diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc index fa73ccf46..6db4c3dab 100644 --- a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc +++ b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc @@ -31,9 +31,9 @@ already part of the {CephCluster} cluster. Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]. -include::../modules/con_ceph-migration-dcn.adoc[leveloffset=+1] +include::../modules/ref_ceph-migration-dcn.adoc[leveloffset=+1] -include::../modules/con_ceph-daemon-cardinality.adoc[leveloffset=+1] +include::../modules/ref_ceph-daemon-cardinality.adoc[leveloffset=+1] include::assembly_migrating-ceph-monitoring-stack.adoc[leveloffset=+1] diff --git a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc b/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc index 51229e9f7..2992a3047 100644 --- a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc +++ b/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc @@ -27,7 +27,7 @@ include::../modules/proc_completing-prerequisites-for-migrating-ceph-monitoring- include::../modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc[leveloffset=+1] -include::../modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc[leveloffset=+1] +include::../modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc[leveloffset=+1] include::../modules/proc_creating-a-ceph-nfs-cluster.adoc[leveloffset=+1] diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc index 5fe5811c9..802f2f6a1 100644 --- a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc +++ b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc @@ -18,11 +18,11 @@ include::../modules/con_adoption-limitations.adoc[leveloffset=+1] //include::../modules/con_known-issues-adoption.adoc[leveloffset=+1] -include::../modules/con_adoption-prerequisites.adoc[leveloffset=+1] +include::../modules/ref_adoption-prerequisites.adoc[leveloffset=+1] include::../modules/con_adoption-guidelines.adoc[leveloffset=+1] -include::../modules/con_adoption-process-overview.adoc[leveloffset=+1] +include::../modules/ref_adoption-process-overview.adoc[leveloffset=+1] include::../modules/con_dcn-adoption-overview.adoc[leveloffset=+1] diff --git a/docs_user/assemblies/assembly_storage-requirements.adoc b/docs_user/assemblies/assembly_storage-requirements.adoc index 771380b3b..2145cca45 100644 --- a/docs_user/assemblies/assembly_storage-requirements.adoc +++ b/docs_user/assemblies/assembly_storage-requirements.adoc @@ -19,13 +19,13 @@ Before you can deploy the services in {rhos_long}, you must review the storage r include::../modules/con_storage-driver-certification.adoc[leveloffset=+1] -include::../modules/con_block-storage-service-requirements.adoc[leveloffset=+1] +include::../modules/ref_block-storage-service-requirements.adoc[leveloffset=+1] include::../modules/con_block-storage-service-limitations.adoc[leveloffset=+1] -include::../modules/con_openshift-preparation-for-block-storage-adoption.adoc[leveloffset=+1] +include::../modules/ref_openshift-preparation-for-block-storage-adoption.adoc[leveloffset=+1] -include::../modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc[leveloffset=+1] +include::../modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc[leveloffset=+1] include::../modules/con_changes-to-cephFS-via-NFS.adoc[leveloffset=+1] diff --git a/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc b/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc index fe61113b8..da5c228ee 100644 --- a/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc +++ b/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc @@ -4,7 +4,7 @@ = {bare_metal} configurations [role="_abstract"] -You configure the {bare_metal_first_ref} by using configuration snippets. For more information about configuring the control plane with the {bare_metal}, see link:{customizing-rhoso}/index[{customizing-rhoso-t}]. +You configure the {bare_metal_first_ref} by using configuration snippets. Some {bare_metal} configuration is overridden in {OpenStackPreviousInstaller}, for example, PXE Loader file names are often overridden at intermediate layers. You must pay attention to the settings you apply in your {rhos_long} deployment. The `ironic-operator` applies a reasonable working default configuration, but if you override them with your prior configuration, your experience might not be ideal or your new {bare_metal} fails to operate. Similarly, additional configuration might be necessary, for example, if you enable and use additional hardware types in your `ironic.conf` file. @@ -38,3 +38,7 @@ The instances of `kernel_append_params`, formerly `pxe_append_params` in the `[p [WARNING] You cannot migrate hardware types that are set with the `ironic.conf` file `enabled_hardware_types` parameter, and hardware type driver interfaces starting with `staging-` into the adopted configuration. + +[role="_additional-resources"] +.Additional resources +* link:{customizing-rhoso}/index[{customizing-rhoso-t}] diff --git a/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc b/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc index c4cc6f303..4e585a17e 100644 --- a/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc +++ b/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="block-storage-configuration-generation-helper-tool_{context}"] = About the {block_storage} configuration generation helper tool diff --git a/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc b/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc index b46f588f7..bafd8b2c0 100644 --- a/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc +++ b/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc @@ -22,4 +22,7 @@ Before you begin the adoption, review the following information to understand th * While the old `ceph-nfs` service only supported NFS version 4.1 and later, the new clustered NFS service supports NFS protocols 3 and 4.1 and later. Mixing protocol versions with an export results in unintended consequences. You should mount a given share across all clients by using a consistent NFS protocol version. -For more information on setting up a clustered NFS service, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster]. + +[role="_additional-resources"] +.Additional resources +* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster] diff --git a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc b/docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc similarity index 84% rename from docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc rename to docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc index 27ef80311..3939b735b 100644 --- a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc +++ b/docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: CONCEPT [id="completing-prerequisites-for-rbd-migration_{context}"] = Completing prerequisites for a {Ceph} RBD migration @@ -7,13 +7,12 @@ Complete the following prerequisites before you begin the {Ceph} Rados Block Device (RBD) migration. * The target CephStorage or ComputeHCI nodes are configured to have both `storage` and `storage_mgmt` networks. This ensures that you can use both {Ceph} public and cluster networks from the same node. From {rhos_prev_long} {rhos_prev_ver} and later you do not have to run a stack update. -* NFS Ganesha is migrated from a {OpenStackPreviousInstaller} deployment to `cephadm`. For more information, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha -cluster]. +* NFS Ganesha is migrated from a {OpenStackPreviousInstaller} deployment to `cephadm`. For more information, see "Creating an NFS Ganesha cluster". * Ceph Metadata Server, monitoring stack, Ceph Object Gateway, and any other daemon that is deployed on Controller nodes. ifeval::["{build}" != "upstream"] * The daemons distribution follows the cardinality constraints that are -described in link:https://access.redhat.com/articles/1548993[Red Hat Ceph -Storage: Supported configurations]. +described in "Red Hat Ceph +Storage: Supported configurations". endif::[] * The {Ceph} cluster is healthy, and the `ceph -s` command returns `HEALTH_OK`. * Run `os-net-config` on the bare metal node and configure additional networks: @@ -57,3 +56,10 @@ $ openstack overcloud node provision \ 7: vlan11 inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\ valid_lft forever preferred_lft forever 8: vlan12 inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\ valid_lft forever preferred_lft forever ---- + +[role="_additional-resources"] +.Additional resources +ifeval::["{build}" != "upstream"] +* link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations] +endif::[] +* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster] diff --git a/docs_user/modules/con_fips-support.adoc b/docs_user/modules/con_fips-support.adoc index 00c216798..831d2573c 100644 --- a/docs_user/modules/con_fips-support.adoc +++ b/docs_user/modules/con_fips-support.adoc @@ -10,4 +10,6 @@ There is a major difference with how FIPS was configured in {OpenStackPreviousIn If your cluster is FIPS enabled, you must deploy a FIPS {rhocp_long} cluster to adopt your {OpenStackShort} {rhos_prev_ver} FIPS control plane. -For more information about enabling FIPS in {OpenShiftShort}, see link:https://docs.openshift.com/container-platform/latest/installing/installing-fips.html[Support for FIPS cryptography] in _OpenShift Container Platform Documentation_. +[role="_additional-resources"] +.Additional resources +* link:https://docs.openshift.com/container-platform/latest/installing/installing-fips.html[Support for FIPS cryptography] diff --git a/docs_user/modules/con_identity-service-authentication.adoc b/docs_user/modules/con_identity-service-authentication.adoc index e249f0639..e18990e89 100644 --- a/docs_user/modules/con_identity-service-authentication.adoc +++ b/docs_user/modules/con_identity-service-authentication.adoc @@ -15,4 +15,6 @@ Red Hat does not support customized roles or policies. Syntax errors or misappli After you adopt a {OpenStackPreviousInstaller}-based OpenStack deployment to a {rhos_long_noacro} deployment, the {identity_service} performs user authentication and authorization by using Secure RBAC (SRBAC). If SRBAC is already enabled, then there is no change to how you perform operations. If SRBAC is disabled, then adopting a {OpenStackPreviousInstaller}-based OpenStack deployment might change how you perform operations due to changes in API access policies. -For more information on SRBAC, see link:{defaultURL}/performing_security_operations/assembly_srbac-in-rhoso_performing-security-services#assembly_srbac-in-rhoso_performing-security-services[Secure role based access control in Red Hat OpenStack Services on OpenShift] in _Performing security operations_. +[role="_additional-resources"] +.Additional resources +* link:{defaultURL}/performing_security_operations/assembly_srbac-in-rhoso_performing-security-services#assembly_srbac-in-rhoso_performing-security-services[Secure role based access control in Red Hat OpenStack Services on OpenShift] diff --git a/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc b/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc index 88aa8e7d5..6ebaa09cf 100644 --- a/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc +++ b/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="key-manager-service-support-for-crypto-plug-ins_{context}"] = Key Manager service support for crypto plug-ins diff --git a/docs_user/modules/con_post-adoption-tasks.adoc b/docs_user/modules/con_post-adoption-tasks.adoc index f0a5563d4..055ed7ba6 100644 --- a/docs_user/modules/con_post-adoption-tasks.adoc +++ b/docs_user/modules/con_post-adoption-tasks.adoc @@ -15,9 +15,9 @@ Perform the following post-adoption tasks to ensure that your {rhos_long} enviro * Verify that you migrated all services from the Controller nodes, and then power off the nodes. If any services are still running in the Controller nodes, such as Open Virtual Networking (ML2/OVN), {object_storage_first_ref}, or {Ceph}, do not power off the nodes. * Optional: Run tempest to verify that the entire adoption process is working correctly. +[role="_additional-resources"] .Additional resources - * link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/updating_your_environment_to_the_latest_maintenance_release/index[Updating your environment to the latest maintenance release] * xref:enabling-high-availability-for-instances_data-plane[Enabling the high availability for Compute instances service] -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/configuring_security_services/index#assembly_enabling-TLS-on-a-deployed-RHOSO-environment[Enabling TLS on a deployed RHOSO environment] in _Configuring security services_ +* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/configuring_security_services/index#assembly_enabling-TLS-on-a-deployed-RHOSO-environment[Enabling TLS on a deployed RHOSO environment] * link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/validating_and_troubleshooting_the_deployed_cloud/index[Validating and troubleshooting the deployed cloud] diff --git a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc index 416ace974..5fb0ac08f 100644 --- a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc +++ b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc @@ -17,8 +17,7 @@ Review the following guidelines for preparing your {rhos_component_storage_file} * Ignore the `osapi_share_listen` configuration. In {rhos_long} {rhos_curr_ver}, you rely on {rhocp_long} routes and ingress. * Check for policy overrides. In {rhos_acro} {rhos_curr_ver}, the {rhos_component_storage_file} ships with a secure default Role-based access control (RBAC), and overrides might not be necessary. ifeval::["{build}" != "downstream"] -Please review RBAC defaults by using the https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html[Oslo policy generator] -tool. +Review RBAC defaults by using the Oslo policy generator tool. endif::[] * If a custom policy is necessary, you must provide it as a `ConfigMap`. The following example spec illustrates how you can set up a `ConfigMap` called `manila-policy` with the contents of a file called `policy.yaml`: + @@ -58,7 +57,7 @@ endif::[] section in `manila: template: manilaScheduler`. * If you have multiple storage back-end drivers configured with {OpenStackShort} {rhos_prev_ver}, you need to split them up when deploying {rhos_acro} {rhos_curr_ver}. Each storage back-end driver needs to use its own instance of the `manila-share` service. * If a storage back-end driver needs a custom container image, find it in the -link:https://catalog.redhat.com/software/containers/search?gs&q=manila[Red Hat Ecosystem Catalog], and create or modify an `OpenStackVersion` custom resource (CR) to specify the custom image using the same `custom name`. +Red Hat Ecosystem Catalog, and create or modify an `OpenStackVersion` custom resource (CR) to specify the custom image using the same `custom name`. + The following example shows a manila spec from the `OpenStackControlPlane` CR that includes multiple storage back-end drivers, where only one is using a custom container image: + @@ -167,3 +166,10 @@ $ oc create secret generic osp-secret-manila-netapp --from-file=~/ replicas: 1 < . . . > ---- + +[role="_additional-resources"] +.Additional resources +ifeval::["{build}" != "downstream"] +* https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html[Oslo policy generator] +endif::[] +* link:https://catalog.redhat.com/software/containers/search?gs&q=manila[Red Hat Ecosystem Catalog] diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc index 5d14ac970..c526210a8 100644 --- a/docs_user/modules/con_storage-driver-certification.adoc +++ b/docs_user/modules/con_storage-driver-certification.adoc @@ -4,6 +4,8 @@ = Storage driver certification [role="_abstract"] -Before you adopt your {rhos_prev_long} {rhos_prev_ver} deployment to a {rhos_long} {rhos_curr_ver} deployment, confirm that your deployed storage drivers are certified for use with {rhos_acro} {rhos_curr_ver}. +Before you adopt your {rhos_prev_long} {rhos_prev_ver} deployment to a {rhos_long} {rhos_curr_ver} deployment, confirm that your deployed storage drivers are certified for use with {rhos_acro} {rhos_curr_ver}. For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the Red Hat Ecosystem Catalog. -For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the link:https://catalog.redhat.com/search?searchType=software&certified_versions=Red%20Hat%20OpenStack%20Services%20on%20OpenShift%2018&p=1[Red Hat Ecosystem Catalog]. +[role="_additional-resources"] +.Additional resources +* link:https://catalog.redhat.com/search?searchType=software&certified_versions=Red%20Hat%20OpenStack%20Services%20on%20OpenShift%2018&p=1[Red Hat Ecosystem Catalog] diff --git a/docs_user/modules/proc_adopting-the-block-storage-service.adoc b/docs_user/modules/proc_adopting-the-block-storage-service.adoc index a69d0bb8c..6aebe5b06 100644 --- a/docs_user/modules/proc_adopting-the-block-storage-service.adoc +++ b/docs_user/modules/proc_adopting-the-block-storage-service.adoc @@ -362,4 +362,4 @@ You do not boot a {compute_service_first_ref} instance by using the new `volume .Additional resources -* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)]. +* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)] diff --git a/docs_user/modules/proc_adopting-the-object-storage-service.adoc b/docs_user/modules/proc_adopting-the-object-storage-service.adoc index 376a1af3b..f76133383 100644 --- a/docs_user/modules/proc_adopting-the-object-storage-service.adoc +++ b/docs_user/modules/proc_adopting-the-object-storage-service.adoc @@ -86,7 +86,7 @@ spec: * `spec.swift.swiftStorage.storageClass` must match the {rhos_acro} deployment storage class. * `metallb.universe.tf/loadBalancerIPs: <172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. * `spec.swift.swiftProxy.networkAttachments` must match the network attachment for the previous {object_storage} configuration from the {OpenStackShort} deployment. - ++ [NOTE] If `SwiftEncryptionEnabled: true` was set in {rhos_prev_long}, ensure that `spec.swift.swiftProxy.encryptionEnabled` is set to `true` and that the {key_manager_first_ref} adoption is complete before proceeding. diff --git a/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc b/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc index 17273f599..5bef3cc75 100644 --- a/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc +++ b/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc @@ -1,7 +1,7 @@ :_mod-docs-content-type: PROCEDURE [id="resolving-HSM-back-end-detection-failures_{context}"] -== Resolving HSM back-end detection failures += Resolving HSM back-end detection failures [role="_abstract"] If the adoption role cannot detect hardware security module (HSM) configuration in the source environment, you must force the HSM adoption. diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc index c94b2fcd8..4a9f26c42 100644 --- a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc +++ b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: CONCEPT [id="reusing-existing-subnet-ranges_{context}"] = Reusing existing subnet ranges @@ -7,11 +7,16 @@ You can reuse existing subnet ranges if they have enough IP addresses to allocate to the new control plane services. You configure the new control plane services to use the same subnet as you used in the {rhos_prev_long} ({OpenStackShort}) environment, and configure the allocation pools that are used by the new services to exclude IP addresses that are already allocated to existing cluster nodes. By reusing existing subnets, you avoid additional link local route configuration between the existing and new subnets. ifeval::["{build_variant}" != "ospdo"] -If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges. For more information, see xref:using-new-subnet-ranges_{context}[Using new subnet ranges]. +If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges. endif::[] No special routing configuration is required to reuse subnet ranges. However, you must ensure that the IP addresses that are consumed by {OpenStackShort} services do not overlap with the new allocation pools configured for {rhos_long_noacro} control plane services. If you are especially constrained by the size of the existing subnet, you may have to apply elaborate exclusion rules when defining allocation pools for the -new control plane services. For more information, see xref:configuring-isolated-networks_configuring-network[Configuring isolated networks]. +new control plane services. + +[role="_additional-resources"] +.Additional resources +* xref:using-new-subnet-ranges_{context}[Using new subnet ranges] +* xref:configuring-isolated-networks_configuring-network[Configuring isolated networks] diff --git a/docs_user/modules/con_adoption-prerequisites.adoc b/docs_user/modules/ref_adoption-prerequisites.adoc similarity index 99% rename from docs_user/modules/con_adoption-prerequisites.adoc rename to docs_user/modules/ref_adoption-prerequisites.adoc index e5d2e4879..eb852bcbb 100644 --- a/docs_user/modules/con_adoption-prerequisites.adoc +++ b/docs_user/modules/ref_adoption-prerequisites.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="adoption-prerequisites_{context}"] = Adoption prerequisites diff --git a/docs_user/modules/con_adoption-process-overview.adoc b/docs_user/modules/ref_adoption-process-overview.adoc similarity index 98% rename from docs_user/modules/con_adoption-process-overview.adoc rename to docs_user/modules/ref_adoption-process-overview.adoc index 2617aa2cb..b7f5b6572 100644 --- a/docs_user/modules/con_adoption-process-overview.adoc +++ b/docs_user/modules/ref_adoption-process-overview.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="adoption-process-overview_{context}"] = Adoption process overview diff --git a/docs_user/modules/con_block-storage-service-requirements.adoc b/docs_user/modules/ref_block-storage-service-requirements.adoc similarity index 98% rename from docs_user/modules/con_block-storage-service-requirements.adoc rename to docs_user/modules/ref_block-storage-service-requirements.adoc index 028f1715c..8d82a42c0 100644 --- a/docs_user/modules/con_block-storage-service-requirements.adoc +++ b/docs_user/modules/ref_block-storage-service-requirements.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="block-storage-requirements_{context}"] = {block_storage} guidelines diff --git a/docs_user/modules/con_ceph-daemon-cardinality.adoc b/docs_user/modules/ref_ceph-daemon-cardinality.adoc similarity index 98% rename from docs_user/modules/con_ceph-daemon-cardinality.adoc rename to docs_user/modules/ref_ceph-daemon-cardinality.adoc index 170bbb898..391bc0812 100644 --- a/docs_user/modules/con_ceph-daemon-cardinality.adoc +++ b/docs_user/modules/ref_ceph-daemon-cardinality.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="ceph-daemon-cardinality_{context}"] = {Ceph} daemon cardinality diff --git a/docs_user/modules/con_ceph-migration-dcn.adoc b/docs_user/modules/ref_ceph-migration-dcn.adoc similarity index 98% rename from docs_user/modules/con_ceph-migration-dcn.adoc rename to docs_user/modules/ref_ceph-migration-dcn.adoc index 8589b6d9f..2681e3cda 100644 --- a/docs_user/modules/con_ceph-migration-dcn.adoc +++ b/docs_user/modules/ref_ceph-migration-dcn.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="ceph-migration-dcn_{context}"] = {Ceph} migration for Distributed Compute Node deployments diff --git a/docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc b/docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc similarity index 99% rename from docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc rename to docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc index 5b5711eac..42a5391f3 100644 --- a/docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc +++ b/docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="openshift-preparation-for-block-storage-adoption_{context}"] = {OpenShiftShort} preparation for {block_storage} adoption diff --git a/docs_user/modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc b/docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc similarity index 99% rename from docs_user/modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc rename to docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc index 4314ea08e..20edb9e68 100644 --- a/docs_user/modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc +++ b/docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc @@ -1,4 +1,4 @@ -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: REFERENCE [id="preparing-block-storage-by-customizing-configuration_{context}"] ifeval::["{build}" == "downstream"]