:_mod-docs-content-type: PROCEDURE
[id="preparing-block-storage-by-customizing-configuration_{context}"]

ifeval::["{build}" == "downstream"]
= Converting the {block_storage} configuration

[role="_abstract"]
In your previous deployment, you use the same `cinder.conf` file for all the services. To prepare your {block_storage_first_ref} configuration for adoption, split this single-file configuration into individual configurations for each {block_storage} service. Review the following information to guide you in coverting your previous configuration:
endif::[]

ifeval::["{build}" != "downstream"]
= Preparing the {block_storage} by customizing the configuration

The high level explanation of the tailor-made approach is:
endif::[]

* Determine what part of the configuration is generic for all the Block Storage services and remove anything that would change when deployed in {rhocp_long}, such as the `connection` in the `[database]` section, the `transport_url` and `log_dir` in the `[DEFAULT]` sections, the whole `[coordination]` and `[barbican]` sections. The remaining generic configuration goes into the `customServiceConfig` option, or a `Secret` custom resource (CR) and is then used in the `customServiceConfigSecrets` section, at the `cinder: template:` level.
* Determine if there is a scheduler-specific configuration and add it to the `customServiceConfig` option in `cinder: template: cinderScheduler`.
* Determine if there is an API-specific configuration and add it to the `customServiceConfig` option in `cinder: template: cinderAPI`.
* If the {block_storage} backup is deployed, add the {block_storage} backup configuration options to `customServiceConfig` option, or to a `Secret` CR that you can add to `customServiceConfigSecrets` section at the `cinder: template:
cinderBackup:` level. Remove the `host` configuration in the `[DEFAULT]` section to support multiple replicas later.
* Determine the individual volume back-end configuration for each of the drivers. The configuration is in the specific driver section, and it includes the `[backend_defaults]` section and FC zoning sections if you use them. The {block_storage} operator does not support a global `customServiceConfig` option for all volume services. Each back end has its own section under `cinder: template: cinderVolumes`, and the configuration goes in the `customServiceConfig` option or in a `Secret` CR and is then used in the `customServiceConfigSecrets` section.
* If any of the {block_storage} volume drivers require a custom vendor image, find the location of the image in the link:https://catalog.redhat.com/search?searchType=software[Red Hat Ecosystem Catalog], and create or modify an `OpenStackVersion` CR to specify the custom image by using the key from the `cinderVolumes` section.
+
For example, if you have the following configuration:
+
[source,yaml]
----
spec:
  cinder:
    enabled: true
    template:
      cinderVolume:
        pure:
          customServiceConfigSecrets:
            - openstack-cinder-pure-cfg
< . . . >
----
+
Then the `OpenStackVersion` CR that describes the container image for that back end looks like the following example:
+
[source,yaml]
----
apiVersion: core.openstack.org/v1beta1
kind: OpenStackVersion
metadata:
  name: openstack
spec:
  customContainerImages:
    cinderVolumeImages:
      pure: registry.connect.redhat.com/purestorage/openstack-cinder-volume-pure-rhosp-18-0'
----
+
[NOTE]
The name of the `OpenStackVersion` must match the name of your `OpenStackControlPlane` CR.

* If your Block Storage services use external files, for example, for a custom policy, or to store credentials or SSL certificate authority bundles to connect to a storage array, make those files available to the right containers. Use `Secrets` or `ConfigMap` to store the information in {OpenShiftShort} and then in the `extraMounts` key. For example, for {Ceph} credentials that are stored in a `Secret` called `ceph-conf-files`, you patch the top-level `extraMounts` key in the `OpenstackControlPlane` CR:
+
[source,yaml]
----
spec:
  extraMounts:
  - extraVol:
    - extraVolType: Ceph
      mounts:
      - mountPath: /etc/ceph
        name: ceph
        readOnly: true
      propagation:
      - CinderVolume
      - CinderBackup
      - Glance
      volumes:
      - name: ceph
        projected:
          sources:
          - secret:
              name: ceph-conf-files
----

* For a service-specific file, such as the API policy, you add the configuration
on the service itself. In the following example, you include the `CinderAPI`
configuration that references the policy you are adding from a `ConfigMap`
called `my-cinder-conf` that has a `policy` key with the contents of the policy:
+
[source,yaml]
----
spec:
  cinder:
    enabled: true
    template:
      cinderAPI:
        customServiceConfig: |
           [oslo_policy]
           policy_file=/etc/cinder/api/policy.yaml
      extraMounts:
      - extraVol:
        - extraVolType: Ceph
          mounts:
          - mountPath: /etc/cinder/api
            name: policy
            readOnly: true
          propagation:
          - CinderAPI
          volumes:
          - name: policy
            projected:
              sources:
              - configMap:
                  name: my-cinder-conf
                  items:
                    - key: policy
                      path: policy.yaml
----