:_mod-docs-content-type: CONCEPT
[id="service-configurations_{context}"]

= Service configurations

[role="_abstract"]
There is a fundamental difference between the {OpenStackPreviousInstaller} and operator deployments
regarding the configuration of the services.

In {OpenStackPreviousInstaller} deployments many of the service configurations are abstracted by
{OpenStackPreviousInstaller}-specific configuration options. A single {OpenStackPreviousInstaller} option may trigger
changes for multiple services and support for drivers, for example, the Block Storage service (cinder), that
require patches to the {OpenStackPreviousInstaller} code base.

In operator deployments this approach has changed: reduce the installer specific knowledge and leverage {OpenShift} ({OpenShiftShort}) and
{rhos_prev_long} ({OpenStackShort}) service specific knowledge whenever possible.

To this effect {OpenStackShort} services will have sensible defaults for {OpenShiftShort} deployments and human operators will provide configuration snippets to provide
necessary configuration, such as the Block Storage service backend configuration, or to override
the defaults.

This shortens the distance between a service specific configuration file (such
as `cinder.conf`) and what the human operator provides in the manifests.

These configuration snippets are passed to the operators in the different
`customServiceConfig` sections available in the manifests, and then they are
layered in the services available in the following levels. To illustrate this,
if you were to set a configuration at the top Block Storage service level (`spec: cinder:
template:`) then it would be applied to all the Block Storage services; for example to
enable debug in all the Block Storage services you would do:

[source,yaml]
----
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      customServiceConfig: |
        [DEFAULT]
        debug = True
< . . . >
----

If you only want to set it for one of the Block Storage services, for example the
scheduler, then you use the `cinderScheduler` section instead:

[source,yaml]
----
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderScheduler:
        customServiceConfig: |
          [DEFAULT]
          debug = True
< . . . >
----

In {OpenShift} it is not recommended to store sensitive information like the
credentials to the Block Storage service storage array in the CRs, so most {OpenStackShort} operators
have a mechanism to use the {OpenShift} `Secrets` for sensitive configuration
parameters of the services and then use them by reference in the
`customServiceConfigSecrets` section which is analogous to the
`customServiceConfig`.

The contents of the `Secret` references passed in the
`customServiceConfigSecrets` will have the same format as `customServiceConfig`:
a snippet with the section/s and configuration options.

When there are sensitive information in the service configuration then it
becomes a matter of personal preference whether to store all the configuration
in the `Secret` or only the sensitive parts. However, if you split the
configuration between `Secret` and `customServiceConfig` you still need the
section header (eg: `[DEFAULT]`) to be present in both places.

Attention should be paid to each service's adoption process as they may have
some particularities regarding their configuration.