:_mod-docs-content-type: ASSEMBLY
ifdef::context[:parent-context: {context}]

[id="preparing-the-block-storage-service_{context}"]
//kgilliga: The content in this file was integrated with "Block storage requirements" (con_block-storage-service-requirements.adoc)
:context: preparing-block-storage

= Preparing the {block_storage} configurations for adoption

[role="_abstract"]
The recommended way to deploy {block_storage} volume back ends is to use a {block_storage} volume service for each back end.

For example, you have an LVM and a Ceph back end and two entries in `cinderVolume`, and you cannot set global defaults for all volume services. You must define a service for each of them:

[source,yaml]
----
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    enabled: true
    template:
      cinderVolume:
        lvm:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [lvm]
< . . . >
        ceph:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [ceph]
< . . . >
----
+
[WARNING]
Check that all configuration options are still valid for the new {rhos_long} version. Configuration options might be deprecated, removed, or added. This applies to both back-end driver-specific configuration options and other generic options.

ifeval::["{build}" != "downstream"]
There are two ways to prepare a {block_storage} configuration for adoption. You can customize the configuration or prepare a quick configuration. There is no difference in how {block_storage} operates with both methods, but you should customize the configuration whenever possible.
endif::[]


ifeval::["{build}" != "downstream"]
include::../modules/proc_preparing-block-storage-service-by-using-agnostic-config-file.adoc[leveloffset=+1]

include::../modules/con_block-storage-service-config-generation-helper-tool.adoc[leveloffset=+1]
endif::[]

ifdef::parent-context[:context: {parent-context}]
ifndef::parent-context[:!context:]