Merge pull request #1148 from klgill/docs-fix-blocktitles

openshift-merge-bot[bot] · web-flow · commit 2df6d47f33f3 · 2025-11-12T19:46:22.000Z
fixing vale warnings
diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc
@@ -29,9 +29,7 @@ Ganesha. To migrate your {CephCluster} cluster, you must decommission the
 Controller nodes and move the {Ceph} daemons to a set of target nodes that are
 already part of the {CephCluster} cluster.
 
-.Prerequisites
-
-* 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].
+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-daemon-cardinality.adoc[leveloffset=+1]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc b/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc
@@ -20,11 +20,7 @@ Ceph Manager. With {OpenStackPreviousInstaller}-deployed {Ceph}, the {Ceph} Dash
 The {Ceph} Dashboard containers are included through `tripleo-container-image-prepare` parameters, and high availability (HA) relies
 on `HAProxy` and `Pacemaker` to be deployed on the {rhos_prev_long} ({OpenStackShort}) environment. For an external {CephCluster} cluster, HA is not supported.
 
-In this procedure, you migrate and relocate the Ceph Monitoring components to free Controller nodes.
-
-.Prerequisites
-
-* 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].
+You migrate and relocate the Ceph Monitoring components to free Controller nodes. 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::../assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc[leveloffset=+1]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
@@ -14,9 +14,7 @@ included in the {rhos_prev_long} control plane into the existing external Red
 Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
 the Compute nodes for an HCI environment or dedicated storage nodes.
 
-.Prerequisites
-
-* 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].
+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/proc_migrating-mgr-from-controller-nodes.adoc[leveloffset=+1]
 
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
@@ -10,9 +10,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
 
-.Prerequisites
-
-* 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].
+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/proc_migrating-the-rgw-backends.adoc[leveloffset=+1]
 
diff --git a/docs_user/assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc b/docs_user/assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc
@@ -11,9 +11,6 @@ ifdef::context[:parent-context: {context}]
 To migrate the monitoring stack to the target nodes, you add the monitoring label to your existing nodes and update the configuration of each daemon. You do not need to migrate node exporters. These daemons are deployed across
 the nodes that are part of the {Ceph} cluster (the placement is ‘*’).
 
-.Prerequisites
-* Confirm that the firewall rules are in place and the ports are open for a given monitoring stack service.
-
 [NOTE]
 Depending on the target nodes and the number of deployed or active daemons, you can either relocate the existing containers to the target nodes, or
 select a subset of nodes that host the monitoring stack daemons. High availability (HA) is not supported. Reducing the placement with `count: 1`  allows you to migrate the existing daemons in a Hyperconverged Infrastructure, or hardware-limited, scenario without impacting other services.
diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
@@ -36,7 +36,7 @@ include::../assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc[leveloff
 
 include::../assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption.adoc[leveloffset=+1]
 
-include::../modules/con_comparing-configuration-files-between-deployments.adoc[leveloffset=+1]
+include::../modules/proc_comparing-configuration-files-between-deployments.adoc[leveloffset=+1]
 
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/modules/proc_comparing-configuration-files-between-deployments.adoc b/docs_user/modules/proc_comparing-configuration-files-between-deployments.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: PROCEDURE
 [id="comparing-configuration-files-between-deployments_{context}"]
 
 = Comparing configuration files between deployments
diff --git a/docs_user/modules/proc_configuring-ldap-with-domain-specific-drivers.adoc b/docs_user/modules/proc_configuring-ldap-with-domain-specific-drivers.adoc
@@ -3,6 +3,7 @@
 
 = Configuring LDAP with domain-specific drivers
 
+[role="_abstract"]
 If you need to integrate the {identity_service_first_ref} with one or more LDAP servers using domain-specific configurations, you can enable domain-specific drivers and provide the necessary LDAP settings.
 
 This involves two main steps:
diff --git a/docs_user/modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc b/docs_user/modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc
@@ -16,8 +16,6 @@ To maintain the high availability for Compute instances (Instance HA) functional
 $ sudo pcs config
 ----
 +
-.Sample output
-+
 ----
 Stonith Devices:
 ...
diff --git a/docs_user/modules/proc_migrating-existing-daemons-to-target-nodes.adoc b/docs_user/modules/proc_migrating-existing-daemons-to-target-nodes.adoc
@@ -6,6 +6,9 @@
 [role="_abstract"]
 The following procedure is an example of an environment with 3 {Ceph} nodes or ComputeHCI nodes. This scenario extends the monitoring labels to all the {Ceph} or ComputeHCI nodes that are part of the cluster. This means that you keep 3 placements for the target nodes.
 
+.Prerequisites
+* Confirm that the firewall rules are in place and the ports are open for a given monitoring stack service.
+
 .Procedure
 
 . Add the monitoring label to all the {CephCluster} or ComputeHCI nodes in the cluster:
diff --git a/docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc b/docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc
@@ -8,6 +8,9 @@ Instead of adding a single `monitoring` label to all the target nodes, it is
 possible to relocate one instance of each monitoring stack daemon on a
 particular node.
 
+.Prerequisites
+* Confirm that the firewall rules are in place and the ports are open for a given monitoring stack service.
+
 .Procedure
 
 . Set each of your nodes to host a particular daemon instance, for example, if you have three target nodes:

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-:_mod-docs-content-type: CONCEPT`
	`1`	`+:_mod-docs-content-type: PROCEDURE`
`2`	`2`	`[id="comparing-configuration-files-between-deployments_{context}"]`
`3`	`3`
`4`	`4`	`= Comparing configuration files between deployments`
Original file line number	Diff line number	Diff line change
`@@ -16,8 +16,6 @@ To maintain the high availability for Compute instances (Instance HA) functional`
`16`	`16`	`$ sudo pcs config`
`17`	`17`	`----`
`18`	`18`	`+`
`19`		`-.Sample output`
`20`		`-+`
`21`	`19`	`----`
`22`	`20`	`Stonith Devices:`
`23`	`21`	`...`