diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 0f9fdf67996c..fb001400bd2a 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -1 +1 @@
- @abhatt-rh @abrennan89 @adellape @aireilly @bergerhoffer @bscott-rh @gabriel-rh @jab-rh @jeana-redhat @JoeAldinger @kalexand-rh @kcarmichael08 @michaelryanpeter @opayne1 @ousleyp @sjhala-ccs @snarayan-redhat @Srivaralakshmi
+ @abhatt-rh @abrennan89 @adellape @aireilly @bergerhoffer @bscott-rh @gabriel-rh @jab-rh @jeana-redhat @JoeAldinger @kalexand-rh @kcarmichael08 @michaelryanpeter @opayne1 @ousleyp @sjhala-ccs @snarayan-redhat
diff --git a/.s2i/httpd-cfg/01-commercial.conf b/.s2i/httpd-cfg/01-commercial.conf
index f5c180331af3..7d2042a392d4 100644
--- a/.s2i/httpd-cfg/01-commercial.conf
+++ b/.s2i/httpd-cfg/01-commercial.conf
@@ -141,13 +141,13 @@ AddType text/vtt                            vtt
     # ACS Redirects to go to the latest version - change here when a new version drops
     # it should probably be best to combine the next few lines in one reg exp but for clarity keeping them separate
     # the first one redirects
-    RewriteRule ^acs/?$ /acs/4.6/welcome/index.html [R=301]
+    RewriteRule ^acs/?$ /acs/4.7/welcome/index.html [R=301]
     # redirect to the latest release notes
-    RewriteRule ^acs/release_notes/?$ /acs/4.6/release_notes/46-release-notes.html [R=301,NE]
+    RewriteRule ^acs/release_notes/?$ /acs/4.7/release_notes/47-release-notes.html [R=301,NE]
     # redirect from ACS CLoud Service page
-    RewriteRule ^acs/installing/install-ocp-operator.html /acs/4.6/installing/installing_ocp/init-bundle-ocp.html [NE,R=301]
-    RewriteRule ^acs/(\D.*)$ /acs/4.6/$1 [NE,R=301]
-    RewriteRule ^acs/(3\.65|3\.66|3\.67|3\.68|3\.69|3\.70|3\.71|3\.72|3\.73|3\.74|4\.0|4\.1|4\.2|4\.3|4\.4|4\.5|4\.6)/?$ /acs/$1/welcome/index.html [L,R=301]
+    RewriteRule ^acs/installing/install-ocp-operator.html /acs/4.7/installing/installing_ocp/init-bundle-ocp.html [NE,R=301]
+    RewriteRule ^acs/(\D.*)$ /acs/4.7/$1 [NE,R=301]
+    RewriteRule ^acs/(3\.65|3\.66|3\.67|3\.68|3\.69|3\.70|3\.71|3\.72|3\.73|3\.74|4\.0|4\.1|4\.2|4\.3|4\.4|4\.5|4\.6|4\.7)/?$ /acs/$1/welcome/index.html [L,R=301]
     #redirect for 4.0 Manage vulneribility page
     RewriteRule ^(acs/(?:4\.0/)?)?operating/manage-vulnerabilities\.html$ /acs/4.0/operating/manage-vulnerabilities/vulnerability-management.html [NE,R=301]
     #redirect for missing 4.3 page
@@ -164,7 +164,7 @@ AddType text/vtt                            vtt
 
     # Redirects for "latest" version
     RewriteRule ^(container-platform|enterprise)/?$ /container-platform/latest [R=301]
-    RewriteRule ^(container-platform|enterprise)/latest/?(.*)$ /container-platform/4\.17/$2 [NE,R=301]
+    RewriteRule ^(container-platform|enterprise)/latest/?(.*)$ /container-platform/4\.18/$2 [NE,R=301]
     RewriteRule ^(online)/(3\.0|3\.1|3\.2|3\.3|3\.4|3\.5|3\.6|3\.7|3\.9|3\.10|3\.11|latest)/?(.*)$ /$1/pro/$3 [NE,R=301]
 
     # Release notes redirects
@@ -268,11 +268,32 @@ AddType text/vtt                            vtt
     # Redirect for power monitoring (specific to 4.14 and latest)
     RewriteRule ^container-platform/(4\.14|latest)/power_monitoring/(.*)$ /container-platform/$1/observability/power_monitoring/$2 [NE,R=302,L]
 
+    # Redirects for Telco RDS changes delivered in https://github.com/openshift/openshift-docs/pull/89095
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/scalability_and_performance/telco-ran-du-rds.html /container-platform/$1/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/scalability_and_performance/telco-core-rds.html /container-platform/$1/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-design-spec.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.html /container-platform/$1/scalability_and_performance/telco-ran-du-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.html /container-platform/$1/scalability_and_performance/telco-core-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.html /container-platform/$1/scalability_and_performance/telco-core-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.html /container-platform/$1/scalability_and_performance/telco-core-rds.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.18)/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.html /container-platform/$1/scalability_and_performance/telco-core-rds.html [NE,R=302]
+
     # Redirects for Telco ZTP changes delivered in https://github.com/openshift/openshift-docs/pull/35889
     RewriteRule ^container-platform/(4\.10|4\.11)/scalability_and_performance/ztp-deploying-disconnected.html /container-platform/$1/scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-clusters-at-scale.html [NE,R=302]
     RewriteRule ^container-platform/(4\.10|4\.11)/scalability_and_performance/ztp-configuring-single-node-cluster-deployment-during-installation.html /container-platform/$1/scalability_and_performance/ztp_far_edge/ztp-manual-install.html [NE,R=302]
     RewriteRule ^container-platform/(4\.10|4\.11)/scalability_and_performance/ztp-vdu-validating-cluster-tuning.html /container-platform/$1/scalability_and_performance/ztp_far_edge/ztp-vdu-validating-cluster-tuning.html [NE,R=302]
 
+    #Redirects for Telco changes for DRC levels in https://github.com/openshift/openshift-docs/pull/87901/
+    RewriteRule ^container-platform/(4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.html /container-platform/$1/scalability_and_performance/cnf-understanding-low-latency.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html /container-platform/$1/scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.html /container-platform/$1/scalability_and_performance/cnf-provisioning-low-latency-workloads.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/scalability_and_performance/low_latency_tuning/cnf-debugging-low-latency-tuning-status.html /container-platform/$1/scalability_and_performance/cnf-debugging-low-latency-tuning-status.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/scalability_and_performance/low_latency_tuning/cnf-performing-platform-verification-latency-tests.html /container-platform/$1/scalability_and_performance/cnf-performing-platform-verification-latency-tests.html [NE,R=302]
+
     # Redirect for low latency tuning changes delivered in https://github.com/openshift/openshift-docs/pull/47965
     RewriteRule ^container-platform/(4\.11|4\.12)/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.html /container-platform/$1/scalability_and_performance/cnf-low-latency-tuning.html [NE,R=302]
 
@@ -285,6 +306,17 @@ AddType text/vtt                            vtt
     RewriteRule ^container-platform/(4\.12|4\.13)/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html /container-platform/$1/scalability_and_performance/cnf-low-latency-tuning.html [NE,R=302]
     RewriteRule ^container-platform/(4\.12|4\.13)/scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.html /container-platform/$1/scalability_and_performance/cnf-low-latency-tuning.html [NE,R=302]
 
+    # Redirects for monitoring changes
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/monitoring-overview.html /container-platform/$1/observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/common-monitoring-configuration-scenarios.html /container-platform/$1/observability/monitoring/getting-started/core-platform-monitoring-first-steps.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/configuring-the-monitoring-stack.html /container-platform/$1/observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/enabling-monitoring-for-user-defined-projects.html /container-platform/$1/observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/enabling-alert-routing-for-user-defined-projects.html /container-platform/$1/observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/managing-metrics.html /container-platform/$1/observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/managing-alerts.html /container-platform/$1/observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/reviewing-monitoring-dashboards.html /container-platform/$1/observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17)/observability/monitoring/accessing-third-party-monitoring-apis.html /container-platform/$1/observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.html [NE,R=302]
+
     #Install redirects per https://github.com/openshift/openshift-docs/pull/79711
     RewriteRule ^container-platform/(4\.1[2-6]|latest)/installing/index.html /container-platform/$1/installing/overview/index.html [NE,R=302]
     RewriteRule ^container-platform/(4\.1[2-6]|latest)/installing/installing-preparing.html /container-platform/$1/installing/overview/installing-preparing.html [NE,R=302]
@@ -360,29 +392,29 @@ AddType text/vtt                            vtt
     RewriteRule ^container-platform/(4\.9|4\.10|4\.11|4\.12)/serverless/develop/serverless-traffic-management.html /container-platform/$1/serverless/knative-serving/traffic-splitting/traffic-splitting-overview.html [NE,R=302]
 
 
-    # redirect latest to 1.34
+    # redirect latest to 1.35
     RewriteRule ^serverless/?$ /serverless/latest [R=302]
-    RewriteRule ^serverless/latest/?(.*)$ /serverless/1\.34/$1 [NE,R=302]
+    RewriteRule ^serverless/latest/?(.*)$ /serverless/1\.35/$1 [NE,R=302]
 
     # redirect top-level without filespec to the about file
-    RewriteRule ^serverless/(1\.28|1\.29|1\.30|1\.31|1\.32|1\.33|1\.34)/?$ /serverless/$1/about/about-serverless.html [L,R=302]
+    RewriteRule ^serverless/(1\.28|1\.29|1\.30|1\.31|1\.32|1\.33|1\.34|1\.35)/?$ /serverless/$1/about/about-serverless.html [L,R=302]
 
     # redirect rel notes
-    RewriteRule ^container-platform/(4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17)/serverless/serverless-release-notes.html$ /serverless/1.34/about/serverless-release-notes.html [L,R=302]
-    RewriteRule ^(rosa|dedicated)/serverless/serverless-release-notes.html$ /serverless/1.34/about/serverless-release-notes.html [L,R=302]
+    RewriteRule ^container-platform/(4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17)/serverless/serverless-release-notes.html$ /serverless/1.35/about/serverless-release-notes.html [L,R=302]
+    RewriteRule ^(rosa|dedicated)/serverless/serverless-release-notes.html$ /serverless/1.35/about/serverless-release-notes.html [L,R=302]
 
     # redirect any links to existing OCP embedded content to standalone equivalent
-    RewriteRule ^container-platform/(4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/serverless/?(.*)$ /serverless/1.34/$2  [L,R=302]
+    RewriteRule ^container-platform/(4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/serverless/?(.*)$ /serverless/1.35/$2  [L,R=302]
 
     # redirect any links to existing ROSA/Dedicated embedded content to standalone equivalent
-    RewriteRule ^(rosa|dedicated)/serverless/?(.*)$ /serverless/1.34/$2  [L,R=302]
+    RewriteRule ^(rosa|dedicated)/serverless/?(.*)$ /serverless/1.35/$2  [L,R=302]
 
     # redirect builds latest to 1.2
     RewriteRule ^builds/?$ /builds/latest [R=302]
-    RewriteRule ^builds/latest/?(.*)$ /builds/1.2/$1 [NE,R=302]
+    RewriteRule ^builds/latest/?(.*)$ /builds/1.3/$1 [NE,R=302]
 
     # redirect top-level without filespec to the about file
-    RewriteRule ^builds/(1\.0|1\.1|1\.2)/?$ /builds/$1/about/overview-openshift-builds.html  [L,R=302]
+    RewriteRule ^builds/(1\.0|1\.1|1\.2|1\.3)/?$ /builds/$1/about/overview-openshift-builds.html  [L,R=302]
 
     # Builds using Shipwright landing page
     RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17|4\.18)/cicd/builds_using_shipwright/overview-openshift-builds.html /builds/latest/about/overview-openshift-builds.html  [L,R=302]
@@ -438,11 +470,11 @@ AddType text/vtt                            vtt
 
     # Service Mesh handling unversioned and latest links
     RewriteRule ^service-mesh/?$ /service-mesh/latest [R=302]
-    RewriteRule ^servce-mesh/latest/?(.*)$ /service-mesh/3\.0.0tp1/$1 [NE,R=302]
+    RewriteRule ^service-mesh/latest/?(.*)$ /service-mesh/3\.0/$1 [NE,R=302]
 
     # Service Mesh landing page
 
-    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17|4\.18)/service_mesh/v3x/ossm-service-mesh-3-0-overview.html /service-mesh/3.0.0tp1/about/ossm-about-openshift-service-mesh.html [NE,R=302]
+    RewriteRule ^container-platform/(4\.14|4\.15|4\.16|4\.17|4\.18)/service_mesh/v3x/ossm-service-mesh-3-0-overview.html /service-mesh/3.0/about/ossm-about-openshift-service-mesh.html [NE,R=302]
 
     # Pipelines handling unversioned and latest links
     RewriteRule ^pipelines/?$ /pipelines/latest [R=302]
@@ -759,7 +791,7 @@ AddType text/vtt                            vtt
     RewriteRule ^rosa/?$ /rosa/welcome/index.html [L,R=301]
     RewriteRule ^enterprise/(3\.0|3\.1|3\.2)/?$ /enterprise/$1/welcome/index.html [L,R=301]
     RewriteRule ^enterprise/3\.3/?$ /container-platform/3.3/welcome/index.html [L,R=301]
-    RewriteRule ^container-platform/(3\.3|3\.4|3\.5|3\.6|3\.7|3\.9|3\.10|3\.11|4\.1|4\.2|4\.3|4\.4|4\.5|4\.6|4\.7|4\.8|4\.9|4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17)/?$ /container-platform/$1/welcome/index.html [L,R=301]
+    RewriteRule ^container-platform/(3\.3|3\.4|3\.5|3\.6|3\.7|3\.9|3\.10|3\.11|4\.1|4\.2|4\.3|4\.4|4\.5|4\.6|4\.7|4\.8|4\.9|4\.10|4\.11|4\.12|4\.13|4\.14|4\.15|4\.16|4\.17|4\.18)/?$ /container-platform/$1/welcome/index.html [L,R=301]
     RewriteRule ^container-platform-ocp/(4\.3|4\.4|4\.8)/?$ /container-platform-ocp/$1/welcome/index.html [L,R=301]
 
 
diff --git a/.vale/styles/config/vocabularies/OpenShiftDocs/accept.txt b/.vale/styles/config/vocabularies/OpenShiftDocs/accept.txt
index edf49fe67c58..7faa7bca3121 100644
--- a/.vale/styles/config/vocabularies/OpenShiftDocs/accept.txt
+++ b/.vale/styles/config/vocabularies/OpenShiftDocs/accept.txt
@@ -13,7 +13,6 @@
 [Uu]npause
 Assisted Installer
 Control Plane Machine Set Operator
-custom resources?
 GHz
 gpsd
 gpspipe
diff --git a/.vale/styles/config/vocabularies/OpenShiftDocs/reject.txt b/.vale/styles/config/vocabularies/OpenShiftDocs/reject.txt
index 2b15a74f7972..fcb24dfb1e44 100644
--- a/.vale/styles/config/vocabularies/OpenShiftDocs/reject.txt
+++ b/.vale/styles/config/vocabularies/OpenShiftDocs/reject.txt
@@ -6,7 +6,6 @@
 [Oo]peratorize
 [Ss]ingle [Nn]ode OpenShift
 [Tt]hree [Nn]ode OpenShift
-AI
 configuration maps?
 MachineSets
 machinesets?
diff --git a/_attributes/attributes-microshift.adoc b/_attributes/attributes-microshift.adoc
index bd0cd2ff805f..ef5c576b2ef0 100644
--- a/_attributes/attributes-microshift.adoc
+++ b/_attributes/attributes-microshift.adoc
@@ -4,14 +4,14 @@
 :experimental:
 :imagesdir: images
 :OCP: OpenShift Container Platform
-:ocp-version: 4.18
+:ocp-version: 4.19
 :oc-first: pass:quotes[OpenShift CLI (`oc`)]
 //OpenShift Kubernetes Engine
 :oke: OpenShift Kubernetes Engine
 :product-title-first: Red Hat build of MicroShift (MicroShift)
 :microshift-short: MicroShift
 :product-registry: OpenShift image registry
-:product-version: 4.18
+:product-version: 4.19
 :rhel-major: rhel-9
 :op-system-base-full: Red Hat Enterprise Linux (RHEL)
 :op-system-base: RHEL
@@ -19,9 +19,10 @@
 :op-system-ostree: RHEL for Edge
 :op-system-rt-kernel: Red Hat Enterprise Linux for Real Time (real-time kernel)
 :op-system-rtk: real-time kernel
-:op-system-version: 9.4
+:op-system-image: image mode for RHEL
+:op-system-version: 9.6
 :op-system-version-major: 9
 :op-system-bundle: Red Hat Device Edge
-:rpm-repo-version: rhocp-4.18
+:rpm-repo-version: rhocp-4.19
 :rhde-version: 4
 :VirtProductName: OpenShift Virtualization
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
index 428963cc7a06..2ddcfd2f1636 100644
--- a/_attributes/common-attributes.adoc
+++ b/_attributes/common-attributes.adoc
@@ -10,6 +10,10 @@
 :toc-title:
 :imagesdir: images
 :prewrap!:
+// n-1 and n+1 OCP versions relative to the current branch's {product-version} attr
+:ocp-nminus1: 4.17
+:ocp-nplus1: 4.19
+// Operating system attributes
 :op-system-first: Red Hat Enterprise Linux CoreOS (RHCOS)
 :op-system: RHCOS
 :op-system-lowercase: rhcos
@@ -40,9 +44,10 @@ endif::[]
 :oadp-first: OpenShift API for Data Protection (OADP)
 :oadp-full: OpenShift API for Data Protection
 :oadp-short: OADP
-:oadp-version: 1.4.1
-:oadp-version-1-3: 1.3.3
-:oadp-version-1-4: 1.4.1
+:oadp-version: 1.4.4
+:oadp-version-1-3: 1.3.6
+:oadp-version-1-4: 1.4.4
+:oadp-bsl-api: backupstoragelocations.velero.io
 :oc-first: pass:quotes[OpenShift CLI (`oc`)]
 :product-registry: OpenShift image registry
 :product-mirror-registry: Mirror registry for Red Hat OpenShift
@@ -51,7 +56,7 @@ endif::[]
 :rh-rhacm-title: Red Hat Advanced Cluster Management
 :rh-rhacm-first: Red Hat Advanced Cluster Management (RHACM)
 :rh-rhacm: RHACM
-:rh-rhacm-version: 2.11
+:rh-rhacm-version: 2.13
 :osc: OpenShift sandboxed containers
 :cert-manager-operator: cert-manager Operator for Red Hat OpenShift
 :secondary-scheduler-operator-full: Secondary Scheduler Operator for Red Hat OpenShift
@@ -68,6 +73,10 @@ endif::[]
 :mtc-version: 1.8
 :mtc-version-z: 1.8.5
 :mtc-legacy-image: 1.7
+:mtv-first: Migration Toolkit for Virtualization (MTV)
+:mtv-short: MTV
+:mtv-full: Migration Toolkit for Virtualization
+:mtv-version: 2.7
 // builds (Valid only in 4.11 and later)
 :builds-v2title: Builds for Red Hat OpenShift
 :builds-v2shortname: OpenShift Builds v2
@@ -85,8 +94,8 @@ endif::[]
 //pipelines
 :pipelines-title: Red Hat OpenShift Pipelines
 :pipelines-shortname: OpenShift Pipelines
-:pipelines-ver: pipelines-1.17
-:pipelines-version-number: 1.17
+:pipelines-ver: pipelines-1.18
+:pipelines-version-number: 1.18
 :tekton-chains: Tekton Chains
 :tekton-hub: Tekton Hub
 :artifact-hub: Artifact Hub
@@ -113,6 +122,9 @@ ifdef::openshift-origin[]
 :CNVSubscriptionSpecSource: community-operators
 :CNVSubscriptionSpecName: community-kubevirt-hyperconverged
 endif::[]
+// openshift virtualization engine (ove)
+:ove-first: Red Hat OpenShift Virtualization Engine
+:ove: OpenShift Virtualization Engine
 //distributed tracing
 :DTProductName: Red Hat OpenShift distributed tracing platform
 :DTShortName: distributed tracing platform
@@ -175,7 +187,7 @@ endif::[]
 :product-rosa: Red Hat OpenShift Service on AWS
 :SMProductName: Red Hat OpenShift Service Mesh
 :SMProductShortName: Service Mesh
-:SMProductVersion: 2.6.4
+:SMProductVersion: 2.6.6
 :MaistraVersion: 2.6
 :KialiProduct: Kiali Operator provided by Red Hat
 :SMPlugin: OpenShift Service Mesh Console (OSSMC) plugin
@@ -211,17 +223,17 @@ endif::[]
 :lvms-first: Logical Volume Manager (LVM) Storage
 :lvms: LVM Storage
 //Operator SDK version
-:osdk_ver: 1.36.1
+:osdk_ver: 1.38.0
 //Operator SDK version that shipped with the previous OCP 4.x release
-:osdk_ver_n1: 1.31.0
+:osdk_ver_n1: 1.36.1
 //Version-agnostic OLM
 :olm-first: Operator Lifecycle Manager (OLM)
 :olm: OLM
-//Initial version of OLM that shipped with OCP 4, aka "v0"
-:olmv0: existing OLM
-:olmv0-caps: Existing OLM
-:olmv0-first: existing Operator Lifecycle Manager (OLM)
-:olmv0-first-caps: Existing Operator Lifecycle Manager (OLM)
+//Initial version of OLM that shipped with OCP 4, aka "v0" and f/k/a "existing" during OLM v1's pre-4.18 TP phase
+:olmv0: OLM (Classic)
+:olmv0-caps: OLM (Classic)
+:olmv0-first: Operator Lifecycle Manager (OLM) Classic
+:olmv0-first-caps: Operator Lifecycle Manager (OLM) Classic
 //Next-gen (OCP 4.14+) Operator Lifecycle Manager, f/k/a "1.0"
 :olmv1: OLM v1
 :olmv1-first: Operator Lifecycle Manager (OLM) v1
@@ -295,6 +307,12 @@ endif::[]
 :ocid: OCID
 :ocvs-first: Oracle(R) Cloud VMware Solution (OCVS)
 :ocvs: OCVS
+:oci-c3: Oracle(R) Compute Cloud@Customer
+:oci-c3-no-rt: Oracle Compute Cloud@Customer
+:oci-c3-short: Compute Cloud@Customer
+:oci-pca: Oracle(R) Private Cloud Appliance
+:oci-pca-no-rt: Oracle Private Cloud Appliance
+:oci-pca-short: Private Cloud Appliance
 // Red Hat OpenStack Platform (RHOSP)/OpenStack
 ifndef::openshift-origin[]
 :rh-openstack-first: Red Hat OpenStack Platform (RHOSP)
@@ -304,12 +322,12 @@ ifdef::openshift-origin[]
 :rh-openstack-first: OpenStack
 :rh-openstack: OpenStack
 endif::openshift-origin[]
+:rhoso-first: Red Hat OpenStack Services on OpenShift (RHOSO)
+:rhoso: RHOSO
 // VMware vSphere
 :vmw-first: VMware vSphere
 :vmw-full: VMware vSphere
 :vmw-short: vSphere
-
-
 //Token-based auth products
 //AWS Security Token Service
 :sts-first: Security Token Service (STS)
@@ -321,8 +339,6 @@ endif::openshift-origin[]
 //Google Cloud Platform Workload Identity
 :gcp-wid-first: Google Cloud Platform Workload Identity
 :gcp-wid-short: GCP Workload Identity
-
-
 // Cluster API terminology
 // Cluster CAPI Operator
 :cluster-capi-operator: Cluster CAPI Operator
@@ -353,7 +369,6 @@ endif::openshift-origin[]
 // Cluster API Provider VMware vSphere
 :cap-vsphere-first: Cluster API Provider VMware vSphere
 :cap-vsphere-short: Cluster API Provider vSphere
-
 // Hosted control planes related attributes
 :hcp-capital: Hosted control planes
 :hcp: hosted control planes
diff --git a/_distro_map.yml b/_distro_map.yml
index 9c68a2c22e10..a15775b53dbf 100644
--- a/_distro_map.yml
+++ b/_distro_map.yml
@@ -45,6 +45,9 @@ openshift-origin:
     enterprise-4.17:
       name: '4.17'
       dir: '4.17'
+    enterprise-4.18:
+      name: '4.18'
+      dir: '4.18'
     enterprise-3.6:
       name: '3.6'
       dir: '3.6'
@@ -170,7 +173,7 @@ openshift-dedicated:
     enterprise-3.11:
       name: '3'
       dir: dedicated/3
-    enterprise-4.17:
+    enterprise-4.18:
       name: ''
       dir: dedicated/
 openshift-aro:
@@ -193,7 +196,7 @@ openshift-rosa:
   site_name: Documentation
   site_url: https://docs.openshift.com/
   branches:
-    enterprise-4.17:
+    enterprise-4.18:
       name: ''
       dir: rosa/
     rosa-preview:
@@ -206,7 +209,7 @@ openshift-rosa-hcp:
   site_name: Documentation
   site_url: https://docs.openshift.com/
   branches:
-    enterprise-4.17:
+    enterprise-4.18:
       name: ''
       dir: rosa-hcp/
     rosa-preview:
@@ -219,7 +222,7 @@ openshift-rosa-portal:
   site_name: Documentation
   site_url: https://docs.openshift.com/
   branches:
-    enterprise-4.17:
+    enterprise-4.18:
       name: ''
       dir: rosa-portal/
 openshift-webscale:
@@ -322,6 +325,9 @@ openshift-acs:
     rhacs-docs-4.6:
       name: '4.6'
       dir: acs/4.6
+    rhacs-docs-4.7:
+      name: '4.7'
+      dir: acs/4.7
 microshift:
   name: Red Hat build of MicroShift
   author: OpenShift Documentation Project <openshift-docs@redhat.com>
@@ -366,6 +372,9 @@ openshift-serverless:
     serverless-docs-1.35:
       name: '1.35'
       dir: serverless/1.35
+    serverless-docs-1.36:
+      name: '1.36'
+      dir: serverless/1.36
 openshift-gitops:
   name: Red Hat OpenShift GitOps
   author: OpenShift documentation team <openshift-docs@redhat.com>
@@ -450,6 +459,9 @@ openshift-builds:
     build-docs-1.3:
       name: '1.3'
       dir: builds/1.3
+    build-docs-1.4:
+      name: '1.4'
+      dir: builds/1.4
 openshift-lightspeed:
   name: Red Hat OpenShift Lightspeed
   author: OpenShift documentation team <openshift-docs@redhat.com>
@@ -460,9 +472,7 @@ openshift-lightspeed:
     lightspeed-docs-1.0tp1:
       name: '1.0tp1'
       dir: lightspeed/1.0tp1
-    lightspeed-docs-1.0:
-      name: '1.0'
-      dir: lightspeed/1.0
+
 openshift-service-mesh:
   name: Red Hat OpenShift Service Mesh
   author: OpenShift documentation team <openshift-docs@redhat.com>
@@ -473,3 +483,6 @@ openshift-service-mesh:
     service-mesh-docs-3.0.0tp1:
       name: '3.0.0tp1'
       dir: service-mesh/3.0.0tp1
+    service-mesh-docs-3.0:
+      name: '3.0'
+      dir: service-mesh/3.0
diff --git a/_javascripts/page-loader.js b/_javascripts/page-loader.js
index 175f9d044e41..ca0a0cfe1fba 100644
--- a/_javascripts/page-loader.js
+++ b/_javascripts/page-loader.js
@@ -8,6 +8,7 @@ const urlMappings = {
   "openshift-builds": "https://docs.openshift.com/builds/",
   "openshift-enterprise": "https://docs.openshift.com/container-platform/",
   "openshift-gitops": "https://docs.openshift.com/gitops/",
+  "openshift-lightspeed": "https://docs.openshift.com/lightspeed/",
   "openshift-origin": "https://docs.okd.io/",
   "openshift-pipelines": "https://docs.openshift.com/pipelines/",
   "openshift-serverless": "https://docs.openshift.com/serverless/",
diff --git a/_stylesheets/docs.css b/_stylesheets/docs.css
index 3ae1715af067..cdc1a0bff0b3 100644
--- a/_stylesheets/docs.css
+++ b/_stylesheets/docs.css
@@ -70,6 +70,21 @@ div.gsc-option-menu-container>div.gsc-selected-option-container {
   margin: 0 10px;
 }
 
+/* target safari only hack: https://stackoverflow.com/a/25975282/6758654 */
+/* Addresses https://github.com/openshift/openshift-docs/issues/40909 */
+@media not all and (min-resolution:.001dpcm) { @supports (-webkit-appearance:none) and (stroke-color:transparent) {
+    #hc-search.wide {
+      z-index:  50;
+      margin-top:  28px;
+      margin-left:  -15px;
+    }
+
+    .sidebar.wide {
+      padding-top:  30px;
+    }
+}}
+/* end safari only */
+
 /* ------------------------------------------------------------
 Image: "Spin" https://www.flickr.com/photos/eflon/3655695161/
 Author: eflon https://www.flickr.com/photos/eflon/
@@ -550,6 +565,7 @@ h2:hover>a.anchor, h2>a.anchor:hover, h3:hover>a.anchor, h3>a.anchor:hover, h4:h
   }
 
   #toc {
+    user-select: none;
     float: right;
     padding-top: 0.1em !important;
     font-size: 0.8em;
diff --git a/_templates/_page_openshift.html.erb b/_templates/_page_openshift.html.erb
index 925cd507852a..4987bffa7415 100644
--- a/_templates/_page_openshift.html.erb
+++ b/_templates/_page_openshift.html.erb
@@ -14,13 +14,13 @@
   <%= ((["3.0", "3.1", "3.2", "3.3", "3.4", "3.5", "3.6", "3.7", "3.9", "3.10", "4.1", "4.2", "4.3", "4.4", "4.5", "4.6", "4.7"].include?(version)) && distro_key == "openshift-enterprise") ? '<meta name="googlebot" content="noindex">' : '' %>
   <title><%= [topic_title, subgroup_title].compact.join(' - ') %> | <%= group_title %> | <%= distro %> <%= version %></title>
   <link href="https://assets.openshift.net/content/subdomain.css" rel="stylesheet" type="text/css"/>
-  <link href="https://docs.openshift.com/container-platform/4.1/_stylesheets/search.css" rel="stylesheet" media="screen"/>
-  <link href="https://docs.openshift.com/container-platform/4.1/_stylesheets/autumn.css" rel="stylesheet"  media="screen"/>
+  <link href="https://docs.okd.io/latest/_stylesheets/search.css" rel="stylesheet" media="screen"/>
+  <link href="https://docs.okd.io/latest/_stylesheets/autumn.css" rel="stylesheet"  media="screen"/>
   <link href="https://assets.openshift.net/content/subdomain/touch-icon-precomposed.png" rel="apple-touch-icon-precomposed" type="image/png"/>
   <link href="https://assets.openshift.net/content/subdomain/favicon32x32.png" rel="shortcut icon" type="text/css"/>
   <link href="https://assets.openshift.net/content/osh-nav-footer.css" rel="stylesheet" type="text/css" media="screen"/>
-  <link href="https://docs.openshift.com/container-platform/4.1/_stylesheets/docs.css" rel="stylesheet"  media="screen"/>
-  <link href="https://docs.openshift.com/container-platform/4.1/_stylesheets/print.css" rel="stylesheet" type="text/css" media="print"/>
+  <link href="https://docs.okd.io/latest/_stylesheets/docs.css" rel="stylesheet"  media="screen"/>
+  <link href="https://docs.okd.io/latest/_stylesheets/print.css" rel="stylesheet" type="text/css" media="print"/>
   <!--[if IE]><link rel="shortcut icon" href="https://assets.openshift.net/content/subdomain/favicon.ico"><![endif]-->
   <!-- or, set /favicon.ico for IE10 win -->
   <meta content="OpenShift" name="application-name">
@@ -66,15 +66,15 @@
                       unsupported_versions_gitops.include?(version) ||
                       unsupported_versions_origin.include?(version)
                       unsupported_versions_pipelines.include?(version) ||
-                      unsupported_versions_serverless.include?(version) ||
-                      version == "4.18"
+                      unsupported_versions_serverless.include?(version)
                       );
 
         if (!["openshift-webscale", "openshift-dpu", "openshift-lightspeed", "openshift-service-mesh", "openshift-origin", "openshift-acs", "openshift-rosa", "openshift-dedicated"].include?(distro_key) || unsupported)
       %>
       <span>
         <div class="alert alert-info" role="primary" id="support-info">
-          <strong>OpenShift docs are moving and will soon only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>, the home of all Red Hat product documentation. Explore the <a href="https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/index" style="color: #0C5460 !important" class="link-primary">new docs experience</a> today.</strong>
+          <strong>Starting on March 12, 2025, OpenShift docs will only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
+          </strong>
         </div>
       </span>
       <% end %>
@@ -106,7 +106,8 @@
       <% if (distro_key == "openshift-acs") %>
         <span>
           <div class="alert alert-info" role="primary" id="support-info">
-            <strong>OpenShift docs are moving and will soon only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>, the home of all Red Hat product documentation. Explore the <a href="https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/latest" style="color: #0C5460 !important" class="link-primary">new docs experience</a> today.</strong>
+            <strong>Starting on March 12, 2025, OpenShift docs will only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
+            </strong>
           </div>
         </span>
       <% end %>
@@ -114,7 +115,8 @@
       <% if (distro_key == "openshift-dedicated") %>
         <span>
           <div class="alert alert-info" role="primary" id="support-info">
-            <strong>OpenShift docs are moving and will soon only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>, the home of all Red Hat product documentation. Explore the <a href="https://docs.redhat.com/en/documentation/openshift_dedicated/4/html/introduction_to_openshift_dedicated/index" style="color: #0C5460 !important" class="link-primary">new docs experience</a> today.</strong>
+            <strong>Starting on March 12, 2025, OpenShift docs will only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
+            </strong>
           </div>
         </span>
       <% end %>
@@ -122,19 +124,19 @@
       <% if (distro_key == "openshift-rosa") %>
         <span>
           <div class="alert alert-info" role="primary" id="support-info">
-            <strong>OpenShift docs are moving and will soon only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>, the home of all Red Hat product documentation. Explore the <a href="https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/about/index" style="color: #0C5460 !important" class="link-primary">new docs experience</a> today.</strong>
+            <strong>Starting on March 12, 2025, OpenShift docs will only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
+            </strong>
           </div>
         </span>
       <% end %>
 
-      <% if (version == "4.18") && (distro_key != "openshift-webscale" && distro_key != "openshift-dpu" && distro_key != "rosa-hcp") %>
+      <% if ((version == "latest") &&(distro_key == "openshift-origin")) %>
       <span>
         <div class="alert alert-danger" role="alert" id="support-alert">
-          <strong>This documentation is a work in progress that aligns to preview releases of the next pending OpenShift Container Platform version 4 minor release. It might not be complete or fully tested, and some features and content might be removed before the next release. </strong>For the most recent released and supported version, see <a href="https://docs.openshift.com/container-platform/latest/welcome/index.html" style="color: #545454 !important" class="link-primary">[4]</a>.
+          <strong>This documentation is a work in progress that aligns to preview releases of the next pending OKD version 4 minor release. It might not be complete or fully tested, and some features and content might be removed before the next release.</a>.
         </div>
       </span>
       <% end %>
-
       <% if ((unsupported_versions.include? version) && (distro_key == "openshift-enterprise")) %>
 
       <span>
@@ -223,6 +225,7 @@
             </a>
           <% end %>
           <select id="version-selector" onchange="versionSelector(this);">
+              <option value="4.18">4.18</option>
               <option value="4.17">4.17</option>
               <option value="4.16">4.16</option>
               <option value="4.15">4.15</option>
@@ -257,6 +260,7 @@
               <%= distro %>
             </a>
             <select id="version-selector" onchange="versionSelector(this);">
+              <option value="4.7">4.7</option>
               <option value="4.6">4.6</option>
               <option value="4.5">4.5</option>
               <option value="4.4">4.4</option>
@@ -280,6 +284,7 @@
               <%= distro %>
             </a>
             <select id="version-selector" onchange="versionSelector(this);">
+              <option value="1.35">1.35</option>
               <option value="1.34">1.34</option>
               <option value="1.33">1.33</option>
               <option value="1.32">1.32</option>
@@ -307,6 +312,7 @@
               <%= distro %>
             </a>
             <select id="version-selector" onchange="versionSelector(this);">
+              <option value="1.3">1.3</option>
               <option value="1.2">1.2</option>
               <option value="1.1">1.1</option>
               <option value="1.0">1.0</option>
@@ -337,6 +343,7 @@
               <%= distro %>
             </a>
             <select id="version-selector" onchange="versionSelector(this);">
+              <option value="3.0">3.0</option>
               <option value="3.0.0tp1">3.0.0tp1</option>
             </select>
         <% elsif (distro_key == "openshift-telco") %>
@@ -353,6 +360,7 @@
             </a>
             <select id="version-selector" onchange="versionSelector(this);">
               <option value="latest">latest</option>
+              <option value="4.18">4.18</option>
               <option value="4.17">4.17</option>
               <option value="4.16">4.16</option>
               <option value="4.15">4.15</option>
@@ -556,13 +564,13 @@
   <script src="https://assets.openshift.net/content/modernizr.js" type="text/javascript"></script>
   <script src="https://assets.openshift.net/content/subdomain.js" type="text/javascript"></script>
   <script src="https://assets.openshift.net/content/nav-tertiary.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/bootstrap-offcanvas.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/reformat-html.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/hc-search.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/page-loader.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/bootstrap-offcanvas.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/reformat-html.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/hc-search.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/page-loader.js" type="text/javascript"></script>
   <script src="https://cdnjs.cloudflare.com/ajax/libs/clipboard.js/2.0.6/clipboard.min.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/clipboard.js" type="text/javascript"></script>
-  <script src="https://docs.openshift.com/container-platform/4.1/_javascripts/collapsible.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/clipboard.js" type="text/javascript"></script>
+  <script src="https://docs.okd.io/latest/_javascripts/collapsible.js" type="text/javascript"></script>
   <script>
   var dk = '<%= distro_key %>';
   var version = '<%= version %>';
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
index 60157538b868..f26a099f9366 100644
--- a/_topic_maps/_topic_map.yml
+++ b/_topic_maps/_topic_map.yml
@@ -31,6 +31,8 @@ Topics:
   File: index
 - Name: Learn more about OpenShift Container Platform
   File: learn_more_about_openshift
+- Name: Providing documentation feedback
+  File: providing-feedback-on-red-hat-documentation
   Distros: openshift-enterprise
 - Name: About OpenShift Kubernetes Engine
   File: oke_about
@@ -122,12 +124,14 @@ Topics:
     File: index
   - Name: Creating a mirror registry with mirror registry for Red Hat OpenShift
     File: installing-mirroring-creating-registry
-  - Name: Mirroring images for a disconnected installation by using the oc adm command
-    File: installing-mirroring-installation-images
-  - Name: Mirroring images for a disconnected installation using the oc-mirror plugin v1
-    File: installing-mirroring-disconnected
   - Name: Mirroring images for a disconnected installation using oc-mirror plugin v2
     File: about-installing-oc-mirror-v2
+  - Name: Migrating from oc-mirror plugin v1 to v2
+    File: oc-mirror-migration-v1-to-v2
+  - Name: Mirroring images for a disconnected installation using the oc-mirror plugin v1
+    File: installing-mirroring-disconnected
+  - Name: Mirroring images for a disconnected installation by using the oc adm command
+    File: installing-mirroring-installation-images
 - Name: Installing a cluster in a disconnected environment
   File: installing
 - Name: Using OLM in disconnected environments
@@ -198,7 +202,7 @@ Topics:
       File: installing-aws-customizations
     - Name: Installing a cluster with network customizations
       File: installing-aws-network-customizations
-    - Name: Installing a cluster in a restricted network
+    - Name: Installing a cluster in a disconnected environment
       File: installing-restricted-networks-aws-installer-provisioned
     - Name: Installing a cluster into an existing VPC
       File: installing-aws-vpc
@@ -228,7 +232,7 @@ Topics:
       File: upi-aws-installation-reqs
     - Name: Installing a cluster using CloudFormation templates
       File: installing-aws-user-infra
-    - Name: Installing a cluster in a restricted network with user-provisioned infrastructure
+    - Name: Installing a cluster in a disconnected environment with user-provisioned infrastructure
       File: installing-restricted-networks-aws
     - Name: Installing an AWS cluster with the support for configuring multi-architecture compute machines
       File: installing-aws-multiarch-support-upi
@@ -261,7 +265,7 @@ Topics:
       File: installing-azure-customizations
     - Name: Installing a cluster with network customizations
       File: installing-azure-network-customizations
-    - Name: Installing a cluster in a restricted network
+    - Name: Installing a cluster in a disconnected environment
       File: installing-restricted-networks-azure-installer-provisioned
     - Name: Installing a cluster into an existing VNet
       File: installing-azure-vnet
@@ -275,7 +279,7 @@ Topics:
     Topics:
     - Name: Preparing to install a cluster
       File: installing-azure-preparing-upi
-    - Name: Installing a cluster in a restricted network with user-provisioned infrastructure
+    - Name: Installing a cluster in a disconnected environment with user-provisioned infrastructure
       File: installing-restricted-networks-azure-user-provisioned
     - Name: Installing a cluster using ARM templates
       File: installing-azure-user-infra
@@ -329,7 +333,7 @@ Topics:
     File: installing-gcp-customizations
   - Name: Installing a cluster on GCP with network customizations
     File: installing-gcp-network-customizations
-  - Name: Installing a cluster on GCP in a restricted network
+  - Name: Installing a cluster on GCP in a disconnected environment
     File: installing-restricted-networks-gcp-installer-provisioned
   - Name: Installing a cluster on GCP into an existing VPC
     File: installing-gcp-vpc
@@ -341,7 +345,7 @@ Topics:
     File: installing-gcp-user-infra
   - Name: Installing a cluster into a shared VPC on GCP using Deployment Manager templates
     File: installing-gcp-user-infra-vpc
-  - Name: Installing a cluster on GCP in a restricted network with user-provisioned infrastructure
+  - Name: Installing a cluster on GCP in a disconnected environment with user-provisioned infrastructure
     File: installing-restricted-networks-gcp
   - Name: Installing a three-node cluster on GCP
     File: installing-gcp-three-node
@@ -371,7 +375,7 @@ Topics:
     File: installing-ibm-cloud-vpc
   - Name: Installing a private cluster on IBM Cloud
     File: installing-ibm-cloud-private
-  - Name: Installing a cluster on IBM Cloud in a restricted network
+  - Name: Installing a cluster on IBM Cloud in a disconnected environment
     File: installing-ibm-cloud-restricted
   - Name: Installation configuration parameters for IBM Cloud
     File: installation-config-parameters-ibm-cloud-vpc
@@ -387,7 +391,7 @@ Topics:
     File: nutanix-failure-domains
   - Name: Installing a cluster on Nutanix
     File: installing-nutanix-installer-provisioned
-  - Name: Installing a cluster on Nutanix in a restricted network
+  - Name: Installing a cluster on Nutanix in a disconnected environment
     File: installing-restricted-networks-nutanix-installer-provisioned
   - Name: Installing a three-node cluster on Nutanix
     File: installing-nutanix-three-node
@@ -409,10 +413,14 @@ Topics:
     File: preparing-to-install-with-agent-based-installer
   - Name: Understanding disconnected installation mirroring
     File: understanding-disconnected-installation-mirroring
-  - Name: Installing a cluster with Agent-based Installer
+  - Name: Installing a cluster
+    File: installing-with-agent-basic
+  - Name: Installing a cluster with customizations
     File: installing-with-agent-based-installer
   - Name: Preparing PXE assets for OCP
     File: prepare-pxe-assets-agent
+  - Name: Preparing installation assets for iSCSI booting
+    File: installing-using-iscsi
   - Name: Preparing an Agent-based installed cluster for the multicluster engine for Kubernetes
     File: preparing-an-agent-based-installed-cluster-for-mce
   - Name: Installation configuration parameters for the Agent-based Installer
@@ -439,7 +447,7 @@ Topics:
       File: installing-bare-metal
     - Name: Installing a user-provisioned bare metal cluster with network customizations
       File: installing-bare-metal-network-customizations
-    - Name: Installing a user-provisioned bare metal cluster on a restricted network
+    - Name: Installing a user-provisioned bare metal cluster on a disconnected environment
       File: installing-restricted-networks-bare-metal
     - Name: Scaling a user-provisioned installation with the bare metal operator
       File: scaling-a-user-provisioned-cluster-with-the-bare-metal-operator
@@ -509,7 +517,7 @@ Topics:
     File: preparing-to-install-on-ibm-power
   - Name: Installing a cluster on IBM Power
     File: installing-ibm-power
-  - Name: Restricted network IBM Power installation
+  - Name: Installing a cluster on IBM Power in a disconnected environment
     File: installing-restricted-networks-ibm-power
   - Name: Installation configuration parameters for IBM Power
     File: installation-config-parameters-ibm-power
@@ -529,7 +537,7 @@ Topics:
     File: installing-ibm-powervs-vpc
   - Name: Installing a private cluster on IBM Power Virtual Server
     File: installing-ibm-power-vs-private-cluster
-  - Name: Installing a cluster on IBM Power Virtual Server in a restricted network
+  - Name: Installing a cluster on IBM Power Virtual Server in a disconnected environment
     File: installing-restricted-networks-ibm-power-vs
   - Name: Uninstalling a cluster on IBM Power Virtual Server
     File: uninstalling-cluster-ibm-power-vs
@@ -549,7 +557,7 @@ Topics:
     File: installing-openstack-installer-custom
   - Name: Installing a cluster on OpenStack on your own infrastructure
     File: installing-openstack-user
-  - Name: Installing a cluster on OpenStack in a restricted network
+  - Name: Installing a cluster on OpenStack in a disconnected environment
     File: installing-openstack-installer-restricted
   - Name: Installing a three-node cluster on OpenStack
     File: installing-openstack-three-node
@@ -575,6 +583,12 @@ Topics:
     File: installing-oci-assisted-installer
   - Name: Installing a cluster on Oracle Cloud Infrastructure by using the Agent-based Installer
     File: installing-oci-agent-based-installer
+  - Name: Installing a cluster on Oracle Compute Cloud@Customer by using the Agent-based Installer
+    File: installing-c3-agent-based-installer
+  - Name: Installing a cluster on Oracle Private Cloud Appliance by using the Agent-based Installer
+    File: installing-pca-agent-based-installer
+  - Name: Installing a cluster on Oracle Compute Cloud@Customer by using the Assisted Installer
+    File: installing-c3-assisted-installer
 - Name: Installing on VMware vSphere
   Dir: installing_vsphere
   Distros: openshift-origin,openshift-enterprise
@@ -595,7 +609,7 @@ Topics:
       File: installing-vsphere-installer-provisioned-customizations
     - Name: Installing a cluster with network customizations
       File: installing-vsphere-installer-provisioned-network-customizations
-    - Name: Installing a cluster in a restricted network
+    - Name: Installing a cluster in a disconnected environment
       File: installing-restricted-networks-installer-provisioned-vsphere
   - Name: User-provisioned infrastructure
     Dir: upi
@@ -609,7 +623,7 @@ Topics:
       File: installing-vsphere
     - Name: Installing a cluster with network customizations
       File: installing-vsphere-network-customizations
-    - Name: Installing a cluster in a restricted network
+    - Name: Installing a cluster in a disconnected environment
       File: installing-restricted-networks-vsphere
   - Name: Assisted Installer
     Distros: openshift-enterprise
@@ -738,10 +752,10 @@ Topics:
 - Name: Preparing to update a cluster
   Dir: preparing_for_updates
   Topics:
-  - Name: Preparing to update to OpenShift Container Platform 4.17
+  - Name: Preparing to update to OpenShift Container Platform 4.19
     File: updating-cluster-prepare
     Distros: openshift-enterprise
-  - Name: Preparing to update to OKD 4.17
+  - Name: Preparing to update to OKD 4.19
     File: updating-cluster-prepare
     Distros: openshift-origin
   - Name: Preparing to update a cluster with manually maintained credentials
@@ -813,7 +827,7 @@ Topics:
     File: using-insights-to-identify-issues-with-your-cluster
   - Name: Using the Insights Operator
     File: using-insights-operator
-  - Name: Using remote health reporting in a restricted network
+  - Name: Using remote health reporting in a disconnected environment
     File: remote-health-reporting-from-restricted-network
   - Name: Importing simple content access entitlements with Insights Operator
     File: insights-operator-simple-access
@@ -883,6 +897,8 @@ Topics:
     File: dynamic-plugins-get-started
   - Name: Deploy your plugin on a cluster
     File: deploy-plugin-cluster
+  - Name: Content Security Policy
+    File: content-security-policy
   - Name: Dynamic plugin example
     File: dynamic-plugin-example
   - Name: Dynamic plugin reference
@@ -1205,6 +1221,8 @@ Topics:
     File: cert-manager-creating-certificate
   - Name: Securing routes with the cert-manager Operator for Red Hat OpenShift
     File: cert-manager-securing-routes
+  - Name: Integrating the cert-manager Operator with Istio-CSR
+    File: cert-manager-operator-integrating-istio
   - Name: Monitoring the cert-manager Operator for Red Hat OpenShift
     File: cert-manager-monitoring
   - Name: Configuring log levels for cert-manager and the cert-manager Operator for Red Hat OpenShift
@@ -1333,12 +1351,8 @@ Name: Networking
 Dir: networking
 Distros: openshift-enterprise,openshift-origin
 Topics:
-- Name: About networking
-  File: about-networking
 - Name: Understanding networking
   File: understanding-networking
-- Name: Zero trust networking
-  File: zero-trust-networking
 - Name: Accessing hosts
   File: accessing-hosts
 - Name: Networking dashboards
@@ -1481,6 +1495,8 @@ Topics:
       File: configuring-egress-firewall-ovn
   - Name: Configuring IPsec encryption
     File: configuring-ipsec-ovn
+  - Name: Zero trust networking
+    File: zero-trust-networking
 - Name: Configuring the Ingress Controller for manual DNS management
   File: ingress-controller-dnsmgt
   Distros: openshift-enterprise,openshift-origin
@@ -1504,16 +1520,12 @@ Topics:
   Topics:
   - Name: About Precision Time Protocol in OpenShift cluster nodes
     File: about-ptp
-  - Name: Configuring Precision Time Protocol devices
+  - Name: Configuring PTP devices
     File: configuring-ptp
   - Name: Developing PTP events consumer applications with the REST API v2
     File: ptp-cloud-events-consumer-dev-reference-v2
-  - Name: Precision Time Protocol events REST API v2 reference
+  - Name: PTP events REST API v2 reference
     File: ptp-events-rest-api-reference-v2
-  - Name: Developing PTP events consumer applications with the REST API v1
-    File: ptp-cloud-events-consumer-dev-reference
-  - Name: Precision Time Protocol events REST API v1 reference
-    File: ptp-events-rest-api-reference
 - Name: CIDR range definitions
   File: cidr-range-definitions
 - Name: Multiple networks
@@ -1568,8 +1580,8 @@ Topics:
     File: configuring-sriov-net-attach
   - Name: Configuring an SR-IOV InfiniBand network attachment
     File: configuring-sriov-ib-attach
-  - Name: Adding a pod to an SR-IOV network
-    File: add-pod
+  - Name: Configuring an RDMA subsystem for SR-IOV
+    File: configuring-sriov-rdma-cni
   - Name: Configuring interface-level network sysctl settings and all-multicast mode for SR-IOV networks
     File: configuring-interface-sysctl-sriov-device
   - Name: Configuring QinQ support for SR-IOV networks
@@ -1655,6 +1667,9 @@ Topics:
   - Name: Configuring ingress cluster traffic using load balancer allowed source ranges
     File: configuring-ingress-cluster-traffic-load-balancer-allowed-source-ranges
     Distros: openshift-enterprise,openshift-origin
+  - Name: Patching existing ingress objects
+    File: configuring-ingress-cluster-patch-fields
+    Distros: openshift-enterprise,openshift-origin
   # Kubernetes NMState (TECHNOLOGY PREVIEW)
 - Name: Kubernetes NMState
   Dir: k8s_nmstate
@@ -1754,18 +1769,16 @@ Topics:
     File: persistent-storage-csi
   - Name: CSI inline ephemeral volumes
     File: ephemeral-storage-csi-inline
-  - Name: Shared Resource CSI Driver Operator
-    File: ephemeral-storage-shared-resource-csi-driver-operator
   - Name: CSI volume snapshots
     File: persistent-storage-csi-snapshots
+  - Name: CSI volume group snapshots
+    File: persistent-storage-csi-group-snapshots
   - Name: CSI volume cloning
     File: persistent-storage-csi-cloning
   - Name: Managing the default storage class
     File: persistent-storage-csi-sc-manage
   - Name: CSI automatic migration
     File: persistent-storage-csi-migration
-  - Name: Detach CSI volumes after non-graceful node shutdown
-    File: persistent-storage-csi-vol-detach-non-graceful-shutdown
   - Name: AWS Elastic Block Store CSI Driver Operator
     File: persistent-storage-csi-ebs
   - Name: AWS Elastic File Service CSI Driver Operator
@@ -1803,6 +1816,9 @@ Topics:
 - Name: Dynamic provisioning
   File: dynamic-provisioning
   Distros: openshift-enterprise,openshift-origin
+- Name: Detach volumes after non-graceful node shutdown
+  File: persistent-storage-csi-vol-detach-non-graceful-shutdown
+  Distros: openshift-enterprise,openshift-origin,openshift-online
 ---
 Name: Registry
 Dir: registry
@@ -2000,21 +2016,6 @@ Topics:
       File: osdk-helm-updating-projects
     - Name: Helm support
       File: osdk-helm-support
-    - Name: Hybrid Helm Operator
-      File: osdk-hybrid-helm
-    - Name: Updating Hybrid Helm-based projects
-      File: osdk-hybrid-helm-updating-projects
-  - Name: Java-based Operators
-    Dir: java
-    Topics:
-    - Name: Getting started
-      File: osdk-java-quickstart
-    - Name: Tutorial
-      File: osdk-java-tutorial
-    - Name: Project layout
-      File: osdk-java-project-layout
-    - Name: Updating Java-based projects
-      File: osdk-java-updating-projects
   - Name: Defining cluster service versions (CSVs)
     File: osdk-generating-csvs
   - Name: Working with bundle images
@@ -2055,7 +2056,7 @@ Topics:
     Distros: openshift-origin
 - Name: Cluster Operators reference
   File: operator-reference
-- Name: OLM v1 (Technology Preview)
+- Name: OLM v1
   Dir: olm_v1
   Distros: openshift-origin,openshift-enterprise
   Topics:
@@ -2088,15 +2089,21 @@ Topics:
     File: rh-catalogs
   - Name: Managing catalogs
     File: managing-catalogs
+  - Name: Catalog content resolution
+    File: catalog-content-resolution
   - Name: Creating catalogs
     File: creating-catalogs
+  - Name: Disconnected environment support in OLM v1
+    File: disconnected-catalogs
 - Name: Cluster extensions
   Dir: ce
   Topics:
   - Name: Managing extensions
     File: managing-ce
-  - Name: Upgrade edges
-    File: upgrade-edges
+  - Name: User access to extension resources
+    File: user-access-resources
+  - Name: Update paths
+    File: update-paths
   - Name: CRD upgrade safety
     File: crd-upgrade-safety
 ---
@@ -2219,10 +2226,6 @@ Topics:
 - Name: Image configuration resources
   File: image-configuration
   Distros: openshift-enterprise,openshift-origin
-- Name: Using templates
-  File: using-templates
-- Name: Using Ruby on Rails
-  File: templates-using-ruby-on-rails
 - Name: Using images
   Dir: using_images
   Distros: openshift-enterprise,openshift-origin
@@ -2254,12 +2257,16 @@ Topics:
 - Name: Creating applications
   Dir: creating_applications
   Topics:
+  - Name: Using templates
+    File: using-templates
   - Name: Creating applications using the Developer perspective
     File: odc-creating-applications-using-developer-perspective
   - Name: Creating applications from installed Operators
     File: creating-apps-from-installed-operators
   - Name: Creating applications by using the CLI
     File: creating-applications-using-cli
+  - Name: Creating applications using Ruby on Rails
+    File: templates-using-ruby-on-rails
 - Name: Viewing application composition by using the Topology view
   File: odc-viewing-application-composition-using-topology-view
 - Name: Exporting applications
@@ -2462,6 +2469,10 @@ Topics:
       File: cluster-api-config-options-aws
     - Name: Cluster API configuration options for Google Cloud Platform
       File: cluster-api-config-options-gcp
+    - Name: Cluster API configuration options for Microsoft Azure
+      File: cluster-api-config-options-azure
+    - Name: Cluster API configuration options for Red Hat OpenStack Platform
+      File: cluster-api-config-options-rhosp
     - Name: Cluster API configuration options for VMware vSphere
       File: cluster-api-config-options-vsphere
 #  - Name: Cluster API resiliency and recovery
@@ -2564,6 +2575,8 @@ Topics:
   File: hcp-using-feature-gates
 - Name: Observability for hosted control planes
   File: hcp-observability
+- Name: Networking for hosted control planes
+  File: hcp-networking
 - Name: Troubleshooting hosted control planes
   File: hcp-troubleshooting
 - Name: Destroying a hosted cluster
@@ -2864,7 +2877,7 @@ Topics:
     File: creating-windows-machineset-vsphere
 - Name: Scheduling Windows container workloads
   File: scheduling-windows-workloads
-- Name: Windows node upgrades
+- Name: Windows node updates
   File: windows-node-upgrades
 - Name: Using Bring-Your-Own-Host Windows instances as nodes
   File: byoh-windows-instance
@@ -2890,62 +2903,119 @@ Topics:
   Topics:
   - Name: About Observability
     File: index
+- Name: Cluster Observability Operator
+  Dir: cluster_observability_operator
+  Distros: openshift-enterprise,openshift-origin
+  Topics:
+  - Name: Cluster Observability Operator release notes
+    File: cluster-observability-operator-release-notes
+  - Name: Cluster Observability Operator overview
+    File: cluster-observability-operator-overview
+  - Name: Installing the Cluster Observability Operator
+    File: installing-the-cluster-observability-operator
+  - Name: Configuring the Cluster Observability Operator to monitor a service
+    File: configuring-the-cluster-observability-operator-to-monitor-a-service
+  - Name: Observability UI plugins
+    Dir: ui_plugins
+    Distros: openshift-enterprise,openshift-origin
+    Topics:
+    - Name: Observability UI plugins overview
+      File: observability-ui-plugins-overview
+    - Name: Monitoring UI plugin
+      File: monitoring-ui-plugin
+    - Name: Logging UI plugin
+      File: logging-ui-plugin
+    - Name: Distributed tracing UI plugin
+      File: distributed-tracing-ui-plugin
+    - Name: Troubleshooting UI plugin
+      File: troubleshooting-ui-plugin
+#    - Name: Dashboard UI plugin
+#      File: dashboard-ui-plugin
 - Name: Monitoring
   Dir: monitoring
   Distros: openshift-enterprise,openshift-origin
   Topics:
-  - Name: Monitoring overview
-    File: monitoring-overview
-  - Name: Common monitoring configuration scenarios
-    File: common-monitoring-configuration-scenarios
-  - Name: Configuring the monitoring stack
-    File: configuring-the-monitoring-stack
-  - Name: Enabling monitoring for user-defined projects
-    File: enabling-monitoring-for-user-defined-projects
-  - Name: Enabling alert routing for user-defined projects
-    File: enabling-alert-routing-for-user-defined-projects
-  - Name: Managing metrics
-    File: managing-metrics
+  - Name: About OpenShift Container Platform monitoring
+    Dir: about-ocp-monitoring
+    Topics:
+    - Name: About OpenShift Container Platform monitoring
+      File: about-ocp-monitoring
+    - Name: Monitoring stack architecture
+      File: monitoring-stack-architecture
+    - Name: Key concepts
+      File: key-concepts
+  - Name: Getting started
+    Dir: getting-started
+    Topics:
+    - Name: Maintenance and support for monitoring
+      File: maintenance-and-support-for-monitoring
+    - Name: Core platform monitoring first steps
+      File: core-platform-monitoring-first-steps
+    - Name: User workload monitoring first steps
+      File: user-workload-monitoring-first-steps
+    - Name: Developer and non-administrator steps
+      File: developer-and-non-administrator-steps
+  - Name: Configuring core platform monitoring
+    Dir: configuring-core-platform-monitoring
+    Topics:
+    - Name: Preparing to configure the monitoring stack
+      File: preparing-to-configure-the-monitoring-stack
+    - Name: Configuring performance and scalability
+      File: configuring-performance-and-scalability
+    - Name: Storing and recording data
+      File: storing-and-recording-data
+    - Name: Configuring metrics
+      File: configuring-metrics
+    - Name: Configuring alerts and notifications
+      File: configuring-alerts-and-notifications
+  - Name: Configuring user workload monitoring
+    Dir: configuring-user-workload-monitoring
+    Topics:
+    - Name: Preparing to configure the monitoring stack
+      File: preparing-to-configure-the-monitoring-stack-uwm
+    - Name: Configuring performance and scalability
+      File: configuring-performance-and-scalability-uwm
+    - Name: Storing and recording data
+      File: storing-and-recording-data-uwm
+    - Name: Configuring metrics
+      File: configuring-metrics-uwm
+    - Name: Configuring alerts and notifications
+      File: configuring-alerts-and-notifications-uwm
+  - Name: Accessing metrics
+    Dir: accessing-metrics
+    Topics:
+    - Name: Accessing metrics as an administrator
+      File: accessing-metrics-as-an-administrator
+    - Name: Accessing metrics as a developer
+      File: accessing-metrics-as-a-developer
+    - Name: Accessing monitoring APIs by using the CLI
+      File: accessing-monitoring-apis-by-using-the-cli
   - Name: Managing alerts
-    File: managing-alerts
-  - Name: Reviewing monitoring dashboards
-    File: reviewing-monitoring-dashboards
-  - Name: Accessing monitoring APIs by using the CLI
-    File: accessing-third-party-monitoring-apis
+    Dir: managing-alerts
+    Topics:
+    - Name: Managing alerts as an administrator
+      File: managing-alerts-as-an-administrator
+    - Name: Managing alerts as a developer
+      File: managing-alerts-as-a-developer
   - Name: Troubleshooting monitoring issues
     File: troubleshooting-monitoring-issues
   - Name: Config map reference for the Cluster Monitoring Operator
     File: config-map-reference-for-the-cluster-monitoring-operator
+  - Name: Monitoring clusters that run on RHOSO
+    File: shiftstack-prometheus-configuration
 - Name: Logging
   Dir: logging
   Distros: openshift-enterprise,openshift-origin
   Topics:
-  - Name: Release notes
-    Dir: logging_release_notes
-    Topics:
-    - Name: Logging 5.9
-      File: logging-5-9-release-notes
-    - Name: Logging 5.8
-      File: logging-5-8-release-notes
-    - Name: Logging 5.7
-      File: logging-5-7-release-notes
-  - Name: Logging 6.0
-    Dir: logging-6.0
-    Topics:
-    - Name: Release notes
-      File: log6x-release-notes
-    - Name: About logging 6.0
-      File: log6x-about
-    - Name: Upgrading to Logging 6.0
-      File: log6x-upgrading-to-6
-    - Name: Configuring log forwarding
-      File: log6x-clf
-    - Name: Configuring LokiStack storage
-      File: log6x-loki
-    - Name: Visualization for logging
-      File: log6x-visual
-    # - Name: API reference 6.0
-    #   File: log6x-api-reference
+#  - Name: Release notes
+#    Dir: logging_release_notes
+#    Topics:
+#    - Name: Logging 5.9
+#      File: logging-5-9-release-notes
+#    - Name: Logging 5.8
+#      File: logging-5-8-release-notes
+#    - Name: Logging 5.7
+#      File: logging-5-7-release-notes
   - Name: Logging 6.1
     Dir: logging-6.1
     Topics:
@@ -2963,110 +3033,107 @@ Topics:
       File: log6x-opentelemetry-data-model-6.1
     - Name: Visualization for logging
       File: log6x-visual-6.1
-  - Name: Support
-    File: cluster-logging-support
-  - Name: Troubleshooting logging
-    Dir: troubleshooting
-    Topics:
-    - Name: Viewing Logging status
-      File: cluster-logging-cluster-status
-    - Name: Troubleshooting log forwarding
-      File: log-forwarding-troubleshooting
-    - Name: Troubleshooting logging alerts
-      File: troubleshooting-logging-alerts
-    - Name: Viewing the status of the Elasticsearch log store
-      File: cluster-logging-log-store-status
-  - Name: About Logging
-    File: cluster-logging
-  - Name: Installing Logging
-    File: cluster-logging-deploying
-  - Name: Updating Logging
-    File: cluster-logging-upgrading
-    Distros: openshift-enterprise,openshift-origin
-  - Name: Visualizing logs
-    Dir: log_visualization
-    Topics:
-    - Name: About log visualization
-      File: log-visualization
-    - Name: Log visualization with the web console
-      File: log-visualization-ocp-console
-    - Name: Viewing cluster dashboards
-      File: cluster-logging-dashboards
-    - Name: Log visualization with Kibana
-      File: logging-kibana
-  - Name: Configuring your Logging deployment
-    Dir: config
-    Distros: openshift-enterprise,openshift-origin
-    Topics:
-    - Name: Configuring CPU and memory limits for Logging components
-      File: cluster-logging-memory
-    - Name: Configuring systemd-journald for Logging
-      File: cluster-logging-systemd
-  - Name: Log collection and forwarding
-    Dir: log_collection_forwarding
-    Topics:
-    - Name: About log collection and forwarding
-      File: log-forwarding
-    - Name: Log output types
-      File: logging-output-types
-    - Name: Enabling JSON log forwarding
-      File: cluster-logging-enabling-json-logging
-    - Name: Configuring log forwarding
-      File: configuring-log-forwarding
-    - Name: Configuring the logging collector
-      File: cluster-logging-collector
-    - Name: Collecting and storing Kubernetes events
-      File: cluster-logging-eventrouter
-  - Name: Log storage
-    Dir: log_storage
-    Topics:
-    - Name: About log storage
-      File: about-log-storage
-    - Name: Installing log storage
-      File: installing-log-storage
-    - Name: Configuring the LokiStack log store
-      File: cluster-logging-loki
-    - Name: Configuring the Elasticsearch log store
-      File: logging-config-es-store
-  - Name: Logging alerts
-    Dir: logging_alerts
-    Topics:
-    - Name: Default logging alerts
-      File: default-logging-alerts
-    - Name: Custom logging alerts
-      File: custom-logging-alerts
-  - Name: Performance and reliability tuning
-    Dir: performance_reliability
-    Topics:
-    - Name: Flow control mechanisms
-      File: logging-flow-control-mechanisms
-    - Name: Filtering logs by content
-      File: logging-content-filtering
-    - Name: Filtering logs by metadata
-      File: logging-input-spec-filtering
-  - Name: Scheduling resources
-    Dir: scheduling_resources
-    Topics:
-    - Name: Using node selectors to move logging resources
-      File: logging-node-selectors
-    - Name: Using tolerations to control logging pod placement
-      File: logging-taints-tolerations
-  - Name: Uninstalling Logging
-    File: cluster-logging-uninstall
-  - Name: Exported fields
-    File: cluster-logging-exported-fields
-    Distros: openshift-enterprise,openshift-origin
-  - Name: API reference
-    Dir: api_reference
-    Topics:
+#  - Name: Support
+#    File: cluster-logging-support
+#  - Name: Troubleshooting logging
+#    Dir: troubleshooting
+#    Topics:
+#    - Name: Viewing Logging status
+#      File: cluster-logging-cluster-status
+#    - Name: Troubleshooting log forwarding
+#      File: log-forwarding-troubleshooting
+#    - Name: Troubleshooting logging alerts
+#      File: troubleshooting-logging-alerts
+#      File: cluster-logging-log-store-status
+#  - Name: About Logging
+#    File: cluster-logging
+#  - Name: Installing Logging
+#    File: cluster-logging-deploying
+#  - Name: Updating Logging
+#    File: cluster-logging-upgrading
+#    Distros: openshift-enterprise,openshift-origin
+#  - Name: Visualizing logs
+#    Topics:
+#    - Name: About log visualization
+#      File: log-visualization
+#    - Name: Log visualization with the web console
+#      File: log-visualization-ocp-console
+#    - Name: Viewing cluster dashboards
+#      File: cluster-logging-dashboards
+#    - Name: Log visualization with Kibana
+#      File: logging-kibana
+#  - Name: Configuring your Logging deployment
+#    Dir: config
+#    Distros: openshift-enterprise,openshift-origin
+#    Topics:
+#    - Name: Configuring CPU and memory limits for Logging components
+#      File: cluster-logging-memory
+#    - Name: Configuring systemd-journald for Logging
+#      File: cluster-logging-systemd
+#  - Name: Log collection and forwarding
+#    Dir: log_collection_forwarding
+#    Topics:
+#    - Name: About log collection and forwarding
+#      File: log-forwarding
+#    - Name: Log output types
+#      File: logging-output-types
+#    - Name: Enabling JSON log forwarding
+#      File: cluster-logging-enabling-json-logging
+#    - Name: Configuring log forwarding
+#      File: configuring-log-forwarding
+#    - Name: Configuring the logging collector
+#      File: cluster-logging-collector
+#    - Name: Collecting and storing Kubernetes events
+#      File: cluster-logging-eventrouter
+#  - Name: Log storage
+#    Dir: log_storage
+#    Topics:
+#    - Name: About log storage
+#      File: about-log-storage
+#      File: installing-log-storage
+#  - Name: Configuring the LokiStack log store
+#      File: cluster-logging-loki
+#    - Name: Configuring the Elasticsearch log store
+#      File: logging-config-es-store
+#  - Name: Logging alerts
+#    Dir: logging_alerts
+#    Topics:
+#    - Name: Default logging alerts
+#      File: default-logging-alerts
+#    - Name: Custom logging alerts
+#      File: custom-logging-alerts
+#  - Name: Performance and reliability tuning
+#    Dir: performance_reliability
+#    Topics:
+#    - Name: Flow control mechanisms
+#      File: logging-flow-control-mechanisms
+#    - Name: Filtering logs by content
+#      File: logging-content-filtering
+#    - Name: Filtering logs by metadata
+#      File: logging-input-spec-filtering
+#  - Name: Scheduling resources
+#    Dir: scheduling_resources
+#    Topics:
+#    - Name: Using node selectors to move logging resources
+#      File: logging-node-selectors
+#    - Name: Using tolerations to control logging pod placement
+#      File: logging-taints-tolerations
+#  - Name: Uninstalling Logging
+#    File: cluster-logging-uninstall
+#  - Name: Exported fields
+#    File: cluster-logging-exported-fields
+#    Distros: openshift-enterprise,openshift-origin
+#  - Name: API reference
+#    Dir: api_reference
+#    Topics:
   #  - Name: 5.8 Logging API reference
   #    File: logging-5-8-reference
   #  - Name: 5.7 Logging API reference
   #    File: logging-5-7-reference
-    - Name: 5.6 Logging API reference
-      File: logging-5-6-reference
-  - Name: Glossary
-    File: logging-common-terms
+#    - Name: 5.6 Logging API reference
+#      File: logging-5-6-reference
+#  - Name: Glossary
+#    File: logging-common-terms
 - Name: Distributed tracing
   Dir: distr_tracing
   Distros: openshift-enterprise
@@ -3113,6 +3180,8 @@ Topics:
   - Name: Configuring the Collector
     Dir: otel-collector
     Topics:
+    - Name: Collector options
+      File: otel-collector-configuration-intro
     - Name: Receivers
       File: otel-collector-receivers
     - Name: Processors
@@ -3204,32 +3273,6 @@ Topics:
     File: visualizing-power-monitoring-metrics
   - Name: Uninstalling power monitoring
     File: uninstalling-power-monitoring
-- Name: Cluster Observability Operator
-  Dir: cluster_observability_operator
-  Distros: openshift-enterprise,openshift-origin
-  Topics:
-  - Name: Cluster Observability Operator release notes
-    File: cluster-observability-operator-release-notes
-  - Name: Cluster Observability Operator overview
-    File: cluster-observability-operator-overview
-  - Name: Installing the Cluster Observability Operator
-    File: installing-the-cluster-observability-operator
-  - Name: Configuring the Cluster Observability Operator to monitor a service
-    File: configuring-the-cluster-observability-operator-to-monitor-a-service
-  - Name: Observability UI plugins
-    Dir: ui_plugins
-    Distros: openshift-enterprise,openshift-origin
-    Topics:
-    - Name: Observability UI plugins overview
-      File: observability-ui-plugins-overview
-    - Name: Dashboard UI plugin
-      File: dashboard-ui-plugin
-    - Name: Distributed tracing UI plugin
-      File: distributed-tracing-ui-plugin
-    - Name: Troubleshooting UI plugin
-      File: troubleshooting-ui-plugin
-    - Name: Logging UI plugin
-      File: logging-ui-plugin
 ---
 Name: Scalability and performance
 Dir: scalability_and_performance
@@ -3247,38 +3290,10 @@ Topics:
     File: recommended-infrastructure-practices
   - Name: Recommended etcd practices
     File: recommended-etcd-practices
-- Name: Reference design specifications
-  Dir: telco_ref_design_specs
-  Distros: openshift-origin,openshift-enterprise
-  Topics:
-  - Name: Telco reference design specifications
-    File: telco-ref-design-specs-overview
-  - Name: Telco RAN DU reference design specification
-    Dir: ran
-    Topics:
-    - Name: Telco RAN DU reference design overview
-      File: telco-ran-ref-design-spec
-    - Name: Telco RAN DU use model overview
-      File: telco-ran-du-overview
-    - Name: RAN DU reference design components
-      File: telco-ran-ref-du-components
-    - Name: RAN DU reference design configuration CRs
-      File: telco-ran-ref-du-crs
-    - Name: Telco RAN DU software specifications
-      File: telco-ran-ref-software-artifacts
-  - Name: Telco core reference design specification
-    Dir: core
-    Topics:
-    - Name: Telco core reference design overview
-      File: telco-core-rds-overview
-    - Name: Telco core use model overview
-      File: telco-core-rds-use-cases
-    - Name: Core reference design components
-      File: telco-core-ref-design-components
-    - Name: Core reference design configuration CRs
-      File: telco-core-ref-crs
-    - Name: Telco core software specifications
-      File: telco-core-ref-software-artifacts
+- Name: Telco core reference design specifications
+  File: telco-core-rds
+- Name: Telco RAN DU reference design specifications
+  File: telco-ran-du-rds
 - Name: Comparing cluster configurations
   Dir: cluster-compare
   Distros: openshift-origin,openshift-enterprise
@@ -3330,20 +3345,16 @@ Topics:
 - Name: What huge pages do and how they are consumed by apps
   File: what-huge-pages-do-and-how-they-are-consumed-by-apps
   Distros: openshift-origin,openshift-enterprise
-- Name: Low latency tuning
-  Dir: low_latency_tuning
-  Distros: openshift-origin,openshift-enterprise
-  Topics:
-  - Name: Understanding low latency
-    File: cnf-understanding-low-latency
-  - Name: Tuning nodes for low latency with the performance profile
-    File: cnf-tuning-low-latency-nodes-with-perf-profile
-  - Name: Provisioning real-time and low latency workloads
-    File: cnf-provisioning-low-latency-workloads
-  - Name: Debugging low latency tuning
-    File: cnf-debugging-low-latency-tuning-status
-  - Name: Performing latency tests for platform verification
-    File: cnf-performing-platform-verification-latency-tests
+- Name: Understanding low latency
+  File: cnf-understanding-low-latency
+- Name: Tuning nodes for low latency with the performance profile
+  File: cnf-tuning-low-latency-nodes-with-perf-profile
+- Name: Provisioning real-time and low latency workloads
+  File: cnf-provisioning-low-latency-workloads
+- Name: Debugging low latency tuning
+  File: cnf-debugging-low-latency-tuning-status
+- Name: Performing latency tests for platform verification
+  File: cnf-performing-platform-verification-latency-tests
 - Name: Improving cluster stability in high latency environments using worker latency profiles
   File: scaling-worker-latency-profiles
   Distros: openshift-origin,openshift-enterprise
@@ -3513,6 +3524,8 @@ Topics:
   File: psap-node-feature-discovery-operator
 - Name: Kernel Module Management Operator
   File: kmm-kernel-module-management
+- Name: Kernel Module Management Operator release notes
+  File: kmm-release-notes
 ---
 Name: Hardware accelerators
 Dir: hardware_accelerators
@@ -3533,6 +3546,8 @@ Topics:
   File: graceful-cluster-shutdown
 - Name: Restarting a cluster gracefully
   File: graceful-cluster-restart
+- Name: Hibernating a cluster
+  File: hibernating-cluster
 - Name: OADP Application backup and restore
   Dir: application_backup_and_restore
   Topics:
@@ -3625,6 +3640,11 @@ Topics:
     Topics:
     - Name: Backing up applications on AWS STS using OADP
       File: oadp-aws-sts
+  - Name: OADP and 3scale
+    Dir: oadp-3scale
+    Topics:
+    - Name: Backing up and restoring 3scale by using OADP
+      File: backing-up-and-restoring-3scale-by-using-oadp
   - Name: OADP Data Mover
     Dir: installing
     Topics:
@@ -3652,6 +3672,8 @@ Topics:
     Topics:
     - Name: About disaster recovery
       File: about-disaster-recovery
+    - Name: Quorum restoration
+      File: quorum-restoration
     - Name: Restoring to a previous cluster state
       File: scenario-2-restoring-cluster-state
     - Name: Recovering from expired control plane certificates
@@ -3681,7 +3703,7 @@ Topics:
   File: about-mtc-3-4
 - Name: Installing MTC
   File: installing-3-4
-- Name: Installing MTC in a restricted network environment
+- Name: Installing MTC in a disconnected environment
   File: installing-restricted-3-4
 - Name: Upgrading MTC
   File: upgrading-3-4
@@ -3713,7 +3735,7 @@ Topics:
     File: mtc-release-notes-1-5
 - Name: Installing MTC
   File: installing-mtc
-- Name: Installing MTC in a restricted network environment
+- Name: Installing MTC in a disconnected environment
   File: installing-mtc-restricted
 - Name: Upgrading MTC
   File: upgrading-mtc
@@ -4559,28 +4581,28 @@ Topics:
 - Name: Advanced VM creation
   Dir: creating_vms_advanced
   Topics:
-# - Name: Overview
-#    File: virt-advanced-vm-overview
-  - Name: Creating VMs in the web console
-    Dir: creating_vms_advanced_web
-    Topics:
-    - Name: Creating VMs from Red Hat images
-      File: virt-creating-vms-from-rh-images-overview
-    - Name: Creating VMs by importing images from web pages
-      File: virt-creating-vms-from-web-images
-    - Name: Creating VMs by uploading images
-      File: virt-creating-vms-uploading-images
-    - Name: Cloning VMs
-      File: virt-cloning-vms
-  - Name: Creating VMs using the CLI
-    Dir: creating_vms_cli
-    Topics:
-    - Name: Creating virtual machines from the command line
-      File: virt-creating-vms-from-cli
-    - Name: Creating VMs by using container disks
-      File: virt-creating-vms-from-container-disks
-    - Name: Creating VMs by cloning PVCs
-      File: virt-creating-vms-by-cloning-pvcs
+    - Name: Advanced virtual machine creation overview
+      File: advanced-vm-creation-overview
+    - Name: Creating VMs in the web console
+      Dir: creating_vms_advanced_web
+      Topics:
+        - Name: Creating VMs from Red Hat images
+          File: virt-creating-vms-from-rh-images-overview
+        - Name: Creating VMs by importing images from web pages
+          File: virt-creating-vms-from-web-images
+        - Name: Creating VMs by uploading images
+          File: virt-creating-vms-uploading-images
+        - Name: Cloning VMs
+          File: virt-cloning-vms
+    - Name: Creating VMs using the CLI
+      Dir: creating_vms_cli
+      Topics:
+        - Name: Creating virtual machines from the command line
+          File: virt-creating-vms-from-cli
+        - Name: Creating VMs by using container disks
+          File: virt-creating-vms-from-container-disks
+        - Name: Creating VMs by cloning PVCs
+          File: virt-creating-vms-by-cloning-pvcs
 - Name: Managing VMs
   Dir: managing_vms
   Topics:
@@ -4611,6 +4633,8 @@ Topics:
     Topics:
     - Name: Working with resource quotas for virtual machines
       File: virt-working-with-resource-quotas-for-vms
+    - Name: Configuring the Application-Aware Quota Operator
+      File: virt-understanding-aaq-operator
     - Name: Specifying nodes for virtual machines
       File: virt-specifying-nodes-for-vms
     - Name: Configuring the default CPU model
@@ -4629,6 +4653,8 @@ Topics:
       File: virt-configuring-pci-passthrough
     - Name: Configuring virtual GPUs
       File: virt-configuring-virtual-gpus
+    - Name: Configuring USB host passthrough
+      File: virt-configuring-usb-host-passthrough
     - Name: Enabling descheduler evictions on virtual machines
       File: virt-enabling-descheduler-evictions
     - Name: About high availability for virtual machines
@@ -4639,6 +4665,8 @@ Topics:
       File: virt-assigning-compute-resources
     - Name: About multi-queue functionality
       File: virt-about-multi-queue
+    - Name: Managing virtual machines by using OpenShift GitOps
+      File: virt-managing-virtual-machines-by-using-openshift-gitops
   - Name: VM disks
     Dir: virtual_disks
     Topics:
@@ -4648,6 +4676,8 @@ Topics:
       File: virt-expanding-vm-disks
     - Name: Configuring shared volumes
       File: virt-configuring-shared-volumes-for-vms
+    - Name: Migrating VM disks to a different storage class
+      File: virt-migrating-storage-class
 - Name: Networking
   Dir: vm_networking
   Topics:
@@ -4655,6 +4685,8 @@ Topics:
     File: virt-networking-overview
   - Name: Connecting a VM to the default pod network
     File: virt-connecting-vm-to-default-pod-network
+  - Name: Connecting a VM to a primary user-defined network
+    File: virt-connecting-vm-to-primary-udn
   - Name: Exposing a VM by using a service
     File: virt-exposing-vm-with-service
   - Name: Accessing a VM by using its internal FQDN
diff --git a/_topic_maps/_topic_map_ms.yml b/_topic_maps/_topic_map_ms.yml
index f78443ff03da..c75992c36dec 100644
--- a/_topic_maps/_topic_map_ms.yml
+++ b/_topic_maps/_topic_map_ms.yml
@@ -33,8 +33,8 @@ Name: Red Hat build of MicroShift release notes
 Dir: microshift_release_notes
 Distros: microshift
 Topics:
-- Name: Red Hat build of MicroShift 4.18 release notes
-  File: microshift-4-18-release-notes
+- Name: Red Hat build of MicroShift 4.19 release notes
+  File: microshift-4-19-release-notes
 ---
 Name: Getting ready to install MicroShift
 Dir: microshift_install_get_ready
@@ -76,8 +76,19 @@ Name: Installing with RHEL image mode
 Dir: microshift_install_bootc
 Distros: microshift
 Topics:
-- Name: Installing with RHEL image mode
-  File: microshift-install-rhel-image-mode
+- Name: Understanding image mode for RHEL
+  File: microshift-about-rhel-image-mode
+- Name: Installing a bootc image
+  File: microshift-install-bootc-image
+- Name: Running the bootc image
+  File: microshift-install-running-bootc-image-vm
+---
+Name: Using RHEL Kickstarts
+Dir: microshift_install_kickstarts
+Distros: microshift
+Topics:
+- Name: Using a Kickstart file for automating installation
+  File: microshift-rhel-kickstarts
 ---
 Name: Updating
 Dir: microshift_updating
@@ -104,6 +115,8 @@ Topics:
   File: microshift-getting-cluster-id
 - Name: Getting support
   File: microshift-getting-support
+- Name: Remote health monitoring with a connected cluster
+  File: microshift-remote-cluster-monitoring
 ---
 Name: Configuring
 Dir: microshift_configuring
@@ -115,16 +128,21 @@ Topics:
   File: microshift-nw-ipv6-config
 - Name: Using ingress control for a MicroShift cluster
   File: microshift-ingress-controller
-- Name: Cluster access with kubeconfig
-  File: microshift-cluster-access-kubeconfig
-- Name: Using custom certificate authorities
-  File: microshift-custom-ca
-- Name: Checking the status of Greenboot health checks
-  File: microshift-greenboot-checking-status
-- Name: Configuring audit logging policies
-  File: microshift-audit-logs-config
 - Name: Disabling LVMS CSI provider and CSI snapshot
   File: microshift-disable-lvms-csi-provider-csi-snapshot
+- Name: Checking the status of Greenboot health checks
+  File: microshift-greenboot-checking-status
+- Name: Cluster access with kubeconfig
+  File: microshift-cluster-access-kubeconfig
+- Name: Configuring MicroShift authentication and security
+  Dir: microshift_auth_security
+  Topics:
+  - Name: Using custom certificate authorities
+    File: microshift-custom-ca
+  - Name: Configuring TLS security profiles
+    File: microshift-tls-config
+  - Name: Configuring audit logging policies
+    File: microshift-audit-logs-config
 - Name: Configuring low latency
   Dir: microshift_low_latency
   Topics:
diff --git a/_topic_maps/_topic_map_osd.yml b/_topic_maps/_topic_map_osd.yml
index 430662b2a999..e4174f68a165 100644
--- a/_topic_maps/_topic_map_osd.yml
+++ b/_topic_maps/_topic_map_osd.yml
@@ -103,10 +103,10 @@ Distros: openshift-dedicated
 Topics:
 - Name: Limits and scalability
   File: osd-limits-scalability
-- Name: Customer Cloud Subscriptions on AWS
-  File: aws-ccs
 - Name: Customer Cloud Subscriptions on GCP
   File: gcp-ccs
+- Name: Customer Cloud Subscriptions on AWS
+  File: aws-ccs
 ---
 Name: Getting started
 Dir: osd_getting_started
@@ -210,9 +210,8 @@ Topics:
     File: troubleshooting-operator-issues
   - Name: Investigating pod issues
     File: investigating-pod-issues
-# Hiding from ROSA and OSD until it is decided who should port the Build book
-#  - Name: Troubleshooting the Source-to-Image process
-#    File: troubleshooting-s2i
+  - Name: Troubleshooting the Source-to-Image process
+    File: troubleshooting-s2i
   - Name: Troubleshooting storage issues
     File: troubleshooting-storage-issues
 # Not supported per WINC team
@@ -583,10 +582,6 @@ Topics:
 - Name: Image configuration resources
   File: image-configuration
   Distros: openshift-dedicated
-- Name: Using templates
-  File: using-templates
-- Name: Using Ruby on Rails
-  File: templates-using-ruby-on-rails
 - Name: Using images
   Dir: using_images
   Distros: openshift-dedicated
@@ -784,21 +779,6 @@ Topics:
       File: osdk-helm-updating-projects
     - Name: Helm support
       File: osdk-helm-support
-#   - Name: Hybrid Helm Operator  <= Tech Preview
-#     File: osdk-hybrid-helm
-#   - Name: Updating Hybrid Helm-based projects  <= Tech Preview
-#     File: osdk-hybrid-helm-updating-projects
-# - Name: Java-based Operators  <= Tech Preview
-#   Dir: java
-#   Topics:
-#   - Name: Getting started
-#     File: osdk-java-quickstart
-#   - Name: Tutorial
-#     File: osdk-java-tutorial
-#   - Name: Project layout
-#     File: osdk-java-project-layout
-#   - Name: Updating Java-based projects
-#     File: osdk-java-updating-projects
   - Name: Defining cluster service versions (CSVs)
     File: osdk-generating-csvs
   - Name: Working with bundle images
@@ -872,6 +852,10 @@ Topics:
   Topics:
   - Name: About the OVN-Kubernetes network plugin
     File: about-ovn-kubernetes
+  - Name: Migrating from the OpenShift SDN network plugin
+    File: migrate-from-openshift-sdn-osd
+  # - Name: Migrating from the OpenShift SDN network plugin
+    # File: migrate-from-openshift-sdn
 - Name: OpenShift SDN network plugin
   Dir: ovn_kubernetes_network_provider
   Topics:
@@ -904,12 +888,16 @@ Topics:
 - Name: Creating applications
   Dir: creating_applications
   Topics:
+  - Name: Using templates
+    File: using-templates
   - Name: Creating applications using the Developer perspective
     File: odc-creating-applications-using-developer-perspective
   - Name: Creating applications from installed Operators
     File: creating-apps-from-installed-operators
   - Name: Creating applications using the CLI
     File: creating-applications-using-cli
+  - Name: Creating applications using Ruby on Rails
+    File: templates-using-ruby-on-rails
 - Name: Viewing application composition using the Topology view
   File: odc-viewing-application-composition-using-topology-view
 # cannot create required namespace
@@ -1243,120 +1231,118 @@ Topics:
     File: troubleshooting-monitoring-issues
   - Name: Config map reference for the Cluster Monitoring Operator
     File: config-map-reference-for-the-cluster-monitoring-operator
-- Name: Logging
-  Dir: logging
-  Distros: openshift-dedicated
-  Topics:
-  - Name: Release notes
-    Dir: logging_release_notes
-    Topics:
-    - Name: Logging 5.9
-      File: logging-5-9-release-notes
-    - Name: Logging 5.8
-      File: logging-5-8-release-notes
-    - Name: Logging 5.7
-      File: logging-5-7-release-notes
-  - Name: Support
-    File: cluster-logging-support
-  - Name: Troubleshooting logging
-    Dir: troubleshooting
-    Topics:
-    - Name: Viewing Logging status
-      File: cluster-logging-cluster-status
-    - Name: Troubleshooting log forwarding
-      File: log-forwarding-troubleshooting
-    - Name: Troubleshooting logging alerts
-      File: troubleshooting-logging-alerts
-    - Name: Viewing the status of the Elasticsearch log store
-      File: cluster-logging-log-store-status
-  - Name: About Logging
-    File: cluster-logging
-  - Name: Installing Logging
-    File: cluster-logging-deploying
-  - Name: Updating Logging
-    File: cluster-logging-upgrading
-  - Name: Visualizing logs
-    Dir: log_visualization
-    Topics:
-    - Name: About log visualization
-      File: log-visualization
-    - Name: Log visualization with the web console
-      File: log-visualization-ocp-console
-    - Name: Viewing cluster dashboards
-      File: cluster-logging-dashboards
-    - Name: Log visualization with Kibana
-      File: logging-kibana
-  - Name: Configuring your Logging deployment
-    Dir: config
-    Topics:
-    - Name: Configuring CPU and memory limits for Logging components
-      File: cluster-logging-memory
-    #- Name: Configuring systemd-journald and Fluentd
-    #  File: cluster-logging-systemd
-  - Name: Log collection and forwarding
-    Dir: log_collection_forwarding
-    Topics:
-    - Name: About log collection and forwarding
-      File: log-forwarding
-    - Name: Log output types
-      File: logging-output-types
-    - Name: Enabling JSON log forwarding
-      File: cluster-logging-enabling-json-logging
-    - Name: Configuring log forwarding
-      File: configuring-log-forwarding
-    - Name: Configuring the logging collector
-      File: cluster-logging-collector
-    - Name: Collecting and storing Kubernetes events
-      File: cluster-logging-eventrouter
-  - Name: Log storage
-    Dir: log_storage
-    Topics:
-    - Name: About log storage
-      File: about-log-storage
-    - Name: Installing log storage
-      File: installing-log-storage
-    - Name: Configuring the LokiStack log store
-      File: cluster-logging-loki
-    - Name: Configuring the Elasticsearch log store
-      File: logging-config-es-store
-  - Name: Logging alerts
-    Dir: logging_alerts
-    Topics:
-    - Name: Default logging alerts
-      File: default-logging-alerts
-    - Name: Custom logging alerts
-      File: custom-logging-alerts
-  - Name: Performance and reliability tuning
-    Dir: performance_reliability
-    Topics:
-    - Name: Flow control mechanisms
-      File: logging-flow-control-mechanisms
-    - Name: Filtering logs by content
-      File: logging-content-filtering
-    - Name: Filtering logs by metadata
-      File: logging-input-spec-filtering
-  - Name: Scheduling resources
-    Dir: scheduling_resources
-    Topics:
-    - Name: Using node selectors to move logging resources
-      File: logging-node-selectors
-    - Name: Using tolerations to control logging pod placement
-      File: logging-taints-tolerations
-  - Name: Uninstalling Logging
-    File: cluster-logging-uninstall
-  - Name: Exported fields
-    File: cluster-logging-exported-fields
-  - Name: API reference
-    Dir: api_reference
-    Topics:
+#- Name: Logging
+#  Dir: logging
+#  Distros: openshift-dedicated
+#  Topics:
+#  - Name: Release notes
+#    Dir: logging_release_notes
+#    Topics:
+#    - Name: Logging 5.9
+#      File: logging-5-9-release-notes
+#    - Name: Logging 5.8
+#      File: logging-5-8-release-notes
+#    - Name: Logging 5.7
+#      File: logging-5-7-release-notes
+#  - Name: Support
+#    File: cluster-logging-support
+#  - Name: Troubleshooting logging
+#    Dir: troubleshooting
+#    Topics:
+#    - Name: Viewing Logging status
+#      File: cluster-logging-cluster-status
+#    - Name: Troubleshooting log forwarding
+#      File: log-forwarding-troubleshooting
+#    - Name: Troubleshooting logging alerts
+#      File: troubleshooting-logging-alerts
+#    - Name: Viewing the status of the Elasticsearch log store
+#      File: cluster-logging-log-store-status
+#  - Name: About Logging
+#    File: cluster-logging
+#  - Name: Installing Logging
+#    File: cluster-logging-deploying
+#  - Name: Updating Logging
+#    File: cluster-logging-upgrading
+#  - Name: Visualizing logs
+#    Dir: log_visualization
+#    Topics:
+#    - Name: About log visualization
+#      File: log-visualization
+#    - Name: Log visualization with the web console
+#      File: log-visualization-ocp-console
+#    - Name: Viewing cluster dashboards
+#      File: cluster-logging-dashboards
+#    - Name: Log visualization with Kibana
+#      File: logging-kibana
+#  - Name: Configuring your Logging deployment
+#    Dir: config
+#    Topics:
+#    - Name: Configuring CPU and memory limits for Logging components
+#      File: cluster-logging-memory
+#    #- Name: Configuring systemd-journald and Fluentd
+#    #  File: cluster-logging-systemd
+#    Dir: log_collection_forwarding
+#   Topics:
+#    - Name: About log collection and forwarding
+#      File: log-forwarding
+#    - Name: Log output types
+#    - Name: Enabling JSON log forwarding
+#    File: cluster-logging-enabling-json-logging
+#  - Name: Configuring log forwarding
+#      File: configuring-log-forwarding
+#    - Name: Configuring the logging collector
+#      File: cluster-logging-collector
+#    - Name: Collecting and storing Kubernetes events
+#      File: cluster-logging-eventrouter
+#  - Name: Log storage
+#    Dir: log_storage
+#    Topics:
+#    - Name: About log storage
+#      File: about-log-storage
+#    - Name: Installing log storage
+#      File: installing-log-storage
+#    - Name: Configuring the LokiStack log store
+#      File: cluster-logging-loki
+#    - Name: Configuring the Elasticsearch log store
+#      File: logging-config-es-store
+#  - Name: Logging alerts
+#    Dir: logging_alerts
+#    Topics:
+#    - Name: Default logging alerts
+#      File: default-logging-alerts
+#    - Name: Custom logging alerts
+#      File: custom-logging-alerts
+#  - Name: Performance and reliability tuning
+#    Dir: performance_reliability
+#    Topics:
+#    - Name: Flow control mechanisms
+#      File: logging-flow-control-mechanisms
+#    - Name: Filtering logs by content
+#      File: logging-content-filtering
+#    - Name: Filtering logs by metadata
+#      File: logging-input-spec-filtering
+#  - Name: Scheduling resources
+#    Dir: scheduling_resources
+#    Topics:
+#    - Name: Using node selectors to move logging resources
+#      File: logging-node-selectors
+#    - Name: Using tolerations to control logging pod placement
+#      File: logging-taints-tolerations
+#  - Name: Uninstalling Logging
+#    File: cluster-logging-uninstall
+#  - Name: Exported fields
+#    File: cluster-logging-exported-fields
+#  - Name: API reference
+#    Dir: api_reference
+#    Topics:
   #  - Name: 5.8 Logging API reference
   #    File: logging-5-8-reference
   #  - Name: 5.7 Logging API reference
   #    File: logging-5-7-reference
-    - Name: 5.6 Logging API reference
-      File: logging-5-6-reference
-  - Name: Glossary
-    File: logging-common-terms
+#    - Name: 5.6 Logging API reference
+#      File: logging-5-6-reference
+#  - Name: Glossary
+#    File: logging-common-terms
 ---
 Name: Service Mesh
 Dir: service_mesh
diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml
index 1b447e8eac13..2496b3fcb454 100644
--- a/_topic_maps/_topic_map_rosa.yml
+++ b/_topic_maps/_topic_map_rosa.yml
@@ -77,7 +77,7 @@ Topics:
 # - Name: About admission plugins
 #   File: rosa-admission-plug-ins
 #   Distros: openshift-rosa
-- Name: About IAM resources for ROSA with STS
+- Name: About IAM resources for STS clusters
   File: rosa-sts-about-iam-resources
 - Name: OpenID Connect Overview
   File: rosa-oidc-overview
@@ -240,7 +240,7 @@ Topics:
   File: rosa-limits-scalability
 - Name: ROSA with HCP limits and scalability
   File: rosa-hcp-limits-scalability
-- Name: Planning your environment
+- Name: Planning resource usage in your cluster
   File: rosa-planning-environment
 - Name: Required AWS service quotas
   File: rosa-sts-required-aws-service-quotas
@@ -383,6 +383,8 @@ Topics:
 #    File: troubleshooting-installations
   - Name: Troubleshooting ROSA installations
     File: rosa-troubleshooting-installations
+  - Name: Troubleshooting ROSA with HCP installations
+    File: rosa-troubleshooting-installations-hcp
   - Name: Troubleshooting networking
     File: rosa-troubleshooting-networking
   - Name: Verifying node health
@@ -402,9 +404,8 @@ Topics:
     File: troubleshooting-operator-issues
   - Name: Investigating pod issues
     File: investigating-pod-issues
-# Hiding from ROSA and OSD until it is decided who should port the Build book
-#  - Name: Troubleshooting the Source-to-Image process
-#    File: troubleshooting-s2i
+  - Name: Troubleshooting the Source-to-Image process
+    File: troubleshooting-s2i
   - Name: Troubleshooting storage issues
     File: troubleshooting-storage-issues
 # Not supported per WINC team
@@ -423,9 +424,6 @@ Topics:
   - Name: Troubleshooting cluster deployments
     File: rosa-troubleshooting-deployments
     Distros: openshift-rosa
-  - Name: Red Hat OpenShift Service on AWS managed resources
-    File: sd-managed-resources
-    Distros: openshift-rosa
 ---
 Name: Web console
 Dir: web_console
@@ -439,7 +437,6 @@ Topics:
   File: using-dashboard-to-get-cluster-information
 - Name: Adding user preferences
   File: adding-user-preferences
-  Distros: openshift-enterprise,openshift-origin
 # cannot patch resource "consoles", insufficient permissions to read any Cluster configuration
 #- Name: Configuring the web console
 #  File: configuring-web-console
@@ -607,6 +604,9 @@ Topics:
     File: dedicated-aws-dc
 - Name: Cluster autoscaling
   File: rosa-cluster-autoscaling
+- Name: Cluster autoscaling for ROSA HCP
+  File: rosa-cluster-autoscaling-hcp
+  # Remove cluster autoscaling for ROSA HCP once the HCP docs are published
 - Name: Manage nodes using machine pools
   Dir: rosa_nodes
   Distros: openshift-rosa
@@ -837,10 +837,6 @@ Topics:
 - Name: Image configuration resources (HCP)
   File: image-configuration-hcp
   Distros: openshift-rosa
-- Name: Using templates
-  File: using-templates
-- Name: Using Ruby on Rails
-  File: templates-using-ruby-on-rails
 - Name: Using images
   Dir: using_images
   Distros: openshift-rosa
@@ -902,8 +898,6 @@ Topics:
   File: configuring-registry-operator
 - Name: Accessing the registry
   File: accessing-the-registry
-# - Name: Exposing the registry
-#   File: securing-exposing-registry
 ---
 Name: Operators
 Dir: operators
@@ -1031,21 +1025,6 @@ Topics:
       File: osdk-helm-updating-projects
     - Name: Helm support
       File: osdk-helm-support
-#   - Name: Hybrid Helm Operator  <= Tech Preview
-#     File: osdk-hybrid-helm
-#   - Name: Updating Hybrid Helm-based projects  <= Tech Preview
-#     File: osdk-hybrid-helm-updating-projects
-# - Name: Java-based Operators  <= Tech Preview
-#   Dir: java
-#   Topics:
-#   - Name: Getting started
-#     File: osdk-java-quickstart
-#   - Name: Tutorial
-#     File: osdk-java-tutorial
-#   - Name: Project layout
-#     File: osdk-java-project-layout
-#   - Name: Updating Java-based projects
-#     File: osdk-java-updating-projects
   - Name: Defining cluster service versions (CSVs)
     File: osdk-generating-csvs
   - Name: Working with bundle images
@@ -1130,6 +1109,8 @@ Topics:
       File: default-network-policy
     - Name: Configuring multitenant isolation with network policy
       File: multitenant-network-policy
+  - Name: Audit logging for network security
+    File: logging-network-security
 - Name: OVN-Kubernetes network plugin
   Dir: ovn_kubernetes_network_provider
   Topics:
@@ -1137,6 +1118,8 @@ Topics:
     File: about-ovn-kubernetes
   - Name: Configuring an egress IP address
     File: configuring-egress-ips-ovn
+  - Name: Migrating from OpenShift SDN network plugin to OVN-Kubernetes network plugin
+    File: migrate-from-openshift-sdn
 - Name: OpenShift SDN network plugin
   Dir: ovn_kubernetes_network_provider
   Topics:
@@ -1169,12 +1152,16 @@ Topics:
 - Name: Creating applications
   Dir: creating_applications
   Topics:
+  - Name: Using templates
+    File: using-templates
   - Name: Creating applications using the Developer perspective
     File: odc-creating-applications-using-developer-perspective
   - Name: Creating applications from installed Operators
     File: creating-apps-from-installed-operators
   - Name: Creating applications using the CLI
     File: creating-applications-using-cli
+  - Name: Creating applications using Ruby on Rails
+    File: templates-using-ruby-on-rails
 - Name: Viewing application composition using the Topology view
   File: odc-viewing-application-composition-using-topology-view
 # cannot create required namespace
@@ -1729,6 +1716,12 @@ Name: Service Mesh
 Dir: service_mesh
 Distros: openshift-rosa
 Topics:
+# Tech Preview
+# - Name: Service Mesh 3.x
+#  Dir: v3x
+#  Topics:
+#  - Name: OpenShift Service Mesh 3.0 TP1 overview
+#    File: ossm-service-mesh-3-0-overview
 - Name: Service Mesh 2.x
   Dir: v2x
   Topics:
@@ -1997,6 +1990,8 @@ Topics:
 # Need to check if supported:
 #   - Name: Configuring shared volumes
 #     File: virt-configuring-shared-volumes-for-vms
+    - Name: Migrating VM disks to a different storage class
+      File: virt-migrating-storage-class
 - Name: Networking
   Dir: vm_networking
   Topics:
@@ -2004,6 +1999,8 @@ Topics:
     File: virt-networking-overview
   - Name: Connecting a VM to the default pod network
     File: virt-connecting-vm-to-default-pod-network
+  - Name: Connecting a VM to a primary user-defined network
+    File: virt-connecting-vm-to-primary-udn
   - Name: Exposing a VM by using a service
     File: virt-exposing-vm-with-service
 # Not supported in ROSA/OSD
diff --git a/_topic_maps/_topic_map_rosa_hcp.yml b/_topic_maps/_topic_map_rosa_hcp.yml
index 11ca4036ed77..40888eaf8e50 100644
--- a/_topic_maps/_topic_map_rosa_hcp.yml
+++ b/_topic_maps/_topic_map_rosa_hcp.yml
@@ -60,6 +60,10 @@ Topics:
     File: rosa-sre-access
   - Name: Understanding security for ROSA
     File: rosa-policy-process-security
+#Temporarily included the following to keep working through xref errors
+- Name: About IAM resources
+  File: rosa-sts-about-iam-resources
+  Distros: openshift-rosa-hcp
 ---
 Name: Learning about ROSA
 Dir: rosa_learning
@@ -110,25 +114,6 @@ Topics:
     File: learning-deploying-application-s2i-deployments
   - Name: Using Source-to-Image (S2I) webhooks for automated deployment
     File: learning-deploying-s2i-webhook-cicd
-# ---
-# Name: Architecture
-# Dir: architecture
-# Distros: openshift-rosa-hcp
-# Topics:
-# - Name: Architecture overview
-#   File: index
-# - Name: Product architecture
-#   File: architecture
-# - Name: Architecture models
-#   File: rosa-architecture-models
-# - Name: Control plane architecture
-#   File: control-plane
-# - Name: NVIDIA GPU architecture overview
-#   File: nvidia-gpu-architecture-overview
-# - Name: Understanding OpenShift development
-#   File: understanding-development
-# - Name: Admission plugins
-#   File: admission-plug-ins
 ---
 Name: Tutorials
 Dir: cloud_experts_tutorials
@@ -140,28 +125,26 @@ Topics:
   File: cloud-experts-rosa-hcp-activation-and-account-linking-tutorial
 - Name: ROSA with HCP private offer acceptance and sharing
   File: cloud-experts-rosa-with-hcp-private-offer-acceptance-and-sharing
-# - Name: Verifying Permissions for a ROSA STS Deployment
-#   File: rosa-mobb-verify-permissions-sts-deployment
-# - Name: Using AWS WAF and Amazon CloudFront to protect ROSA workloads
-#   File: cloud-experts-using-cloudfront-and-waf
-# - Name: Using AWS WAF and AWS ALBs to protect ROSA workloads
-#   File: cloud-experts-using-alb-and-waf
-# - Name: Deploying OpenShift API for Data Protection on a ROSA cluster
-#   File: cloud-experts-deploy-api-data-protection
-# - Name: AWS Load Balancer Operator on ROSA
-#   File: cloud-experts-aws-load-balancer-operator
+- Name: Deploying ROSA with a Custom DNS Resolver
+  File: cloud-experts-custom-dns-resolver
+- Name: Using AWS WAF and Amazon CloudFront to protect ROSA workloads
+  File: cloud-experts-using-cloudfront-and-waf
+- Name: Using AWS WAF and AWS ALBs to protect ROSA workloads
+  File: cloud-experts-using-alb-and-waf
+- Name: Deploying OpenShift API for Data Protection on a ROSA cluster
+  File: cloud-experts-deploy-api-data-protection
+- Name: AWS Load Balancer Operator on ROSA
+  File: cloud-experts-aws-load-balancer-operator
 - Name: Configuring Microsoft Entra ID (formerly Azure Active Directory) as an identity provider
   File: cloud-experts-entra-id-idp
-# - Name: Using AWS Secrets Manager CSI on ROSA with STS
-#   File: cloud-experts-aws-secret-manager
-# - Name: Using AWS Controllers for Kubernetes on ROSA
-#   File: cloud-experts-using-aws-ack
-# - Name: Deploying the External DNS Operator on ROSA
-#   File: cloud-experts-external-dns
-# - Name: Dynamically issuing certificates using the cert-manager Operator on ROSA
-#   File: cloud-experts-dynamic-certificate-custom-domain
-# - Name: Assigning consistent egress IP for external traffic
-#   File: cloud-experts-consistent-egress-ip
+- Name: Using AWS Secrets Manager CSI on ROSA with STS
+  File: cloud-experts-aws-secret-manager
+- Name: Using AWS Controllers for Kubernetes on ROSA
+  File: cloud-experts-using-aws-ack
+- Name: Dynamically issuing certificates using the cert-manager Operator on ROSA
+  File: cloud-experts-dynamic-certificate-custom-domain
+- Name: Assigning consistent egress IP for external traffic
+  File: cloud-experts-consistent-egress-ip
 # ---
 # Name: Getting started
 # Dir: rosa_getting_started
@@ -173,27 +156,25 @@ Topics:
 #   File: rosa-getting-started
 # - Name: Understanding the ROSA with STS deployment workflow
 #   File: rosa-sts-getting-started-workflow
-# ---
-# Name: Prepare your environment
-# Dir: rosa_planning
-# Distros: openshift-rosa-hcp
-# Topics:
-# - Name: Prerequisites checklist for deploying ROSA using STS
-#   File: rosa-cloud-expert-prereq-checklist
-# - Name: Detailed requirements for deploying ROSA using STS
-#   File: rosa-sts-aws-prereqs
-# - Name: ROSA IAM role resources
-#   File: rosa-sts-ocm-role
-# - Name: Limits and scalability
-#   File: rosa-limits-scalability
-#- Name: ROSA with HCP limits and scalability
-#  File: rosa-hcp-limits-scalability
-# - Name: Planning your environment
-#   File: rosa-planning-environment
-# - Name: Required AWS service quotas
-#   File: rosa-sts-required-aws-service-quotas
-# - Name: Setting up your environment
-#   File: rosa-sts-setting-up-environment
+---
+Name: Prepare your environment
+Dir: rosa_planning
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Prerequisites checklist for deploying ROSA with HCP
+  File: rosa-cloud-expert-prereq-checklist
+- Name: Detailed requirements for deploying ROSA with HCP
+  File: rosa-sts-aws-prereqs
+- Name: Required IAM roles and resources
+  File: rosa-hcp-prepare-iam-roles-resources
+- Name: ROSA with HCP limits and scalability
+  File: rosa-hcp-limits-scalability
+- Name: Required AWS service quotas
+  File: rosa-sts-required-aws-service-quotas
+- Name: Setting up your environment
+  File: rosa-sts-setting-up-environment
+- Name: Planning resource usage in your cluster
+  File: rosa-planning-environment
 # - Name: Preparing Terraform to install ROSA clusters
 #   File: rosa-understanding-terraform
 ---
@@ -214,6 +195,136 @@ Topics:
 - Name: Creating ROSA with HCP clusters with external authentication
   File: rosa-hcp-sts-creating-a-cluster-ext-auth
 ---
+Name: Web console
+Dir: web_console
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Web console overview
+  File: web-console-overview
+- Name: Accessing the web console
+  File: web-console
+- Name: Viewing cluster information
+  File: using-dashboard-to-get-cluster-information
+- Name: Adding user preferences
+  File: adding-user-preferences
+- Name: Dynamic plugins
+  Dir: dynamic-plugin
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Overview of dynamic plugins
+    File: overview-dynamic-plugin
+  - Name: Getting started with dynamic plugins
+    File: dynamic-plugins-get-started
+  - Name: Deploy your plugin on a cluster
+    File: deploy-plugin-cluster
+  - Name: Dynamic plugin example
+    File: dynamic-plugin-example
+  - Name: Dynamic plugin reference
+    File: dynamic-plugins-reference
+- Name: Web terminal
+  Dir: web_terminal
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Installing the web terminal
+    File: installing-web-terminal
+  - Name: Using the web terminal
+    File: odc-using-web-terminal
+  - Name: Troubleshooting the web terminal
+    File: troubleshooting-web-terminal
+  - Name: Uninstalling the web terminal
+    File: uninstalling-web-terminal
+- Name: About quick start tutorials
+  File: creating-quick-start-tutorials
+  Distros: openshift-rosa-hcp
+---
+Name: CLI tools
+Dir: cli_reference
+Distros: openshift-rosa-hcp
+Topics:
+- Name: CLI tools overview
+  File: index
+- Name: OpenShift CLI (oc)
+  Dir: openshift_cli
+  Topics:
+  - Name: Getting started with the OpenShift CLI
+    File: getting-started-cli
+  - Name: Configuring the OpenShift CLI
+    File: configuring-cli
+  - Name: Usage of oc and kubectl commands
+    File: usage-oc-kubectl
+  - Name: Managing CLI profiles
+    File: managing-cli-profiles
+  - Name: Extending the OpenShift CLI with plugins
+    File: extending-cli-plugins
+ # - Name: Managing CLI plugins with Krew
+  #  File: managing-cli-plugins-krew
+  #  Distros: openshift-rosa-hcp
+  - Name: OpenShift CLI developer command reference
+    File: developer-cli-commands
+  - Name: OpenShift CLI administrator command reference
+    File: administrator-cli-commands
+    Distros: openshift-rosa-hcp
+- Name: Developer CLI (odo)
+  File: odo-important-update
+  # Dir: developer_cli_odo
+  Distros: openshift-rosa-hcp
+  # Topics:
+  # - Name: odo release notes
+  #  File: odo-release-notes
+  # - Name: Understanding odo
+  #  File: understanding-odo
+  # - Name: Installing odo
+  #  File: installing-odo
+  # - Name: Configuring the odo CLI
+  #  File: configuring-the-odo-cli
+  # - Name: odo CLI reference
+  #  File: odo-cli-reference
+- Name: Knative CLI (kn) for use with OpenShift Serverless
+  File: kn-cli-tools
+  Distros: openshift-rosa-hcp
+- Name: Pipelines CLI (tkn)
+  Dir: tkn_cli
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Installing tkn
+    File: installing-tkn
+  - Name: Configuring tkn
+    File: op-configuring-tkn
+  - Name: Basic tkn commands
+    File: op-tkn-reference
+- Name: opm CLI
+  Dir: opm
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Installing the opm CLI
+    File: cli-opm-install
+  - Name: opm CLI reference
+    File: cli-opm-ref
+- Name: Operator SDK
+  Dir: osdk
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Installing the Operator SDK CLI
+    File: cli-osdk-install
+  - Name: Operator SDK CLI reference
+    File: cli-osdk-ref
+- Name: ROSA CLI
+  Dir: rosa_cli
+  Distros: openshift-rosa-hcp
+  Topics:
+  # - Name: CLI and web console
+  #   File: rosa-cli-openshift-console
+  - Name: Getting started with the ROSA CLI
+    File: rosa-get-started-cli
+  - Name: Managing objects with the ROSA CLI
+    File: rosa-manage-objects-cli
+  - Name: Checking account and version information with the ROSA CLI
+    File: rosa-checking-acct-version-cli
+  - Name: Checking logs with the ROSA CLI
+    File: rosa-checking-logs-cli
+  - Name: Least privilege permissions for ROSA CLI commands
+    File: rosa-cli-permission-examples
+---
 Name: Red Hat OpenShift Cluster Manager
 Dir: ocm
 Distros: openshift-rosa-hcp
@@ -224,6 +335,97 @@ Topics:
 #    File: ocm-overview
 #  - Name: Using the OpenShift web console
 #    File: rosa-using-openshift-console
+# OSDOCS-11789: Adding the minimum chapters of support and troubleshooting
+# docs needed to ensure that xrefs in "Planning your environment" work;
+# omit as required by further HCP migration work.
+---
+Name: Support
+Dir: support
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Support overview
+  File: index
+- Name: Managing your cluster resources
+  File: managing-cluster-resources
+- Name: Approved Access
+  File: approved-access
+- Name: Getting support
+  File: getting-support
+- Name: Remote health monitoring with connected clusters
+  Dir: remote_health_monitoring
+  Topics:
+  - Name: About remote health monitoring
+    File: about-remote-health-monitoring
+  - Name: Showing data collected by remote health monitoring
+    File: showing-data-collected-by-remote-health-monitoring
+# cannot get resource "secrets" in API group "" in the namespace "openshift-config"
+#  - Name: Opting out of remote health reporting
+#    File: opting-out-of-remote-health-reporting
+# cannot get resource "secrets" in API group "" in the namespace "openshift-config"
+#  - Name: Enabling remote health reporting
+#    File: enabling-remote-health-reporting
+  - Name: Using Insights to identify issues with your cluster
+    File: using-insights-to-identify-issues-with-your-cluster
+  - Name: Using Insights Operator
+    File: using-insights-operator
+# Not supported per Michael McNeill
+# - Name: Using remote health reporting in a restricted network
+#   File: remote-health-reporting-from-restricted-network
+# cannot list resource "secrets" in API group "" in the namespace "openshift-config"
+#  - Name: Importing simple content access entitlements with Insights Operator
+#    File: insights-operator-simple-access
+- Name: Gathering data about your cluster
+  File: gathering-cluster-data
+- Name: Summarizing cluster specifications
+  File: summarizing-cluster-specifications
+- Name: Troubleshooting
+  Dir: troubleshooting
+  Topics:
+# rosa has own troubleshooting installations
+#  - Name: Troubleshooting installations
+#    File: troubleshooting-installations
+  - Name: Troubleshooting ROSA installations
+    File: rosa-troubleshooting-installations
+  - Name: Troubleshooting ROSA with HCP installations
+    File: rosa-troubleshooting-installations-hcp
+  - Name: Troubleshooting networking
+    File: rosa-troubleshooting-networking
+  - Name: Verifying node health
+    File: verifying-node-health
+#  cannot create resource "namespaces", cannot patch resource "nodes"
+#  - Name: Troubleshooting CRI-O container runtime issues
+#    File: troubleshooting-crio-issues
+# requires ostree, butane, and other plug-ins
+#  - Name: Troubleshooting operating system issues
+#    File: troubleshooting-operating-system-issues
+#    Distros: openshift-rosa
+# cannot patch resource "nodes", "nodes/proxy", "namespaces"
+#  - Name: Troubleshooting network issues
+#    File: troubleshooting-network-issues
+#    Distros: openshift-rosa
+  - Name: Troubleshooting Operator issues
+    File: troubleshooting-operator-issues
+  - Name: Investigating pod issues
+    File: investigating-pod-issues
+  - Name: Troubleshooting the Source-to-Image process
+    File: troubleshooting-s2i
+  - Name: Troubleshooting storage issues
+    File: troubleshooting-storage-issues
+# Not supported per WINC team
+#  - Name: Troubleshooting Windows container workload issues
+#    File: troubleshooting-windows-container-workload-issues
+  - Name: Investigating monitoring issues
+    File: investigating-monitoring-issues
+  - Name: Diagnosing OpenShift CLI (oc) issues
+    File: diagnosing-oc-issues
+  - Name: Troubleshooting expired offline access tokens
+    File: rosa-troubleshooting-expired-tokens
+  - Name: Troubleshooting IAM roles
+    File: rosa-troubleshooting-iam-resources
+  - Name: Troubleshooting cluster deployments
+    File: rosa-troubleshooting-deployments
+  - Name: Red Hat managed resources
+    File: sd-managed-resources
 ---
 Name: Cluster administration
 Dir: rosa_cluster_admin
@@ -242,6 +444,8 @@ Topics:
     File: dedicated-aws-vpn
   - Name: Configuring AWS Direct Connect
     File: dedicated-aws-dc
+- Name: Cluster autoscaling
+  File: rosa-cluster-autoscaling
 - Name: Manage nodes using machine pools
   Dir: rosa_nodes
   Topics:
@@ -267,90 +471,85 @@ Distros: openshift-rosa-hcp
 Topics:
 - Name: Adding additional constraints for IP-based AWS role assumption
   File: rosa-adding-additional-constraints-for-ip-based-aws-role-assumption
-# ---
-# - Name: Security
-#   File: rosa-security
-# - Name: Application and cluster compliance
-#   File: rosa-app-security-compliance
-# ---
-# Name: Authentication and authorization
-# Dir: authentication
-# Distros: openshift-rosa-hcp
-# Topics:
-# - Name: Authentication and authorization overview
-#   File: index
-# - Name: Understanding authentication
-#   File: understanding-authentication
-#  - Name: Configuring the internal OAuth server
-#    File: configuring-internal-oauth
-#  - Name: Configuring OAuth clients
-#    File: configuring-oauth-clients
-# - Name: Managing user-owned OAuth access tokens
-#   File: managing-oauth-access-tokens
-#  - Name: Understanding identity provider configuration
-#    File: understanding-identity-provider
+---
+Name: Authentication and authorization
+Dir: authentication
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Authentication and authorization overview
+  File: index
+- Name: Understanding authentication
+  File: understanding-authentication
+# - Name: Configuring the internal OAuth server
+#   File: configuring-internal-oauth
+# - Name: Configuring OAuth clients
+#   File: configuring-oauth-clients
+- Name: Managing user-owned OAuth access tokens
+  File: managing-oauth-access-tokens
+# - Name: Understanding identity provider configuration
+#   File: understanding-identity-provider
+- Name: Configuring identity providers
+  File: sd-configuring-identity-providers
 # - Name: Configuring identity providers
-#   File: sd-configuring-identity-providers
-#  - Name: Configuring identity providers
-#    Dir: identity_providers
-#    Topics:
-#    - Name: Configuring an htpasswd identity provider
-#      File: configuring-htpasswd-identity-provider
-#    - Name: Configuring a Keystone identity provider
-#      File: configuring-keystone-identity-provider
-#    - Name: Configuring an LDAP identity provider
-#      File: configuring-ldap-identity-provider
-#    - Name: Configuring a basic authentication identity provider
-#      File: configuring-basic-authentication-identity-provider
-#    - Name: Configuring a request header identity provider
-#      File: configuring-request-header-identity-provider
-#    - Name: Configuring a GitHub or GitHub Enterprise identity provider
-#      File: configuring-github-identity-provider
-#    - Name: Configuring a GitLab identity provider
-#      File: configuring-gitlab-identity-provider
-#    - Name: Configuring a Google identity provider
-#      File: configuring-google-identity-provider
-#    - Name: Configuring an OpenID Connect identity provider
-#      File: configuring-oidc-identity-provider
-# - Name: Using RBAC to define and apply permissions
-#   File: using-rbac
-#  - Name: Removing the kubeadmin user
-#    File: remove-kubeadmin
-# - Name: Configuring LDAP failover
-#   File: configuring-ldap-failover
-# - Name: Understanding and creating service accounts
-#   File: understanding-and-creating-service-accounts
-# - Name: Using service accounts in applications
-#   File: using-service-accounts-in-applications
-# - Name: Using a service account as an OAuth client
-#   File: using-service-accounts-as-oauth-client
-# - Name: Assuming an AWS IAM role for a service account
-#   File: assuming-an-aws-iam-role-for-a-service-account
-# - Name: Scoping tokens
-#   File: tokens-scoping
-# - Name: Using bound service account tokens
-#   File: bound-service-account-tokens
-# - Name: Managing security context constraints
-#   File: managing-security-context-constraints
-# - Name: Understanding and managing pod security admission
-#   File: understanding-and-managing-pod-security-admission
-#  - Name: Impersonating the system:admin user
-#    File: impersonating-system-admin
-# - Name: Syncing LDAP groups
-#   File: ldap-syncing
-#  - Name: Managing cloud provider credentials
-#    Dir: managing_cloud_provider_credentials
-#    Topics:
-#    - Name: About the Cloud Credential Operator
-#      File: about-cloud-credential-operator
-#    - Name: Mint mode
-#      File: cco-mode-mint
-#    - Name: Passthrough mode
-#      File: cco-mode-passthrough
-#    - Name: Manual mode with long-term credentials for components
-#      File: cco-mode-manual
-#    - Name: Manual mode with short-term credentials for components
-#      File: cco-short-term-creds
+#   Dir: identity_providers
+#   Topics:
+#   - Name: Configuring an htpasswd identity provider
+#     File: configuring-htpasswd-identity-provider
+#   - Name: Configuring a Keystone identity provider
+#     File: configuring-keystone-identity-provider
+#   - Name: Configuring an LDAP identity provider
+#     File: configuring-ldap-identity-provider
+#   - Name: Configuring a basic authentication identity provider
+#     File: configuring-basic-authentication-identity-provider
+#   - Name: Configuring a request header identity provider
+#     File: configuring-request-header-identity-provider
+#   - Name: Configuring a GitHub or GitHub Enterprise identity provider
+#     File: configuring-github-identity-provider
+#   - Name: Configuring a GitLab identity provider
+#     File: configuring-gitlab-identity-provider
+#   - Name: Configuring a Google identity provider
+#     File: configuring-google-identity-provider
+#   - Name: Configuring an OpenID Connect identity provider
+#     File: configuring-oidc-identity-provider
+- Name: Using RBAC to define and apply permissions
+  File: using-rbac
+# - Name: Removing the kubeadmin user
+#   File: remove-kubeadmin
+#- Name: Configuring LDAP failover
+#  File: configuring-ldap-failover
+- Name: Understanding and creating service accounts
+  File: understanding-and-creating-service-accounts
+- Name: Using service accounts in applications
+  File: using-service-accounts-in-applications
+- Name: Using a service account as an OAuth client
+  File: using-service-accounts-as-oauth-client
+- Name: Assuming an AWS IAM role for a service account
+  File: assuming-an-aws-iam-role-for-a-service-account
+- Name: Scoping tokens
+  File: tokens-scoping
+- Name: Using bound service account tokens
+  File: bound-service-account-tokens
+- Name: Managing security context constraints
+  File: managing-security-context-constraints
+- Name: Understanding and managing pod security admission
+  File: understanding-and-managing-pod-security-admission
+# - Name: Impersonating the system:admin user
+#   File: impersonating-system-admin
+- Name: Syncing LDAP groups
+  File: ldap-syncing
+# - Name: Managing cloud provider credentials
+#   Dir: managing_cloud_provider_credentials
+#   Topics:
+#   - Name: About the Cloud Credential Operator
+#     File: about-cloud-credential-operator
+#   - Name: Mint mode
+#     File: cco-mode-mint
+#   - Name: Passthrough mode
+#     File: cco-mode-passthrough
+#   - Name: Manual mode with long-term credentials for components
+#     File: cco-mode-manual
+#   - Name: Manual mode with short-term credentials for components
+#     File: cco-short-term-creds
 ---
 Name: Upgrading
 Dir: upgrading
@@ -470,6 +669,255 @@ Topics:
 - Name: Accessing the registry
   File: accessing-the-registry
 ---
+Name: Operators
+Dir: operators
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Operators overview
+  File: index
+- Name: Understanding Operators
+  Dir: understanding
+  Topics:
+  - Name: What are Operators?
+    File: olm-what-operators-are
+  - Name: Packaging format
+    File: olm-packaging-format
+  - Name: Common terms
+    File: olm-common-terms
+  - Name: Operator Lifecycle Manager (OLM)
+    Dir: olm
+    Topics:
+    - Name: Concepts and resources
+      File: olm-understanding-olm
+    - Name: Architecture
+      File: olm-arch
+    - Name: Workflow
+      File: olm-workflow
+    - Name: Dependency resolution
+      File: olm-understanding-dependency-resolution
+    - Name: Operator groups
+      File: olm-understanding-operatorgroups
+    - Name: Multitenancy and Operator colocation
+      File: olm-colocation
+    - Name: Operator conditions
+      File: olm-operatorconditions
+    - Name: Metrics
+      File: olm-understanding-metrics
+    - Name: Webhooks
+      File: olm-webhooks
+  - Name: OperatorHub
+    File: olm-understanding-operatorhub
+  - Name: Red Hat-provided Operator catalogs
+    File: olm-rh-catalogs
+  - Name: Operators in multitenant clusters
+    File: olm-multitenancy
+  - Name: CRDs
+    Dir: crds
+    Topics:
+    - Name: Managing resources from CRDs
+      File: crd-managing-resources-from-crds
+- Name: User tasks
+  Dir: user
+  Topics:
+  - Name: Creating applications from installed Operators
+    File: olm-creating-apps-from-installed-operators
+- Name: Administrator tasks
+  Dir: admin
+  Topics:
+  - Name: Adding Operators to a cluster
+    File: olm-adding-operators-to-cluster
+  - Name: Updating installed Operators
+    File: olm-upgrading-operators
+  - Name: Deleting Operators from a cluster
+    File: olm-deleting-operators-from-cluster
+  - Name: Configuring proxy support
+    File: olm-configuring-proxy-support
+  - Name: Viewing Operator status
+    File: olm-status
+  - Name: Managing Operator conditions
+    File: olm-managing-operatorconditions
+  - Name: Managing custom catalogs
+    File: olm-managing-custom-catalogs
+  - Name: Catalog source pod scheduling
+    File: olm-cs-podsched
+  - Name: Troubleshooting Operator issues
+    File: olm-troubleshooting-operator-issues
+- Name: Developing Operators
+  Dir: operator_sdk
+  Topics:
+  - Name: About the Operator SDK
+    File: osdk-about
+  - Name: Installing the Operator SDK CLI
+    File: osdk-installing-cli
+  - Name: Go-based Operators
+    Dir: golang
+    Topics:
+#  Quick start excluded, because it requires cluster-admin permissions.
+#    - Name: Getting started
+#      File: osdk-golang-quickstart
+    - Name: Tutorial
+      File: osdk-golang-tutorial
+    - Name: Project layout
+      File: osdk-golang-project-layout
+    - Name: Updating Go-based projects
+      File: osdk-golang-updating-projects
+  - Name: Ansible-based Operators
+    Dir: ansible
+    Topics:
+#  Quick start excluded, because it requires cluster-admin permissions.
+#    - Name: Getting started
+#      File: osdk-ansible-quickstart
+    - Name: Tutorial
+      File: osdk-ansible-tutorial
+    - Name: Project layout
+      File: osdk-ansible-project-layout
+    - Name: Updating Ansible-based projects
+      File: osdk-ansible-updating-projects
+    - Name: Ansible support
+      File: osdk-ansible-support
+    - Name: Kubernetes Collection for Ansible
+      File: osdk-ansible-k8s-collection
+    - Name: Using Ansible inside an Operator
+      File: osdk-ansible-inside-operator
+    - Name: Custom resource status management
+      File: osdk-ansible-cr-status
+  - Name: Helm-based Operators
+    Dir: helm
+    Topics:
+#  Quick start excluded, because it requires cluster-admin permissions.
+#    - Name: Getting started
+#      File: osdk-helm-quickstart
+    - Name: Tutorial
+      File: osdk-helm-tutorial
+    - Name: Project layout
+      File: osdk-helm-project-layout
+    - Name: Updating Helm-based projects
+      File: osdk-helm-updating-projects
+    - Name: Helm support
+      File: osdk-helm-support
+#  - Name: Hybrid Helm Operator  <= Tech Preview
+#    File: osdk-hybrid-helm
+#  - Name: Updating Hybrid Helm-based projects  (Technology Preview)
+#    File: osdk-hybrid-helm-updating-projects
+# - Name: Java-based Operators  <= Tech Preview
+#   Dir: java
+#   Topics:
+#   - Name: Getting started
+#     File: osdk-java-quickstart
+#   - Name: Tutorial
+#     File: osdk-java-tutorial
+#   - Name: Project layout
+#     File: osdk-java-project-layout
+#   - Name: Updating Java-based projects
+#     File: osdk-java-updating-projects
+  - Name: Defining cluster service versions (CSVs)
+    File: osdk-generating-csvs
+  - Name: Working with bundle images
+    File: osdk-working-bundle-images
+  - Name: Complying with pod security admission
+    File: osdk-complying-with-psa
+  - Name: Validating Operators using the scorecard
+    File: osdk-scorecard
+  - Name: Validating Operator bundles
+    File: osdk-bundle-validate
+  - Name: High-availability or single-node cluster detection and support
+    File: osdk-ha-sno
+  - Name: Configuring built-in monitoring with Prometheus
+    File: osdk-monitoring-prometheus
+  - Name: Configuring leader election
+    File: osdk-leader-election
+  - Name: Object pruning utility
+    File: osdk-pruning-utility
+  - Name: Migrating package manifest projects to bundle format
+    File: osdk-pkgman-to-bundle
+  - Name: Operator SDK CLI reference
+    File: osdk-cli-ref
+  - Name: Migrating to Operator SDK v0.1.0
+    File: osdk-migrating-to-v0-1-0
+#  ROSA customers can't configure/edit the cluster Operators
+#  - Name: Cluster Operators reference
+#    File: operator-reference
+---
+Name: Building applications
+Dir: applications
+Distros: openshift-rosa-hcp
+Topics:
+- Name: Building applications overview
+  File: index
+- Name: Projects
+  Dir: projects
+  Topics:
+  - Name: Working with projects
+    File: working-with-projects
+#  cannot impersonate resource "users" in API group
+#  - Name: Creating a project as another user
+#    File: creating-project-other-user
+  - Name: Configuring project creation
+    File: configuring-project-creation
+- Name: Creating applications
+  Dir: creating_applications
+  Topics:
+  - Name: Creating applications using the Developer perspective
+    File: odc-creating-applications-using-developer-perspective
+  - Name: Creating applications from installed Operators
+    File: creating-apps-from-installed-operators
+  - Name: Creating applications using the CLI
+    File: creating-applications-using-cli
+- Name: Viewing application composition using the Topology view
+  File: odc-viewing-application-composition-using-topology-view
+# cannot create required namespace
+# - Name: Exporting applications
+#  File: odc-exporting-applications
+- Name: Working with Helm charts
+  Dir: working_with_helm_charts
+  Topics:
+  - Name: Understanding Helm
+    File: understanding-helm
+  - Name: Installing Helm
+    File: installing-helm
+  - Name: Configuring custom Helm chart repositories
+    File: configuring-custom-helm-chart-repositories
+  - Name: Working with Helm releases
+    File: odc-working-with-helm-releases
+- Name: Deployments
+  Dir: deployments
+  Topics:
+  - Name: Custom domains for applications
+    File: rosa-config-custom-domains-applications
+  - Name: Understanding Deployments and DeploymentConfigs
+    File: what-deployments-are
+  - Name: Managing deployment processes
+    File: managing-deployment-processes
+  - Name: Using deployment strategies
+    File: deployment-strategies
+  - Name: Using route-based deployment strategies
+    File: route-based-deployment-strategies
+- Name: Quotas
+  Dir: quotas
+  Topics:
+  - Name: Resource quotas per project
+    File: quotas-setting-per-project
+  - Name: Resource quotas across multiple projects
+    File: quotas-setting-across-multiple-projects
+- Name: Using config maps with applications
+  File: config-maps
+- Name: Monitoring project and application metrics using the Developer perspective
+  File: odc-monitoring-project-and-application-metrics-using-developer-perspective
+- Name: Monitoring application health
+  File: application-health
+- Name: Editing applications
+  File: odc-editing-applications
+- Name: Working with quotas
+  File: working-with-quotas
+- Name: Pruning objects to reclaim resources
+  File: pruning-objects
+- Name: Idling applications
+  File: idling-applications
+- Name: Deleting applications
+  File: odc-deleting-applications
+- Name: Using the Red Hat Marketplace
+  File: red-hat-marketplace
+---
 Name: Backup and restore
 Dir: backup_and_restore
 Distros: openshift-rosa-hcp
@@ -675,124 +1123,6 @@ Topics:
 #     File: nodes-secondary-scheduler-configuring
 #   - Name: Uninstalling the Secondary Scheduler Operator
 #     File: nodes-secondary-scheduler-uninstalling
-# - Name: Using Jobs and DaemonSets
-#   Dir: jobs
-#   Topics:
-#   - Name: Running background tasks on nodes automatically with daemonsets
-#     File: nodes-pods-daemonsets
-#     Distros: openshift-rosa-hcp
-#   - Name: Running tasks in pods using jobs
-#     File: nodes-nodes-jobs
-# - Name: Working with nodes
-#   Dir: nodes
-#   Distros: openshift-rosa-hcp
-#   Topics:
-#   - Name: Viewing and listing the nodes in your cluster
-#     File: nodes-nodes-viewing
-#  cannot use oc adm cordon; cannot patch resource "machinesets"; cannot patch resource "nodes"
-#   - Name: Working with nodes
-#     File: nodes-nodes-working
-#  cannot create resource "kubeletconfigs", "schedulers", "machineconfigs", "kubeletconfigs"
-#   - Name: Managing nodes
-#     File: nodes-nodes-managing
-#  cannot create resource "kubeletconfigs"
-#   - Name: Managing graceful node shutdown
-#     File: nodes-nodes-graceful-shutdown
-#  cannot create resource "kubeletconfigs"
-#   - Name: Managing the maximum number of pods per node
-#     File: nodes-nodes-managing-max-pods
-#   - Name: Using the Node Tuning Operator
-#     File: nodes-node-tuning-operator
-#   - Name: Remediating, fencing, and maintaining nodes
-#     File: nodes-remediating-fencing-maintaining-rhwa
-#  Cannot create namespace needed to oc debug and reboot; revisit after Operator book converted
-#   - Name: Understanding node rebooting
-#     File: nodes-nodes-rebooting
-#  cannot create resource "kubeletconfigs"
-#   - Name: Freeing node resources using garbage collection
-#     File: nodes-nodes-garbage-collection
-#  cannot create resource "kubeletconfigs"
-#   - Name: Allocating resources for nodes
-#     File: nodes-nodes-resources-configuring
-#  cannot create resource "kubeletconfigs"
-#   - Name: Allocating specific CPUs for nodes in a cluster
-#     File: nodes-nodes-resources-cpus
-#  cannot create resource "kubeletconfigs"
-#   - Name: Configuring the TLS security profile for the kubelet
-#     File: nodes-nodes-tls
-#     Distros: openshift-rosa-hcp
-#   - Name: Monitoring for problems in your nodes
-#     File: nodes-nodes-problem-detector
-#   - Name: Machine Config Daemon metrics
-#     File: nodes-nodes-machine-config-daemon-metrics
-#  cannot patch resource "nodes"
-#   - Name: Creating infrastructure nodes
-#     File: nodes-nodes-creating-infrastructure-nodes
-# - Name: Working with containers
-#   Dir: containers
-#   Topics:
-#   - Name: Understanding containers
-#     File: nodes-containers-using
-#   - Name: Using Init Containers to perform tasks before a pod is deployed
-#     File: nodes-containers-init
-#     Distros: openshift-rosa-hcp
-#   - Name: Using volumes to persist container data
-#     File: nodes-containers-volumes
-#   - Name: Mapping volumes using projected volumes
-#     File: nodes-containers-projected-volumes
-#   - Name: Allowing containers to consume API objects
-#     File: nodes-containers-downward-api
-#   - Name: Copying files to or from a container
-#     File: nodes-containers-copying-files
-#   - Name: Executing remote commands in a container
-#     File: nodes-containers-remote-commands
-#   - Name: Using port forwarding to access applications in a container
-#     File: nodes-containers-port-forwarding
-#  cannot patch resource "configmaps"
-#   - Name: Using sysctls in containers
-#     File: nodes-containers-sysctls
-# - Name: Working with clusters
-#   Dir: clusters
-#   Topics:
-#   - Name: Viewing system event information in a cluster
-#     File: nodes-containers-events
-#   - Name: Analyzing cluster resource levels
-#     File: nodes-cluster-resource-levels
-#     Distros: openshift-rosa-hcp
-#   - Name: Setting limit ranges
-#     File: nodes-cluster-limit-ranges
-#   - Name: Configuring cluster memory to meet container memory and risk requirements
-#     File: nodes-cluster-resource-configure
-#     Distros: openshift-rosa-hcp
-#   - Name: Configuring your cluster to place pods on overcommited nodes
-#     File: nodes-cluster-overcommit
-#     Distros: openshift-rosa-hcp
-#   - Name: Configuring the Linux cgroup version on your nodes
-#     File: nodes-cluster-cgroups-2
-#     Distros: openshift-enterprise
-#   - Name: Configuring the Linux cgroup version on your nodes
-#     File: nodes-cluster-cgroups-okd
-#     Distros: openshift-origin
-#   The TechPreviewNoUpgrade Feature Gate is not allowed
-#   - Name: Enabling features using FeatureGates
-#     File: nodes-cluster-enabling-features
-#     Distros: openshift-rosa-hcp
-#  Error: nodes.config.openshift.io "cluster" could not be patched
-#   - Name: Improving cluster stability in high latency environments using worker latency profiles
-#     File: nodes-cluster-worker-latency-profiles
-#  Not supported per Michael McNeill
-# - Name: Remote worker nodes on the network edge
-#   Dir: edge
-#   Topics:
-#   - Name: Using remote worker node at the network edge
-#     File: nodes-edge-remote-workers
-#  Not supported per Michael McNeill
-# - Name: Worker nodes for single-node OpenShift clusters
-#   Dir: nodes
-#   Distros: openshift-rosa-hcp
-#   Topics:
-#   - Name: Adding worker nodes to single-node OpenShift clusters
-#     File: nodes-sno-worker-nodes
 - Name: Using jobs and daemon sets
   Dir: jobs
   Topics:
@@ -904,12 +1234,450 @@ Topics:
 #  - Name: Adding worker nodes to single-node OpenShift clusters
 #    File: nodes-sno-worker-nodes
 ---
-Name: Serverless
-Dir: serverless
+Name: Observability
+Dir: observability
 Distros: openshift-rosa-hcp
 Topics:
-- Name: About Serverless
-  Dir: about
+- Name: Observability overview
+  Dir: overview
+  Topics:
+  - Name: About Observability
+    File: index
+- Name: Monitoring
+  Dir: monitoring
+  Distros: openshift-rosa-hcp
   Topics:
-  - Name: Serverless overview
-    File: about-serverless
+  - Name: Monitoring overview
+    File: monitoring-overview
+  - Name: Accessing monitoring for user-defined projects
+    File: sd-accessing-monitoring-for-user-defined-projects
+  - Name: Configuring the monitoring stack
+    File: configuring-the-monitoring-stack
+  - Name: Disabling monitoring for user-defined projects
+    File: sd-disabling-monitoring-for-user-defined-projects
+  - Name: Enabling alert routing for user-defined projects
+    File: enabling-alert-routing-for-user-defined-projects
+  - Name: Managing metrics
+    File: managing-metrics
+  - Name: Managing alerts
+    File: managing-alerts
+  - Name: Reviewing monitoring dashboards
+    File: reviewing-monitoring-dashboards
+  - Name: Accessing third-party monitoring APIs
+    File: accessing-third-party-monitoring-apis
+  - Name: Troubleshooting monitoring issues
+    File: troubleshooting-monitoring-issues
+  - Name: Config map reference for the Cluster Monitoring Operator
+    File: config-map-reference-for-the-cluster-monitoring-operator
+- Name: Logging
+  Dir: logging
+  Distros: openshift-rosa-hcp
+  Topics:
+  - Name: Release notes
+    Dir: logging_release_notes
+    Topics:
+    - Name: Logging 5.9
+      File: logging-5-9-release-notes
+    - Name: Logging 5.8
+      File: logging-5-8-release-notes
+    - Name: Logging 5.7
+      File: logging-5-7-release-notes
+  - Name: Support
+    File: cluster-logging-support
+  - Name: Troubleshooting logging
+    Dir: troubleshooting
+    Topics:
+    - Name: Viewing Logging status
+      File: cluster-logging-cluster-status
+    - Name: Troubleshooting log forwarding
+      File: log-forwarding-troubleshooting
+    - Name: Troubleshooting logging alerts
+      File: troubleshooting-logging-alerts
+    - Name: Viewing the status of the Elasticsearch log store
+      File: cluster-logging-log-store-status
+  - Name: About Logging
+    File: cluster-logging
+  - Name: Installing Logging
+    File: cluster-logging-deploying
+  - Name: Updating Logging
+    File: cluster-logging-upgrading
+  - Name: Visualizing logs
+    Dir: log_visualization
+    Topics:
+    - Name: About log visualization
+      File: log-visualization
+    - Name: Log visualization with the web console
+      File: log-visualization-ocp-console
+    - Name: Viewing cluster dashboards
+      File: cluster-logging-dashboards
+    - Name: Log visualization with Kibana
+      File: logging-kibana
+  - Name: Configuring your Logging deployment
+    Dir: config
+    Topics:
+    - Name: Configuring CPU and memory limits for Logging components
+      File: cluster-logging-memory
+    #- Name: Configuring systemd-journald and Fluentd
+    #  File: cluster-logging-systemd
+  - Name: Log collection and forwarding
+    Dir: log_collection_forwarding
+    Topics:
+    - Name: About log collection and forwarding
+      File: log-forwarding
+    - Name: Log output types
+      File: logging-output-types
+    - Name: Enabling JSON log forwarding
+      File: cluster-logging-enabling-json-logging
+    - Name: Configuring log forwarding
+      File: configuring-log-forwarding
+    - Name: Configuring the logging collector
+      File: cluster-logging-collector
+    - Name: Collecting and storing Kubernetes events
+      File: cluster-logging-eventrouter
+  - Name: Log storage
+    Dir: log_storage
+    Topics:
+    - Name: About log storage
+      File: about-log-storage
+    - Name: Installing log storage
+      File: installing-log-storage
+    - Name: Configuring the LokiStack log store
+      File: cluster-logging-loki
+    - Name: Configuring the Elasticsearch log store
+      File: logging-config-es-store
+  - Name: Logging alerts
+    Dir: logging_alerts
+    Topics:
+    - Name: Default logging alerts
+      File: default-logging-alerts
+    - Name: Custom logging alerts
+      File: custom-logging-alerts
+  - Name: Performance and reliability tuning
+    Dir: performance_reliability
+    Topics:
+    - Name: Flow control mechanisms
+      File: logging-flow-control-mechanisms
+    - Name: Filtering logs by content
+      File: logging-content-filtering
+    - Name: Filtering logs by metadata
+      File: logging-input-spec-filtering
+  - Name: Scheduling resources
+    Dir: scheduling_resources
+    Topics:
+    - Name: Using node selectors to move logging resources
+      File: logging-node-selectors
+    - Name: Using tolerations to control logging pod placement
+      File: logging-taints-tolerations
+  - Name: Uninstalling Logging
+    File: cluster-logging-uninstall
+  - Name: Exported fields
+    File: cluster-logging-exported-fields
+  - Name: API reference
+    Dir: api_reference
+    Topics:
+  #  - Name: 5.8 Logging API reference
+  #    File: logging-5-8-reference
+  #  - Name: 5.7 Logging API reference
+  #    File: logging-5-7-reference
+    - Name: 5.6 Logging API reference
+      File: logging-5-6-reference
+  - Name: Glossary
+    File: logging-common-terms
+---
+Name: Virtualization
+Dir: virt
+Distros: openshift-rosa-hcp
+Topics:
+- Name: About
+  Dir: about_virt
+  Topics:
+  - Name: About OpenShift Virtualization
+    File: about-virt
+    Distros: openshift-rosa-hcp
+  - Name: About OKD Virtualization
+    File: about-virt
+    Distros: openshift-origin
+  - Name: Security policies
+    File: virt-security-policies
+  - Name: Architecture
+    File: virt-architecture
+    Distros: openshift-rosa-hcp
+#- Name: Release notes
+#  Dir: release_notes
+#  Topics:
+#  - Name: OpenShift Virtualization release notes
+#    File: virt-release-notes-placeholder
+#    Distros: openshift-rosa
+- Name: Getting started
+  Dir: getting_started
+  Topics:
+  - Name: Getting started with OpenShift Virtualization
+    File: virt-getting-started
+    Distros: openshift-rosa-hcp
+  - Name: Getting started with OKD Virtualization
+    File: virt-getting-started
+    Distros: openshift-origin
+  - Name: virtctl and libguestfs
+    File: virt-using-the-cli-tools
+    Distros: openshift-rosa-hcp
+- Name: Installing
+  Dir: install
+  Topics:
+  - Name: Preparing your cluster
+    File: preparing-cluster-for-virt
+  - Name: Installing OpenShift Virtualization
+    File: installing-virt
+  - Name: Uninstalling OpenShift Virtualization
+    File: uninstalling-virt
+- Name: Post-installation configuration
+  Dir: post_installation_configuration
+  Topics:
+  - Name: Post-installation configuration
+    File: virt-post-install-config
+  - Name: Node placement rules
+    File: virt-node-placement-virt-components
+  - Name: Network configuration
+    File: virt-post-install-network-config
+  - Name: Storage configuration
+    File: virt-post-install-storage-config
+  - Name: Configuring certificate rotation
+    File: virt-configuring-certificate-rotation
+- Name: Updating
+  Dir: updating
+  Topics:
+  - Name: Updating OpenShift Virtualization
+    File: upgrading-virt
+    Distros: openshift-rosa-hcp
+- Name: Creating a virtual machine
+  Dir: creating_vm
+  Topics:
+#  - Name: Overview
+#    File: virt-basic-vm-overview
+#  - Name: Setting up your environment
+#    File: virt-setting-up-environment
+  - Name: Creating VMs from instance types
+    File: virt-creating-vms-from-instance-types
+  - Name: Creating VMs from templates
+    File: virt-creating-vms-from-templates
+- Name: Advanced VM creation
+  Dir: creating_vms_advanced
+  Topics:
+#  - Name: Overview
+#    File: virt-advanced-vm-overview
+  - Name: Creating VMs in the web console
+    Dir: creating_vms_advanced_web
+    Topics:
+    - Name: Creating VMs from Red Hat images
+      File: virt-creating-vms-from-rh-images-overview
+    - Name: Creating VMs by importing images from web pages
+      File: virt-creating-vms-from-web-images
+    - Name: Creating VMs by uploading images
+      File: virt-creating-vms-uploading-images
+    - Name: Cloning VMs
+      File: virt-cloning-vms
+  - Name: Creating VMs using the CLI
+    Dir: creating_vms_cli
+    Topics:
+    - Name: Creating virtual machines from the command line
+      File: virt-creating-vms-from-cli
+    - Name: Creating VMs by using container disks
+      File: virt-creating-vms-from-container-disks
+    - Name: Creating VMs by cloning PVCs
+      File: virt-creating-vms-by-cloning-pvcs
+- Name: Managing VMs
+  Dir: managing_vms
+  Topics:
+  - Name: Installing the QEMU guest agent and VirtIO drivers
+    File: virt-installing-qemu-guest-agent
+  - Name: Connecting to VM consoles
+    File: virt-accessing-vm-consoles
+  - Name: Configuring SSH access to VMs
+    File: virt-accessing-vm-ssh
+  - Name: Editing virtual machines
+    File: virt-edit-vms
+  - Name: Editing boot order
+    File: virt-edit-boot-order
+  - Name: Deleting virtual machines
+    File: virt-delete-vms
+  - Name: Exporting virtual machines
+    File: virt-exporting-vms
+  - Name: Managing virtual machine instances
+    File: virt-manage-vmis
+  - Name: Controlling virtual machine states
+    File: virt-controlling-vm-states
+  - Name: Using virtual Trusted Platform Module devices
+    File: virt-using-vtpm-devices
+  - Name: Managing virtual machines with OpenShift Pipelines
+    File: virt-managing-vms-openshift-pipelines
+  - Name: Advanced virtual machine management
+    Dir: advanced_vm_management
+    Topics:
+    - Name: Working with resource quotas for virtual machines
+      File: virt-working-with-resource-quotas-for-vms
+    - Name: Specifying nodes for virtual machines
+      File: virt-specifying-nodes-for-vms
+    - Name: Configuring the default CPU model
+      File: virt-configuring-default-cpu-model
+    - Name: UEFI mode for virtual machines
+      File: virt-uefi-mode-for-vms
+    - Name: Configuring PXE booting for virtual machines
+      File: virt-configuring-pxe-booting
+# Huge pages not supported in ROSA
+#   - Name: Using huge pages with virtual machines
+#     File: virt-using-huge-pages-with-vms
+# CPU Manager not supported in ROSA
+#   - Name: Enabling dedicated resources for a virtual machine
+#     File: virt-dedicated-resources-vm
+    - Name: Scheduling virtual machines
+      File: virt-schedule-vms
+# Cannot create required machine config in ROSA as required
+#   - Name: Configuring PCI passthrough
+#     File: virt-configuring-pci-passthrough
+# Cannot create required machine config in ROSA as required
+#   - Name: Configuring virtual GPUs
+#     File: virt-configuring-virtual-gpus
+# Feature is TP, thus not supported in ROSA
+#   - Name: Enabling descheduler evictions on virtual machines
+#     File: virt-enabling-descheduler-evictions
+    - Name: About high availability for virtual machines
+      File: virt-high-availability-for-vms
+    - Name: Control plane tuning
+      File: virt-vm-control-plane-tuning
+# Need to review following are supported:
+#   - Name: Assigning compute resources
+#     File: virt-assigning-compute-resources
+#   - Name: About multi-queue functionality
+#     File: virt-about-multi-queue
+  - Name: VM disks
+    Dir: virtual_disks
+    Topics:
+    - Name: Hot-plugging VM disks
+      File: virt-hot-plugging-virtual-disks
+    - Name: Expanding VM disks
+      File: virt-expanding-vm-disks
+# Need to check if supported:
+#   - Name: Configuring shared volumes
+#     File: virt-configuring-shared-volumes-for-vms
+    - Name: Migrating VM disks to a different storage class
+      File: virt-migrating-storage-class
+- Name: Networking
+  Dir: vm_networking
+  Topics:
+  - Name: Networking configuration overview
+    File: virt-networking-overview
+  - Name: Connecting a VM to the default pod network
+    File: virt-connecting-vm-to-default-pod-network
+  - Name: Connecting a VM to a primary user-defined network
+    File: virt-connecting-vm-to-primary-udn
+  - Name: Exposing a VM by using a service
+    File: virt-exposing-vm-with-service
+# Not supported in ROSA/OSD
+#  - Name: Connecting a VM to a Linux bridge network
+#    File: virt-connecting-vm-to-linux-bridge
+#  - Name: Connecting a VM to an SR-IOV network
+#    File: virt-connecting-vm-to-sriov
+#  - Name: Using DPDK with SR-IOV
+#    File: virt-using-dpdk-with-sriov
+  - Name: Connecting a VM to an OVN-Kubernetes secondary network
+    File: virt-connecting-vm-to-ovn-secondary-network
+  - Name: Hot plugging secondary network interfaces
+    File: virt-hot-plugging-network-interfaces
+  - Name: Connecting a VM to a service mesh
+    File: virt-connecting-vm-to-service-mesh
+  - Name: Configuring a dedicated network for live migration
+    File: virt-dedicated-network-live-migration
+  - Name: Configuring and viewing IP addresses
+    File: virt-configuring-viewing-ips-for-vms
+# Tech Preview features not supported in ROSA/OSD
+#  - Name: Accessing a VM by using the cluster FQDN
+#    File: virt-accessing-vm-secondary-network-fqdn
+  - Name: Managing MAC address pools for network interfaces
+    File: virt-using-mac-address-pool-for-vms
+- Name: Storage
+  Dir: storage
+  Topics:
+  - Name: Storage configuration overview
+    File: virt-storage-config-overview
+  - Name: Configuring storage profiles
+    File: virt-configuring-storage-profile
+  - Name: Managing automatic boot source updates
+    File: virt-automatic-bootsource-updates
+  - Name: Reserving PVC space for file system overhead
+    File: virt-reserving-pvc-space-fs-overhead
+  - Name: Configuring local storage by using HPP
+    File: virt-configuring-local-storage-with-hpp
+  - Name: Enabling user permissions to clone data volumes across namespaces
+    File: virt-enabling-user-permissions-to-clone-datavolumes
+  - Name: Configuring CDI to override CPU and memory quotas
+    File: virt-configuring-cdi-for-namespace-resourcequota
+  - Name: Preparing CDI scratch space
+    File: virt-preparing-cdi-scratch-space
+  - Name: Using preallocation for data volumes
+    File: virt-using-preallocation-for-datavolumes
+  - Name: Managing data volume annotations
+    File: virt-managing-data-volume-annotations
+# Virtual machine live migration
+- Name: Live migration
+  Dir: live_migration
+  Topics:
+  - Name: About live migration
+    File: virt-about-live-migration
+  - Name: Configuring live migration
+    File: virt-configuring-live-migration
+  - Name: Initiating and canceling live migration
+    File: virt-initiating-live-migration
+# Node maintenance mode
+- Name: Nodes
+  Dir: nodes
+  Topics:
+  - Name: Node maintenance
+    File: virt-node-maintenance
+  - Name: Managing node labeling for obsolete CPU models
+    File: virt-managing-node-labeling-obsolete-cpu-models
+  - Name: Preventing node reconciliation
+    File: virt-preventing-node-reconciliation
+# Hiding in ROSA as user cannot cordon and drain nodes
+#  - Name: Deleting a failed node to trigger VM failover
+#    File: virt-triggering-vm-failover-resolving-failed-node
+- Name: Monitoring
+  Dir: monitoring
+  Topics:
+  - Name: Monitoring overview
+    File: virt-monitoring-overview
+# Hiding in ROSA/OSD as TP not supported
+#  - Name: Cluster checkup framework
+#    File: virt-running-cluster-checkups
+  - Name: Prometheus queries for virtual resources
+    File: virt-prometheus-queries
+  - Name: Virtual machine custom metrics
+    File: virt-exposing-custom-metrics-for-vms
+  - Name: Virtual machine health checks
+    File: virt-monitoring-vm-health
+  - Name: Runbooks
+    File: virt-runbooks
+- Name: Support
+  Dir: support
+  Topics:
+  - Name: Support overview
+    File: virt-support-overview
+  - Name: Collecting data for Red Hat Support
+    File: virt-collecting-virt-data
+    Distros: openshift-rosa-hcp
+  - Name: Troubleshooting
+    File: virt-troubleshooting
+- Name: Backup and restore
+  Dir: backup_restore
+  Topics:
+  - Name: Backup and restore by using VM snapshots
+    File: virt-backup-restore-snapshots
+  - Name: Backing up and restoring virtual machines
+    File: virt-backup-restore-overview
+#  - Name: Removed topics (Placeholder for topics removed from topic map)
+#    Dir: Removed_topics
+#    Topics:
+#    - Name: Collecting OKD Virtualization data for community report
+#      File: virt-collecting-virt-data
+#    - Name: Preparing to upgrade ROSA to 4.9
+#      File: rosa-upgrading-cluster-prepare
+#    - Name: Upgrading ROSA Classic clusters
+#      File: rosa-upgrading
diff --git a/modules/ephemeral-storage-additional-details-about-volumeattributes-on-shared-resource-pod-volumes.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-additional-details-about-volumeattributes-on-shared-resource-pod-volumes.adoc
similarity index 100%
rename from modules/ephemeral-storage-additional-details-about-volumeattributes-on-shared-resource-pod-volumes.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-additional-details-about-volumeattributes-on-shared-resource-pod-volumes.adoc
diff --git a/modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc
similarity index 100%
rename from modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc
diff --git a/modules/ephemeral-storage-integration-between-shared-resources-insights-operator-and-openshift-builds.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-integration-between-shared-resources-insights-operator-and-openshift-builds.adoc
similarity index 100%
rename from modules/ephemeral-storage-integration-between-shared-resources-insights-operator-and-openshift-builds.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-integration-between-shared-resources-insights-operator-and-openshift-builds.adoc
diff --git a/modules/ephemeral-storage-sharing-configmaps-across-namespaces.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-sharing-configmaps-across-namespaces.adoc
similarity index 100%
rename from modules/ephemeral-storage-sharing-configmaps-across-namespaces.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-sharing-configmaps-across-namespaces.adoc
diff --git a/modules/ephemeral-storage-sharing-secrets-across-namespaces.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-sharing-secrets-across-namespaces.adoc
similarity index 100%
rename from modules/ephemeral-storage-sharing-secrets-across-namespaces.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-sharing-secrets-across-namespaces.adoc
diff --git a/modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc
similarity index 100%
rename from modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc
diff --git a/modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc
similarity index 100%
rename from modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/Modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc
diff --git a/storage/container_storage_interface/ephemeral-storage-shared-resource-csi-driver-operator.adoc b/_unused_topics/Storage_Shared_Resource_CSI_Driver/ephemeral-storage-shared-resource-csi-driver-operator.adoc
similarity index 100%
rename from storage/container_storage_interface/ephemeral-storage-shared-resource-csi-driver-operator.adoc
rename to _unused_topics/Storage_Shared_Resource_CSI_Driver/ephemeral-storage-shared-resource-csi-driver-operator.adoc
diff --git a/modules/capi-creating-infrastructure-resource.adoc b/_unused_topics/capi-creating-infrastructure-resource.adoc
similarity index 97%
rename from modules/capi-creating-infrastructure-resource.adoc
rename to _unused_topics/capi-creating-infrastructure-resource.adoc
index c1c2df11dc8a..1528fb4b775b 100644
--- a/modules/capi-creating-infrastructure-resource.adoc
+++ b/_unused_topics/capi-creating-infrastructure-resource.adoc
@@ -46,6 +46,7 @@ This value must match the value for your platform.
 The following values are valid:
 * `AWSCluster`: The cluster is running on {aws-short}.
 * `GCPCluster`: The cluster is running on {gcp-short}.
+* `AzureCluster`: The cluster is running on {azure-first}.
 * `VSphereCluster`: The cluster is running on {vmw-short}.
 <3> Specify the name of the cluster.
 <4> Specify the details for your environment.
diff --git a/_unused_topics/capi-yaml-infrastructure-aws.adoc b/_unused_topics/capi-yaml-infrastructure-aws.adoc
new file mode 100644
index 000000000000..adaf51ac5ab9
--- /dev/null
+++ b/_unused_topics/capi-yaml-infrastructure-aws.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-infrastructure-aws_{context}"]
+= Sample YAML for a Cluster API infrastructure cluster resource on {aws-full}
+
+The infrastructure cluster resource is provider-specific and defines properties that all the compute machine sets in the cluster share, such as the region and subnets.
+The compute machine set references this resource when creating machines.
+
+In {product-title} {product-version}, the {cluster-capi-operator} generates this resource.
+The following sample YAML file is for informational purposes.
+User modification of this generated resource is not recommended.
+
+[source,yaml]
+----
+apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
+kind: AWSCluster # <1>
+metadata:
+  name: <cluster_name> # <2>
+  namespace: openshift-cluster-api
+spec:
+  controlPlaneEndpoint: # <3>
+    host: <control_plane_endpoint_address>
+    port: 6443
+  region: <region> # <4>
+----
+<1> Specifies the infrastructure kind for the cluster.
+This value matches the value for your platform.
+<2> Specifies the cluster ID as the name of the cluster.
+<3> Specifies the address of the control plane endpoint and the port to use to access it.
+<4> Specifies the {aws-short} region.
\ No newline at end of file
diff --git a/_unused_topics/capi-yaml-infrastructure-azure.adoc b/_unused_topics/capi-yaml-infrastructure-azure.adoc
new file mode 100644
index 000000000000..20c6c352e312
--- /dev/null
+++ b/_unused_topics/capi-yaml-infrastructure-azure.adoc
@@ -0,0 +1,51 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-infrastructure-azure_{context}"]
+= Sample YAML for a Cluster API infrastructure cluster resource on {azure-full}
+
+The infrastructure cluster resource is provider-specific and defines properties that all the compute machine sets in the cluster share, such as the region and subnets.
+The compute machine set references this resource when creating machines.
+
+In {product-title} {product-version}, the {cluster-capi-operator} generates this resource.
+The following sample YAML file is for informational purposes.
+User modification of this generated resource is not recommended.
+
+[source,yaml]
+----
+apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+kind: AzureCluster # <1>
+metadata:
+  name: <cluster_name> # <2>
+  namespace: openshift-cluster-api
+spec:
+  azureEnvironment: AzurePublicCloud
+  bastionSpec: {}
+  controlPlaneEndpoint: # <3>
+    host: <control_plane_endpoint_address>
+    port: 6443
+  identityRef: # <4>
+    kind: AzureClusterIdentity
+    name: <cluster_name>
+    namespace: openshift-cluster-api
+  location: westus # <5>
+  networkSpec:
+    apiServerLB:
+      backendPool: {}
+    nodeOutboundLB:
+      backendPool:
+        name: <cluster_name>
+      name: <cluster_name>
+    vnet:
+      name: <cluster_name>-vnet
+      resourceGroup: <cluster_name>-rg
+  resourceGroup: <cluster_name>-rg
+----
+<1> Specifies the infrastructure kind for the cluster.
+This value matches the value for your platform.
+<2> Specifies the cluster ID as the name of the cluster.
+<3> Specifies the address of the control plane endpoint and the port to use to access it.
+<4> The cluster identity that the {cluster-capi-operator} creates.
+<5> Specifies the {azure-short} region.
\ No newline at end of file
diff --git a/_unused_topics/capi-yaml-infrastructure-gcp.adoc b/_unused_topics/capi-yaml-infrastructure-gcp.adoc
new file mode 100644
index 000000000000..42bbe1450495
--- /dev/null
+++ b/_unused_topics/capi-yaml-infrastructure-gcp.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-infrastructure-gcp_{context}"]
+= Sample YAML for a Cluster API infrastructure cluster resource on {gcp-full}
+
+The infrastructure cluster resource is provider-specific and defines properties that all the compute machine sets in the cluster share, such as the region and subnets.
+The compute machine set references this resource when creating machines.
+
+In {product-title} {product-version}, the {cluster-capi-operator} generates this resource.
+The following sample YAML file is for informational purposes.
+User modification of this generated resource is not recommended.
+
+[source,yaml]
+----
+apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+kind: GCPCluster # <1>
+metadata:
+  name: <cluster_name> # <2>
+spec:
+  controlPlaneEndpoint: # <3>
+    host: <control_plane_endpoint_address>
+    port: 6443
+  network:
+    name: <cluster_name>-network
+  project: <project> # <4>
+  region: <region> # <5>
+----
+<1> Specifies the infrastructure kind for the cluster.
+This value matches the value for your platform.
+<2> Specifies the cluster ID as the name of the cluster.
+<3> Specifies the IP address of the control plane endpoint and the port used to access it.
+<4> Specifies the {gcp-short} project name.
+<5> Specifies the {gcp-short} region.
\ No newline at end of file
diff --git a/modules/capi-yaml-infrastructure-vsphere.adoc b/_unused_topics/capi-yaml-infrastructure-vsphere.adoc
similarity index 53%
rename from modules/capi-yaml-infrastructure-vsphere.adoc
rename to _unused_topics/capi-yaml-infrastructure-vsphere.adoc
index 403af3240647..bd213de70fbc 100644
--- a/modules/capi-yaml-infrastructure-vsphere.adoc
+++ b/_unused_topics/capi-yaml-infrastructure-vsphere.adoc
@@ -4,11 +4,15 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="capi-yaml-infrastructure-vsphere_{context}"]
-= Sample YAML for a Cluster API infrastructure resource on {vmw-full}
+= Sample YAML for a Cluster API infrastructure cluster resource on {vmw-full}
 
-The infrastructure resource is provider-specific and defines properties that are shared by all the compute machine sets in the cluster, such as the region and subnets.
+The infrastructure cluster resource is provider-specific and defines properties that all the compute machine sets in the cluster share, such as the region and subnets.
 The compute machine set references this resource when creating machines.
 
+In {product-title} {product-version}, the {cluster-capi-operator} generates this resource.
+The following sample YAML file is for informational purposes.
+User modification of this generated resource is not recommended.
+
 [source,yaml]
 ----
 apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
@@ -24,11 +28,11 @@ spec:
     name: <cluster_name>
   server: <vsphere_server> # <4>
 ----
-<1> Specify the infrastructure kind for the cluster.
-This value must match the value for your platform.
-<2> Specify the cluster ID as the name of the cluster.
-<3> Specify the IP address of the control plane endpoint and the port used to access it.
-<4> Specify the {vmw-short} server for the cluster.
+<1> Specifies the infrastructure kind for the cluster.
+This value matches the value for your platform.
+<2> Specifies the cluster ID as the name of the cluster.
+<3> Specifies the IP address of the control plane endpoint and the port used to access it.
+<4> Specifies the {vmw-short} server for the cluster.
 You can find this value on an existing {vmw-short} cluster by running the following command:
 +
 [source,terminal]
diff --git a/_unused_topics/manually-creating-iam-gcp.adoc b/_unused_topics/manually-creating-iam-gcp.adoc
index 2d315023f0fc..b243181fe2c4 100644
--- a/_unused_topics/manually-creating-iam-gcp.adoc
+++ b/_unused_topics/manually-creating-iam-gcp.adoc
@@ -14,7 +14,7 @@ include::modules/alternatives-to-storing-admin-secrets-in-kube-system.adoc[level
 .Additional resources
 
 * xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#cco-mode-gcp-workload-identity[Using manual mode with GCP Workload Identity]
-* xref:../../post_installation_configuration/cluster-tasks.adoc#post-install-rotate-remove-cloud-creds[Rotating or removing cloud provider credentials]
+* xref:../../post_installation_configuration/cluster-tasks.adoc#post-install-remove-cloud-creds[Removing cloud provider credentials]
 
 For a detailed description of all available CCO credential modes and their supported platforms, see xref:../../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[About the Cloud Credential Operator].
 
diff --git a/modules/olmv1-creating-a-pull-secret-for-catalogd.adoc b/_unused_topics/olmv1-creating-a-pull-secret-for-catalogd.adoc
similarity index 100%
rename from modules/olmv1-creating-a-pull-secret-for-catalogd.adoc
rename to _unused_topics/olmv1-creating-a-pull-secret-for-catalogd.adoc
diff --git a/_unused_topics/osdk-updating-v125-to-v128.adoc b/_unused_topics/osdk-updating-v125-to-v128.adoc
index 1ee8e317e20e..1bbbe0a635ab 100644
--- a/_unused_topics/osdk-updating-v125-to-v128.adoc
+++ b/_unused_topics/osdk-updating-v125-to-v128.adoc
@@ -3,8 +3,7 @@
 // * operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
 // * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
-// * operators/operator_sdk/java/osdk-java-updating-projects.adoc
+// * operators/operator_sdk/helm/
 
 ifeval::["{context}" == "osdk-golang-updating-projects"]
 :golang:
@@ -18,14 +17,6 @@ ifeval::["{context}" == "osdk-helm-updating-projects"]
 :helm:
 :type: Helm
 endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:hybrid:
-:type: Hybrid Helm
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:java:
-:type: Java
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-upgrading-projects_{context}"]
@@ -40,7 +31,7 @@ The following procedure updates an existing {type}-based Operator project for co
 
 .Procedure
 
-ifdef::helm,hybrid,java[]
+ifdef::helm[]
 * Find the `ose-kube-rbac-proxy` pull spec in the following files, and update the image tag to `v4.14`:
 endif::[]
 ifdef::ansible,golang[]
@@ -136,12 +127,4 @@ endif::[]
 ifeval::["{context}" == "osdk-helm-updating-projects"]
 :!helm:
 :!type:
-endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:!hybrid:
-:!type:
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:!java:
-:!type:
-endif::[]
+endif::[]
\ No newline at end of file
diff --git a/adding_service_cluster/adding-service.adoc b/adding_service_cluster/adding-service.adoc
index d99a497236f5..363bf2106eda 100644
--- a/adding_service_cluster/adding-service.adoc
+++ b/adding_service_cluster/adding-service.adoc
@@ -21,9 +21,3 @@ include::modules/adding-service-existing.adoc[leveloffset=+1]
 include::modules/access-service.adoc[leveloffset=+1]
 include::modules/deleting-service.adoc[leveloffset=+1]
 //include::modules/deleting-service-cli.adoc[leveloffset=+1]
-
-ifdef::openshift-rosa[]
-[role="_additional-resources"]
-== Additional resources
-* xref:../observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc#cluster-logging-collector-log-forward-cloudwatch_configuring-log-forwarding[Forwarding logs to Amazon CloudWatch]
-endif::[]
diff --git a/adding_service_cluster/rosa-available-services.adoc b/adding_service_cluster/rosa-available-services.adoc
index d81a769cfa5f..b8e1c94471dc 100644
--- a/adding_service_cluster/rosa-available-services.adoc
+++ b/adding_service_cluster/rosa-available-services.adoc
@@ -16,7 +16,6 @@ include::modules/aws-cloudwatch.adoc[leveloffset=+1]
 .Additional resources
 
 * link:https://aws.amazon.com/cloudwatch/[Amazon CloudWatch product information]
-* xref:../observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc#cluster-logging-collector-log-forward-cloudwatch_configuring-log-forwarding[Forwarding logs to Amazon CloudWatch]
 
 include::modules/osd-rhoam.adoc[leveloffset=+1]
 
@@ -38,5 +37,5 @@ include::modules/rosa-rhods.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_science/1[Red{nbsp}Hat OpenShift Data Science] documentation
-* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-data-science[Red{nbsp}Hat OpenShift Data Science] product page
+* link:https://docs.redhat.com/en/documentation/red_hat_openshift_ai/2025[Red{nbsp}Hat OpenShift AI] documentation
+* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-ai[Red{nbsp}Hat OpenShift AI] product page
diff --git a/applications/application-health.adoc b/applications/application-health.adoc
index ecd05107e5b1..42fefe17fdf1 100644
--- a/applications/application-health.adoc
+++ b/applications/application-health.adoc
@@ -22,9 +22,9 @@ include::modules/application-health-configuring.adoc[leveloffset=+1]
 include::modules/odc-monitoring-application-health-using-developer-perspective.adoc[leveloffset=+1]
 
 // cannot add health checks in web console
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/odc-adding-health-checks.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/odc-editing-health-checks.adoc[leveloffset=+1]
 
@@ -32,7 +32,7 @@ include::modules/odc-monitoring-health-checks.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * For details on switching to the *Developer* perspective in the web console, see xref:../web_console/web-console-overview.adoc#about-developer-perspective_web-console-overview[About the *Developer* perspective].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * For details on adding health checks while creating and deploying an application, see *Advanced Options* in the xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective] section.
diff --git a/applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc b/applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc
index c8db6869053b..4bc0cf51d69f 100644
--- a/applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc
+++ b/applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc
@@ -23,7 +23,7 @@ include::modules/sbo-categories-of-exposable-binding-data.adoc[leveloffset=+1]
 == Additional resources
 // * link:https://github.com/openshift/console/blob/master/frontend/packages/operator-lifecycle-manager/src/components/descriptors/reference/reference.md[OLM Descriptor Reference].
 // When OLM descriptors are supported again, add this additional resource.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-generating-csvs[Defining cluster service versions (CSVs)].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../applications/connecting_applications_to_services/projecting-binding-data.adoc#projecting-binding-data[Projecting binding data].
diff --git a/applications/connecting_applications_to_services/getting-started-with-service-binding.adoc b/applications/connecting_applications_to_services/getting-started-with-service-binding.adoc
index 0931cb8555be..535314cb299d 100644
--- a/applications/connecting_applications_to_services/getting-started-with-service-binding.adoc
+++ b/applications/connecting_applications_to_services/getting-started-with-service-binding.adoc
@@ -14,30 +14,30 @@ The {servicebinding-title} manages the data plane for workloads and backing serv
 [discrete]
 == Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to an {product-title} cluster using an account with `cluster-admin` permissions.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to an {product-title} cluster using an account with `dedicated-admin` permissions.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the `oc` CLI.
 * You have installed {servicebinding-title} from OperatorHub.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the 5.1.2 version of the Crunchy Postgres for Kubernetes Operator from OperatorHub using the *v5* Update channel. The installed Operator is available in an appropriate namespace, such as the `my-petclinic` namespace.
 +
 [NOTE]
 ====
 You can create the namespace using the `oc create namespace my-petclinic` command.
 ====
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the 5.1.2 version of the Crunchy Postgres for Kubernetes Operator from OperatorHub using the *v5* Update channel. The installed Operator is available in an appropriate project, such as the `my-petclinic` project.
 +
 [NOTE]
 ====
 You can create the project using the `oc new-project my-petclinic` command.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 //Creating a PostgreSQL database instance
 include::modules/sbo-creating-a-postgresql-database-instance.adoc[leveloffset=+1]
diff --git a/applications/connecting_applications_to_services/installing-sbo.adoc b/applications/connecting_applications_to_services/installing-sbo.adoc
index 9c99bd08dbc3..4d19708106cc 100644
--- a/applications/connecting_applications_to_services/installing-sbo.adoc
+++ b/applications/connecting_applications_to_services/installing-sbo.adoc
@@ -16,9 +16,9 @@ You can install {servicebinding-title} on {product-title} 4.7 and later.
 == Prerequisites
 
 * You have access to an {product-title} cluster using an account with `cluster-admin` permissions.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your cluster has the xref:../../installing/overview/cluster-capabilities.adoc#operator-marketplace_cluster-capabilities[Marketplace capability] enabled or the Red Hat Operator catalog source configured manually.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 //Installing Service Binding Operator using web console
 
diff --git a/applications/creating_applications/creating-apps-from-installed-operators.adoc b/applications/creating_applications/creating-apps-from-installed-operators.adoc
index 7e390fd46531..948b895e253b 100644
--- a/applications/creating_applications/creating-apps-from-installed-operators.adoc
+++ b/applications/creating_applications/creating-apps-from-installed-operators.adoc
@@ -13,7 +13,7 @@ have been installed by a cluster administrator.
 This guide walks developers through an example of creating applications from an
 installed Operator using the {product-title} web console.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
@@ -21,6 +21,6 @@ ifndef::openshift-rosa,openshift-dedicated[]
 xref:../../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Operators]
 guide for more on how Operators work and how the Operator Lifecycle Manager is
 integrated in {product-title}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/olm-creating-etcd-cluster-from-operator.adoc[leveloffset=+1]
diff --git a/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc b/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc
index 0f2b6cb72271..aac14ab28613 100644
--- a/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc
+++ b/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc
@@ -54,23 +54,23 @@ Note that certain options, such as *Pipelines*, *Event Source*, and *Import Virt
 endif::[]
 // dedicated-admin cannot install the Serverless or Virtualization operators, cannot create namespace.
 // xref: ../../cicd/pipelines/installing-pipelines.adoc#op-installing-pipelines-operator-in-web-console_installing-pipelines[OpenShift Pipelines Operator]
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 Note that the *Pipelines* option is displayed only when the OpenShift Pipelines Operator is installed.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [id="prerequisites_odc-creating-applications-using-developer-perspective"]
 == Prerequisites
 
 To create applications using the *Developer* perspective ensure that:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have xref:../../web_console/web-console.adoc#web-console[logged in to the web console].
 * You have created a project or have access to a project with the appropriate xref:../../authentication/using-rbac.adoc#default-roles_using-rbac[roles and permissions] to create applications and other workloads in {product-title}.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console.
 // * You have created a project or have access to a project with the appropriate xref:  ../../authentication/using-rbac.adoc#default-roles_using-rbac[roles and permissions] to create applications and other workloads in {product-title}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // dedicated-admin cannot install the Serverless operator. This ifdef should cover this. 
 ifdef::openshift-enterprise,openshift-webscale[]
diff --git a/openshift_images/templates-using-ruby-on-rails.adoc b/applications/creating_applications/templates-using-ruby-on-rails.adoc
similarity index 97%
rename from openshift_images/templates-using-ruby-on-rails.adoc
rename to applications/creating_applications/templates-using-ruby-on-rails.adoc
index 36aac95bb25c..15260d01b3fd 100644
--- a/openshift_images/templates-using-ruby-on-rails.adoc
+++ b/applications/creating_applications/templates-using-ruby-on-rails.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="templates-using-ruby-on-rails"]
-= Using Ruby on Rails
+= Creating applications using Ruby on Rails
 include::_attributes/common-attributes.adoc[]
 :context: templates-ruby-on-rails
 
diff --git a/openshift_images/using-templates.adoc b/applications/creating_applications/using-templates.adoc
similarity index 92%
rename from openshift_images/using-templates.adoc
rename to applications/creating_applications/using-templates.adoc
index 007f9b11ecd2..01fb7298d52b 100644
--- a/openshift_images/using-templates.adoc
+++ b/applications/creating_applications/using-templates.adoc
@@ -25,11 +25,11 @@ include::modules/templates-cli-generating-list-of-objects.adoc[leveloffset=+2]
 include::modules/templates-modifying-uploaded-template.adoc[leveloffset=+1]
 
 // cannot patch resource "templates" 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/templates-using-instant-app-quickstart.adoc[leveloffset=+1]
 
 include::modules/templates-quickstart.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/templates-writing.adoc[leveloffset=+1]
 
diff --git a/applications/deployments/managing-deployment-processes.adoc b/applications/deployments/managing-deployment-processes.adoc
index 9476174e930d..030ba3f10325 100644
--- a/applications/deployments/managing-deployment-processes.adoc
+++ b/applications/deployments/managing-deployment-processes.adoc
@@ -24,12 +24,12 @@ include::modules/deployments-setting-triggers.adoc[leveloffset=+3]
 include::modules/deployments-setting-resources.adoc[leveloffset=+2]
 
 // When the Nodes book is added to ROSA/OSD, check if this link is valid.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * For more information about resource limits and requests, see xref:../../nodes/clusters/nodes-cluster-resource-configure.adoc#nodes-cluster-resource-configure-about_nodes-cluster-resource-configure[Understanding managing application memory].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/deployments-scaling-manually.adoc[leveloffset=+2]
 include::modules/deployments-accessing-private-repos.adoc[leveloffset=+2]
diff --git a/applications/deployments/route-based-deployment-strategies.adoc b/applications/deployments/route-based-deployment-strategies.adoc
index 1bf4b78810d5..95ae73f43f81 100644
--- a/applications/deployments/route-based-deployment-strategies.adoc
+++ b/applications/deployments/route-based-deployment-strategies.adoc
@@ -34,8 +34,11 @@ include::modules/deployments-blue-green.adoc[leveloffset=+1]
 include::modules/deployments-ab-testing.adoc[leveloffset=+1]
 include::modules/deployments-ab-testing-lb.adoc[leveloffset=+2]
 
+ifndef::openshift-rosa-hcp[]
+// Remove conditionals when Networking content is in ROSA HCP 
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources
 
 * xref:../../networking/routes/route-configuration.adoc#nw-route-specific-annotations_route-configuration[Route-specific annotations].
+endif::[]
diff --git a/applications/index.adoc b/applications/index.adoc
index 48b8b95d5607..b909004e1cc5 100644
--- a/applications/index.adoc
+++ b/applications/index.adoc
@@ -15,26 +15,25 @@ Using projects, you can organize and manage applications in isolation. You can m
 
 After you create the project, you can xref:../applications/projects/working-with-projects.adoc#odc-providing-project-permissions-using-developer-perspective_projects[grant or revoke access to a project] and xref:../applications/projects/working-with-projects.adoc#odc-customizing-available-cluster-roles-using-the-web-console_projects[manage cluster roles] for the users using the Developer perspective. You can also xref:../applications/projects/configuring-project-creation.adoc#configuring-project-creation[edit the project configuration resource] while creating a project template that is used for automatic provisioning of new projects.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 Using the CLI, you can xref:../applications/projects/creating-project-other-user.adoc#creating-project-other-user[create a project as a different user] by impersonating a request to the {product-title} API. When you make a request to create a new project, the {product-title} uses an endpoint to provision the project according to a customizable template. As a cluster administrator, you can choose to xref:../applications/projects/configuring-project-creation.adoc#disabling-project-self-provisioning_configuring-project-creation[prevent an authenticated user group from self-provisioning new projects].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 As a user with dedicated administrator permissions, you can choose to xref:../applications/projects/configuring-project-creation.adoc#disabling-project-self-provisioning_configuring-project-creation[prevent an authenticated user group from self-provisioning new projects].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
 
 [id="working-on-application"]
 == Working on an application
 
 [id="creating-application"]
 === Creating an application
-
 To create applications, you must have created a project or have access to a project with the appropriate roles and permissions. You can create an application by using either xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[the Developer perspective in the web console], xref:../applications/creating_applications/creating-apps-from-installed-operators.adoc#creating-apps-from-installed-operators[installed Operators], or xref:../applications/creating_applications/creating-applications-using-cli.adoc#creating-applications-using-cli[the {oc-first}]. You can source the applications to be added to the project from Git, JAR files, devfiles, or the developer catalog.
 
 You can also use components that include source or binary code, images, and templates to create an application by using the {oc-first}. With the {product-title} web console, you can create an application from an Operator installed by a cluster administrator.
 
 [id="maintaining-application"]
 === Maintaining an application
-
 After you create the application, you can use the web console to xref:../applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc#odc-monitoring-project-and-application-metrics-using-developer-perspective[monitor your project or application metrics]. You can also xref:../applications/odc-editing-applications.adoc#odc-editing-applications[edit] or xref:../applications/odc-deleting-applications.adoc#odc-deleting-applications[delete] the application using the web console.  
 
 When the application is running, not all applications resources are used. As a cluster administrator, you can choose to xref:../applications/idling-applications.adoc#idling-applications[idle these scalable resources] to reduce resource consumption.
@@ -47,5 +46,4 @@ You can also use xref:../applications/working_with_helm_charts/understanding-hel
 
 [id="redhat-marketplace"]
 == Using the Red Hat Marketplace
-
-The xref:../applications/red-hat-marketplace.adoc#red-hat-marketplace[Red Hat Marketplace] is an open cloud marketplace where you can discover and access certified software for container-based environments that run on public clouds and on-premises.
+The xref:../applications/red-hat-marketplace.adoc#red-hat-marketplace[Red Hat Marketplace] is an open cloud marketplace where you can discover and access certified software for container-based environments that run on public clouds and on-premise.
diff --git a/applications/odc-editing-applications.adoc b/applications/odc-editing-applications.adoc
index 4ce1d7ae32e3..9e310a369b23 100644
--- a/applications/odc-editing-applications.adoc
+++ b/applications/odc-editing-applications.adoc
@@ -10,16 +10,16 @@ You can edit the configuration and the source code of the application you create
 
 == Prerequisites
 // When the Authentication book is added to ROSA/OSD, check if this link is valid.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have the appropriate xref:../authentication/using-rbac.adoc#default-roles_using-rbac[roles and permissions] in a project to create and modify applications in {product-title}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[created and deployed an application on {product-title} using the *Developer* perspective].
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have xref:../web_console/web-console.adoc#web-console[logged in to the web console] and have switched to xref:../web_console/web-console-overview.adoc#about-developer-perspective_web-console-overview[the *Developer* perspective].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console and have switched to the *Developer* perspective.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/odc-editing-source-code-using-developer-perspective.adoc[leveloffset=+1]
 
diff --git a/applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc b/applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc
index b6a72d2720ec..7f6090467339 100644
--- a/applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc
+++ b/applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc
@@ -13,12 +13,12 @@ The *Observe* view in the *Developer* perspective provides options to monitor yo
 == Prerequisites
 
 * You have xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[created and deployed applications on {product-title}].
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have xref:../web_console/web-console.adoc#web-console[logged in to the web console] and have switched to xref:../web_console/web-console-overview.adoc#about-developer-perspective_web-console-overview[the *Developer* perspective].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console and have switched to the *Developer* perspective.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/odc-monitoring-your-project-metrics.adoc[leveloffset=+1]
 
@@ -28,7 +28,12 @@ include::modules/odc-image-vulnerabilities-breakdown.adoc[leveloffset=+1]
 
 include::modules/odc-monitoring-your-app-vulnerabilities.adoc[leveloffset=+1]
 
+ifdef::openshift-rosa,openshift-dedicated[]
 [role="_additional-resources"]
 [id="additional-resources-odc-monitoring-project-and-application-metrics-using-developer-perspective"]
 == Additional resources
 * xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+endif::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+* xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
\ No newline at end of file
diff --git a/applications/odc-viewing-application-composition-using-topology-view.adoc b/applications/odc-viewing-application-composition-using-topology-view.adoc
index 4fab3cc5917b..67f00d2f1bb1 100644
--- a/applications/odc-viewing-application-composition-using-topology-view.adoc
+++ b/applications/odc-viewing-application-composition-using-topology-view.adoc
@@ -11,15 +11,15 @@ The *Topology* view in the *Developer* perspective of the web console provides a
 == Prerequisites
 To view your applications in the *Topology* view and interact with them, ensure that:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have xref:../web_console/web-console.adoc#web-console[logged in to the web console].
 * You have the appropriate xref:../authentication/using-rbac.adoc#default-roles_using-rbac[roles and permissions] in a project to create applications and other workloads in {product-title}.
 * You are in xref:../web_console/web-console-overview.adoc#about-developer-perspective_web-console-overview[the *Developer* perspective].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console.
 * You are in the *Developer* perspective.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/odc-viewing-application-topology.adoc[leveloffset=+1]
 
@@ -41,6 +41,6 @@ include::modules/odc-labels-and-annotations-used-for-topology-view.adoc[leveloff
 == Additional resources
 
 * See xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-importing-codebase-from-git-to-create-application_odc-creating-applications-using-developer-perspective[Importing a codebase from Git to create an application] for more information on creating an application from Git.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * See xref:../applications/odc-exporting-applications.adoc#odc-exporting-applications[Exporting applications].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/applications/projects/working-with-projects.adoc b/applications/projects/working-with-projects.adoc
index 5af175685d58..6dea112749db 100644
--- a/applications/projects/working-with-projects.adoc
+++ b/applications/projects/working-with-projects.adoc
@@ -12,12 +12,12 @@ isolation from other communities.
 [NOTE]
 ====
 Projects starting with `openshift-` and `kube-` are 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 xref:../../authentication/using-rbac.adoc#rbac-default-projects_using-rbac[default projects]. 
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 default projects. 
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 These projects host cluster components that run as pods and other infrastructure components. As such, {product-title} does not allow you to create projects starting with `openshift-` or `kube-` using the `oc new-project` command.
 ifndef::openshift-dedicated[]
 Cluster administrators can create these projects using the `oc adm new-project` command.
diff --git a/applications/pruning-objects.adoc b/applications/pruning-objects.adoc
index 9020f9db77bb..5d08939f2543 100644
--- a/applications/pruning-objects.adoc
+++ b/applications/pruning-objects.adoc
@@ -10,33 +10,34 @@ Over time, API objects created in {product-title} can accumulate in the
 cluster's etcd data store through normal user operations, such as when building
 and deploying applications.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 Cluster administrators can periodically prune older versions of objects from the
 cluster that are no longer required. For example, by pruning images you can delete
 older images and layers that are no longer in use, but are still taking up disk
 space.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 A user with the `dedicated-admin` role can periodically prune older versions of objects from the
 cluster that are no longer required. For example, by pruning images you can delete
 older images and layers that are no longer in use, but are still taking up disk
 space.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/pruning-basic-operations.adoc[leveloffset=+1]
 include::modules/pruning-groups.adoc[leveloffset=+1]
 include::modules/pruning-deployments.adoc[leveloffset=+1]
 include::modules/pruning-builds.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../cicd/builds/advanced-build-operations.adoc#builds-build-pruning-advanced-build-operations[Performing advanced builds -> Pruning builds]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/pruning-images.adoc[leveloffset=+1]
 //cannot create resource "serviceaccounts". cannot create resource "cronjobs"
-ifndef::openshift-rosa,openshift-dedicated[] 
+
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/pruning-images-manual.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -47,23 +48,24 @@ include::modules/pruning-images-manual.adoc[leveloffset=+1]
 xref:../registry/configuring-registry-operator.adoc#configuring-registry-operator[Image
 Registry Operator in {product-title}] for information on how to create a
 registry route.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // cannot patch resource "configs" 
-ifndef::openshift-rosa,openshift-dedicated[] 
+
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/pruning-hard-pruning-registry.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/pruning-cronjobs.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 // When the Operators book is added to ROSA/OSD, check if this link is valid.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../nodes/jobs/nodes-nodes-jobs.adoc#nodes-nodes-jobs_nodes-nodes-jobs[Running tasks in pods using jobs]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../applications/quotas/quotas-setting-across-multiple-projects.adoc#setting-quotas-across-multiple-projects[Resource quotas across multiple projects]
 // When the Operators book is added to ROSA/OSD, check if this link is valid.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/applications/red-hat-marketplace.adoc b/applications/red-hat-marketplace.adoc
index 99f239b589af..ac0936d05c40 100644
--- a/applications/red-hat-marketplace.adoc
+++ b/applications/red-hat-marketplace.adoc
@@ -6,6 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The link:https://marketplace.redhat.com[Red Hat Marketplace] is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premises.
+The link:https://marketplace.redhat.com[Red Hat Marketplace] is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premise.
 
 include::modules/red-hat-marketplace-features.adoc[leveloffset=+1]
diff --git a/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc b/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc
index bdb2b9cb1c14..823d7ce3e2d2 100644
--- a/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc
+++ b/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc
@@ -7,12 +7,12 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 You can create Helm releases on an {product-title} cluster using the following methods:
 
 * The CLI.
 * The *Developer* perspective of the web console.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 The *Developer Catalog*, in the *Developer* perspective of the web console, displays the Helm charts available in the cluster. By default, it lists the Helm charts from the Red Hat OpenShift Helm chart repository. For a list of the charts, see link:https://charts.openshift.io/index.yaml[the Red Hat `Helm index` file].
 
@@ -29,39 +29,39 @@ In the *Developer* perspective of the web console, you can use the *Helm* page t
 * View the list of the existing Helm chart repositories in the Repositories tab, which can also be easily distinguished as either cluster scoped or namespace scoped.
 
 // clusterroles.rbac.authorization.k8s.io is forbidden: user (groups=["dedicated-admins" "system:authenticated:oauth" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/helm-installing-a-helm-chart-on-an-openshift-cluster.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/odc-creating-helm-releases-using-developer-perspective.adoc[leveloffset=+1]
 
 == Using Helm in the web terminal
 
 // ROSA/OSD users can access the web terminal, but the docs are not currently present in the ROSA/OSD books.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 You can use Helm by xref:../../web_console/web_terminal/odc-using-web-terminal.adoc#odc-access-web-terminal_odc-using-web-terminal[Accessing the web terminal] in the *Developer* perspective of the web console.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 You can use Helm by Accessing the web terminal in the *Developer* perspective of the web console.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/helm-creating-a-custom-helm-chart-on-openshift.adoc[leveloffset=+1]
 
 //cannot create resource "helmchartrepositories" in API group "helm.openshift.io"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/helm-adding-helm-chart-repositories.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 //projecthelmchartrepositories.helm.openshift.io "azure-sample-repo" is forbidden: User cannot get resource "projecthelmchartrepositories" in API group "helm.openshift.io"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/helm-adding-namespace-scoped-helm-chart-repositories.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 //cannot create resource "helmchartrepositories" in API group "helm.openshift.io"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/helm-creating-credentials-and-certificates-to-add-helm-repositories.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/helm-filtering-helm-charts-by-certification-level.adoc[leveloffset=+1]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 //cannot patch resource "helmchartrepositories" in API group "helm.openshift.io"
 include::modules/helm-disabling-helm-chart-repositories.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/applications/working_with_helm_charts/installing-helm.adoc b/applications/working_with_helm_charts/installing-helm.adoc
index e7c65cf4953c..3ac0a5d8f744 100644
--- a/applications/working_with_helm_charts/installing-helm.adoc
+++ b/applications/working_with_helm_charts/installing-helm.adoc
@@ -15,7 +15,7 @@ You can also find the URL to the latest binaries from the {product-title} web co
 
 == On Linux
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Download the Helm binary and add it to your path:
 
 * Linux (x86_64, amd64)
@@ -38,15 +38,15 @@ ifndef::openshift-rosa,openshift-dedicated[]
 ----
 # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-ppc64le -o /usr/local/bin/helm
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Download the Linux x86_64 or Linux amd64 Helm binary and add it to your path:
 +
 [source,terminal]
 ----
 # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm
 ----
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Make the binary file executable:
 +
diff --git a/applications/working_with_helm_charts/odc-working-with-helm-releases.adoc b/applications/working_with_helm_charts/odc-working-with-helm-releases.adoc
index efd04fd76eee..351e17669223 100644
--- a/applications/working_with_helm_charts/odc-working-with-helm-releases.adoc
+++ b/applications/working_with_helm_charts/odc-working-with-helm-releases.adoc
@@ -10,12 +10,12 @@ You can use the *Developer* perspective in the web console to update, rollback,
 
 == Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console and have switched to xref:../../web_console/web-console-overview.adoc#about-developer-perspective_web-console-overview[the *Developer* perspective].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have logged in to the web console and have switched to the *Developer* perspective.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 
 include::modules/odc-upgrading-helm-release.adoc[leveloffset=+1]
diff --git a/applications/working_with_helm_charts/understanding-helm.adoc b/applications/working_with_helm_charts/understanding-helm.adoc
index 9dc558284ea6..65ee3b1c079e 100644
--- a/applications/working_with_helm_charts/understanding-helm.adoc
+++ b/applications/working_with_helm_charts/understanding-helm.adoc
@@ -27,12 +27,12 @@ Helm provides the ability to:
 * Package and share your applications as charts.
 
 // No tech preview in ROSA/OSD, added ifndef in case this note gets un-commented.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 //[NOTE]
 //====
 // In {product-title} 4.10 and 4.11, Helm is disabled for the xref: ../../web_console/web-console.adoc#multi-cluster-about_web-console[Multicluster Console] (Technology Preview).
 //====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 == Red Hat Certification of Helm charts for OpenShift
 
diff --git a/architecture/index.adoc b/architecture/index.adoc
index 3e750ad6a9f5..eb419440bbc9 100644
--- a/architecture/index.adoc
+++ b/architecture/index.adoc
@@ -25,7 +25,6 @@ endif::openshift-dedicated,openshift-rosa[]
 * For more information on storage, see xref:../storage/index.adoc#index[{product-title} storage].
 * For more information on authentication, see xref:../authentication/index.adoc#index[{product-title} authentication].
 * For more information on Operator Lifecycle Manager (OLM), see xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[OLM].
-* For more information on logging, see xref:../observability/logging/cluster-logging.adoc#cluster-logging[About Logging].
 // Topic not included in the OSD/ROSA docs
 ifndef::openshift-dedicated,openshift-rosa[]
 * For more information on over-the-air (OTA) updates, see xref:../updating/understanding_updates/intro-to-updates.adoc#understanding-openshift-updates[Introduction to OpenShift updates].
diff --git a/architecture/mce-overview-ocp.adoc b/architecture/mce-overview-ocp.adoc
index e1f9d07b5b5f..94ec6e1854de 100644
--- a/architecture/mce-overview-ocp.adoc
+++ b/architecture/mce-overview-ocp.adoc
@@ -22,7 +22,7 @@ When you enable multicluster engine on {product-title}, you gain the following c
 * Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of {product-title}, such as {sno} on bare metal. The Infrastructure Operator includes xref:../edge_computing/ztp-deploying-far-edge-clusters-at-scale.adoc#ztp-challenges-of-far-edge-deployments_ztp-deploying-far-edge-clusters-at-scale[{ztp-first}], which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes.
 * Open cluster management, which provides resources to manage Kubernetes clusters.
 
-The multicluster engine is included with your {product-title} support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the {product-title} cluster and then install the operator. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator].
+The multicluster engine is included with your {product-title} support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the {product-title} cluster and then install the operator. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator].
 
 [id="mce-on-rhacm"]
 == Cluster management with Red Hat Advanced Cluster Management
@@ -32,4 +32,4 @@ If you need cluster management capabilities beyond what {product-title} with mul
 [id="mce-additional-resources-ocp"]
 == Additional resources
 
-For the complete documentation for multicluster engine, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview[Cluster lifecycle with multicluster engine documentation], which is part of the product documentation for Red Hat Advanced Cluster Management.
\ No newline at end of file
+For the complete documentation for multicluster engine, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview[Cluster lifecycle with multicluster engine documentation], which is part of the product documentation for Red Hat Advanced Cluster Management.
\ No newline at end of file
diff --git a/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc b/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc
index 6d2d4a247e75..3b6f55d07d8f 100644
--- a/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc
+++ b/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc
@@ -2,17 +2,17 @@
 [id="assuming-an-aws-iam-role-for-a-service-account"]
 = Assuming an AWS IAM role for a service account
 include::_attributes/common-attributes.adoc[]
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::_attributes/attributes-openshift-dedicated.adoc[]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 :context: assuming-an-aws-iam-role-for-a-service-account
 
 toc::[]
 
 [role="_abstract"]
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 In {product-title} clusters that use the AWS Security Token Service (STS), the OpenShift API server can be enabled to project signed service account tokens that can be used to assume an AWS Identity and Access Management (IAM) role in a pod. If the assumed IAM role has the required AWS permissions, the pods can authenticate against the AWS API using temporary STS credentials to perform AWS operations.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 You can use the pod identity webhook to project service account tokens to assume an AWS Identity and Access Management (IAM) role for your own workloads. If the assumed IAM role has the required AWS permissions, the pods can run AWS SDK operations by using temporary STS credentials.
 
@@ -37,6 +37,6 @@ include::modules/verifying-the-assumed-iam-role-in-your-pod.adoc[leveloffset=+2]
 
 * For more information about installing and using the AWS Boto3 SDK for Python, see the link:https://boto3.amazonaws.com/v1/documentation/api/latest/index.html[AWS Boto3 documentation].
 
-ifdef::openshift-rosa,openshift-dedicated[]
-* For general information about webhook admission plugins for OpenShift, see link:https://docs.openshift.com/container-platform/4.17/architecture/admission-plug-ins.html#admission-webhooks-about_admission-plug-ins[Webhook admission plugins] in the OpenShift Container Platform documentation.
-endif::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+* For general information about webhook admission plugins for OpenShift, see link:https://docs.openshift.com/container-platform/4.18/architecture/admission-plug-ins.html#admission-webhooks-about_admission-plug-ins[Webhook admission plugins] in the OpenShift Container Platform documentation.
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/authentication/bound-service-account-tokens.adoc b/authentication/bound-service-account-tokens.adoc
index dfd7b643c9fa..791036d2c566 100644
--- a/authentication/bound-service-account-tokens.adoc
+++ b/authentication/bound-service-account-tokens.adoc
@@ -21,9 +21,9 @@ include::modules/bound-sa-tokens-configuring-externally.adoc[leveloffset=+1]
 .Additional resources
 
 // This xref target does not exist in the OSD/ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-gracefully_nodes-nodes-rebooting[Rebooting a node gracefully]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 * xref:../authentication/understanding-and-creating-service-accounts.adoc#service-accounts-managing_understanding-service-accounts[Creating service accounts]
 
diff --git a/authentication/index.adoc b/authentication/index.adoc
index 7004a1417235..54d98755b7c7 100644
--- a/authentication/index.adoc
+++ b/authentication/index.adoc
@@ -10,12 +10,12 @@ include::modules/authentication-authorization-common-terms.adoc[leveloffset=+1]
 [id="authentication-overview"]
 == About authentication in {product-title}
 To control access to an {product-title} cluster,
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 a cluster administrator
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 an administrator with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can configure xref:../authentication/understanding-authentication.adoc#understanding-authentication[user authentication] and ensure only approved users access the cluster.
 
 To interact with an {product-title} cluster, users must first authenticate to the {product-title} API in some way. You can authenticate by providing an xref:../authentication/understanding-authentication.adoc#rbac-api-authentication_understanding-authentication[OAuth access token or an X.509 client certificate] in your requests to the {product-title} API.
@@ -25,11 +25,11 @@ To interact with an {product-title} cluster, users must first authenticate to th
 If you do not present a valid access token or certificate, your request is unauthenticated and you receive an HTTP 401 error.
 ====
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 An administrator can configure authentication by configuring an identity provider. You can define any xref:../authentication/sd-configuring-identity-providers.adoc#understanding-idp-supported_sd-configuring-identity-providers[supported identity provider in {product-title}] and add it to your cluster.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 An administrator can configure authentication through the following tasks:
 
 * Configuring an identity provider: You can define any xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[supported identity provider in {product-title}] and add it to your cluster.
@@ -50,7 +50,7 @@ When users send a request for an OAuth token, they must specify either a default
 
 * Managing cloud provider credentials using the xref:../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[Cloud Credentials Operator]: Cluster components use cloud provider credentials to get permissions required to perform cluster-related tasks.
 * Impersonating a system admin user: You can grant cluster administrator permissions to a user by xref:../authentication/impersonating-system-admin.adoc#impersonating-system-admin[impersonating a system admin user].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="authorization-overview"]
 == About authorization in {product-title}
@@ -68,25 +68,25 @@ You can manage authorization for {product-title} through the following tasks:
 
 * Creating a xref:../authentication/using-rbac.adoc#creating-local-role_using-rbac[local role] and assigning it to a user or group.
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Creating a cluster role and assigning it to a user or group: {product-title} includes a set of xref:../authentication/using-rbac.adoc#default-roles_using-rbac[default cluster roles]. You can create additional xref:../authentication/using-rbac.adoc#creating-cluster-role_using-rbac[cluster roles] and xref:../authentication/using-rbac.adoc#adding-roles_using-rbac[add them to a user or group].
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Assigning a cluster role to a user or group: {product-title} includes a set of xref:../authentication/using-rbac.adoc#default-roles_using-rbac[default cluster roles]. You can xref:../authentication/using-rbac.adoc#adding-roles_using-rbac[add them to a user or group].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Creating a cluster-admin user: By default, your cluster has only one cluster administrator called `kubeadmin`. You can xref:../authentication/using-rbac.adoc#creating-cluster-admin_using-rbac[create another cluster administrator]. Before creating a cluster administrator, ensure that you have configured an identity provider.
 +
 [NOTE]
 ====
 After creating the cluster admin user, xref:../authentication/remove-kubeadmin.adoc#removing-kubeadmin_removing-kubeadmin[delete the existing kubeadmin user] to improve cluster security.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 * Creating cluster-admin and dedicated-admin users: The user who created the {product-title} cluster can grant access to other xref:../authentication/using-rbac.adoc#rosa-create-cluster-admins_using-rbac[`cluster-admin`] and xref:../authentication/using-rbac.adoc#rosa-create-dedicated-cluster-admins_using-rbac[`dedicated-admin`] users.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-dedicated[]
 * Granting administrator privileges to users: You can xref:../authentication/using-rbac.adoc#osd-grant-admin-privileges_using-rbac[grant `dedicated-admin` privileges to users].
diff --git a/authentication/ldap-syncing.adoc b/authentication/ldap-syncing.adoc
index 802f055b0f45..a1bbda824cee 100644
--- a/authentication/ldap-syncing.adoc
+++ b/authentication/ldap-syncing.adoc
@@ -9,9 +9,9 @@ toc::[]
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 As an administrator,
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As an administrator with the `dedicated-admin` role,
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 you can use groups to manage users, change
 their permissions, and enhance collaboration. Your organization may have already
 created user groups and stored them in an LDAP server. {product-title} can sync
@@ -20,15 +20,15 @@ your groups in one place. {product-title} currently supports group sync with
 LDAP servers using three common schemas for defining group membership: RFC 2307,
 Active Directory, and augmented Active Directory.
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information on configuring LDAP, see
 xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[Configuring an LDAP identity provider].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information on configuring LDAP, see
 xref:../authentication/sd-configuring-identity-providers.adoc#config-ldap-idp_sd-configuring-identity-providers[Configuring an LDAP identity provider].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 [NOTE]
@@ -36,12 +36,12 @@ ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 You must have `cluster-admin` privileges to sync groups.
 ====
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 You must have `dedicated-admin` privileges to sync groups.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/ldap-syncing-about.adoc[leveloffset=+1]
 include::modules/ldap-syncing-config-rfc2307.adoc[leveloffset=+2]
@@ -54,7 +54,7 @@ include::modules/ldap-syncing-running-subset.adoc[leveloffset=+2]
 include::modules/ldap-syncing-pruning.adoc[leveloffset=+1]
 
 // OSD and ROSA dedicated-admins cannot create the cluster roles and cluster role bindings required for this procedure.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Automatically syncing LDAP groups
 include::modules/ldap-auto-syncing.adoc[leveloffset=+1]
 
@@ -63,7 +63,7 @@ include::modules/ldap-auto-syncing.adoc[leveloffset=+1]
 
 * xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[Configuring an LDAP identity provider]
 * xref:../nodes/jobs/nodes-nodes-jobs.adoc#nodes-nodes-jobs-creating-cron_nodes-nodes-jobs[Creating cron jobs]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/ldap-syncing-examples.adoc[leveloffset=+1]
 include::modules/ldap-syncing-rfc2307.adoc[leveloffset=+2]
diff --git a/authentication/managing-security-context-constraints.adoc b/authentication/managing-security-context-constraints.adoc
index 0a67c077b59f..94ac04555d6d 100644
--- a/authentication/managing-security-context-constraints.adoc
+++ b/authentication/managing-security-context-constraints.adoc
@@ -13,14 +13,14 @@ Default SCCs are created during installation and when you install some Operators
 [IMPORTANT]
 ====
 Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
 endif::[]
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
-ifdef::openshift-origin,openshift-enterprise,openshift-webscale,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-webscale,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see xref:../authentication/managing-security-context-constraints.adoc#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
 endif::[]
@@ -47,4 +47,9 @@ include::modules/security-context-constraints-command-reference.adoc[leveloffset
 [id="additional-resources_configuring-internal-oauth"]
 == Additional resources
 
-* xref:../support/getting-support.adoc#getting-support[Getting support]
\ No newline at end of file
+ifndef::openshift-rosa-hcp[]
+* xref:../support/getting-support.adoc#getting-support[Getting support]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.openshift.com/rosa/support/getting-support.html[Getting support]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc b/authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc
index db3c5ecae040..b7bb544055db 100644
--- a/authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc
+++ b/authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc
@@ -17,7 +17,7 @@ The CCO uses the `admin` credential to process the `CredentialsRequest` objects
 With mint mode, each cluster component has only the specific permissions it requires.
 Cloud credential reconciliation is automatic and continuous so that components can perform actions that require additional credentials or permissions.
 
-For example, a minor version cluster update (such as updating from {product-title} 4.16 to 4.17) might include an updated `CredentialsRequest` resource for a cluster component.
+For example, a minor version cluster update (such as updating from {product-title} {ocp-nminus1} to {product-version}) might include an updated `CredentialsRequest` resource for a cluster component.
 The CCO, operating in mint mode, uses the `admin` credential to process the `CredentialsRequest` resource and create users with limited permissions to satisfy the updated authentication requirements.
 
 [NOTE]
diff --git a/authentication/sd-configuring-identity-providers.adoc b/authentication/sd-configuring-identity-providers.adoc
index 1a55e98fd52e..1c1f1f93d936 100644
--- a/authentication/sd-configuring-identity-providers.adoc
+++ b/authentication/sd-configuring-identity-providers.adoc
@@ -8,9 +8,9 @@ toc::[]
 
 After your {product-title} cluster is created, you must configure identity providers to determine how users log in to access the cluster.
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 The following topics describe how to configure an identity provider using {cluster-manager} console. Alternatively, you can use the ROSA CLI (`rosa`) to configure an identity provider and access the cluster.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/understanding-idp.adoc[leveloffset=+1]
 include::modules/identity-provider-parameters.adoc[leveloffset=+2]
diff --git a/authentication/understanding-and-creating-service-accounts.adoc b/authentication/understanding-and-creating-service-accounts.adoc
index ed1854708470..d0cec995b025 100644
--- a/authentication/understanding-and-creating-service-accounts.adoc
+++ b/authentication/understanding-and-creating-service-accounts.adoc
@@ -8,6 +8,8 @@ toc::[]
 
 include::modules/service-accounts-overview.adoc[leveloffset=+1]
 
+include::modules/service-account-auto-secret-removed.adoc[leveloffset=+2]
+
 // include::modules/service-accounts-enabling-authentication.adoc[leveloffset=+1]
 
 include::modules/service-accounts-creating.adoc[leveloffset=+1]
diff --git a/authentication/understanding-and-managing-pod-security-admission.adoc b/authentication/understanding-and-managing-pod-security-admission.adoc
index d62ce6968c97..c4ecac8a8f2a 100644
--- a/authentication/understanding-and-managing-pod-security-admission.adoc
+++ b/authentication/understanding-and-managing-pod-security-admission.adoc
@@ -34,14 +34,17 @@ include::modules/security-context-constraints-psa-label.adoc[leveloffset=+1]
 include::modules/security-context-constraints-psa-rectifying.adoc[leveloffset=+1]
 
 // OSD and ROSA dedicated-admin users cannot use the must-gather tool.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Identifying pod security violations
 include::modules/security-context-constraints-psa-alert-eval.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [role="_additional-resources"]
 [id="additional-resources_managing-pod-security-admission"]
 == Additional resources
 
+// Module not included in the HCP distro
+ifndef::openshift-rosa-hcp[]
 * xref:../security/audit-log-view.adoc#nodes-nodes-audit-log-basic-viewing_audit-log-view[Viewing audit logs]
+endif::openshift-rosa-hcp[]
 * xref:../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing security context constraints]
diff --git a/authentication/using-rbac.adoc b/authentication/using-rbac.adoc
index 410f11dd3da1..acefe675e3e9 100644
--- a/authentication/using-rbac.adoc
+++ b/authentication/using-rbac.adoc
@@ -18,7 +18,7 @@ include::modules/rbac-viewing-local-roles.adoc[leveloffset=+1]
 
 include::modules/rbac-adding-roles.adoc[leveloffset=+1]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/rbac-creating-local-role.adoc[leveloffset=+1]
 
 include::modules/rbac-creating-cluster-role.adoc[leveloffset=+1]
@@ -26,18 +26,18 @@ endif::[]
 
 include::modules/rbac-local-role-binding-commands.adoc[leveloffset=+1]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/rbac-cluster-role-binding-commands.adoc[leveloffset=+1]
 endif::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/rbac-creating-cluster-admin.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 include::modules/rosa-create-cluster-admins.adoc[leveloffset=+1]
 include::modules/rosa-create-dedicated-cluster-admins.adoc[leveloffset=+1]
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-dedicated[]
 include::modules/osd-grant-admin-privileges.adoc[leveloffset=+1]
diff --git a/backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-scheduling-backups-doc.adoc b/backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-scheduling-backups-doc.adoc
index f37336ee6a4e..135e8f5f7a3d 100644
--- a/backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-scheduling-backups-doc.adoc
+++ b/backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-scheduling-backups-doc.adoc
@@ -83,4 +83,4 @@ Enter the minutes value between quotation marks (`" "`).
 [source,terminal]
 ----
 $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
-----
+----
\ No newline at end of file
diff --git a/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp.adoc b/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp.adoc
index 02294607531d..3b936c1594d9 100644
--- a/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp.adoc
@@ -61,6 +61,7 @@ include::modules/oadp-configuring-noobaa-for-dr.adoc[leveloffset=+1]
 
 include::modules/about-oadp-update-channels.adoc[leveloffset=+1]
 include::modules/about-installing-oadp-on-multiple-namespaces.adoc[leveloffset=+1]
+include::modules/oadp-support-backup-data-immutability.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc b/backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
index 82fa49baa3df..d07cd4e5243a 100644
--- a/backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
@@ -6,17 +6,35 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-{oadp-short} includes a built-in Data Mover that you can use to move Container Storage Interface (CSI) volume snapshots to a remote object store. The built-in Data Mover allows you to restore stateful applications from the remote object store if a failure, accidental deletion, or corruption of the cluster occurs. It uses xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-about-kopia.adoc#oadp-about-kopia[Kopia] as the uploader mechanism to read the snapshot data and write to the unified repository.
+{oadp-first} includes a built-in Data Mover that you can use to move Container Storage Interface (CSI) volume snapshots to a remote object store. The built-in Data Mover allows you to restore stateful applications from the remote object store if a failure, accidental deletion, or corruption of the cluster occurs. It uses xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-about-kopia.adoc#oadp-about-kopia[Kopia] as the uploader mechanism to read the snapshot data and write to the unified repository.
 
 {oadp-short} supports CSI snapshots on the following:
 
 * {odf-full}
 * Any other cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API
 
-[IMPORTANT]
-====
+// ** suggest removing the admonition and replacing with a clear section **
+//
+// [IMPORTANT]
+// ====
+// The {oadp-short} built-in Data Mover, which was introduced in {oadp-short} 1.3 as a Technology Preview, is now fully supported for both containerized and virtual machine workloads.
+// ====
+
+[id="oadp-data-mover-support_{context}"]
+== Data Mover support
+
 The {oadp-short} built-in Data Mover, which was introduced in {oadp-short} 1.3 as a Technology Preview, is now fully supported for both containerized and virtual machine workloads.
-====
+
+.Supported
+
+The Data Mover backups taken with {oadp-short} 1.3 can be restored using {oadp-short} 1.3, 1.4, and later. This is supported.
+
+.Not supported
+
+Backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 using the Data Mover feature cannot be restored using {oadp-short} 1.3 and later. Therefore, it is not supported.
+
+{oadp-short} 1.1 and {oadp-short} 1.2 are no longer supported. The DataMover feature in {oadp-short} 1.1 or {oadp-short} 1.2 was a Technology Preview and was never supported. DataMover backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 cannot be restored on later versions of {oadp-short}.
+
 
 [id="enabling-oadp-data-mover_{context}"]
 == Enabling the built-in Data Mover
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc
index 5999b11f0a1c..74b9379e7099 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc
@@ -30,7 +30,7 @@ include::modules/oadp-ssec-encrypted-backups.adoc[leveloffset=+2]
 [role="_additional-resources_1"]
 .Additional resources
 
-You can also download the file with the additional encryption key backed up with Velcro by running a different command. See xref:../../../backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc#oadp-ssec-encrypted-backups-velero_installing-oadp-aws[Downloading a file with an SSE-C encryption key for files backed up by Velero].
+You can also download the file with the additional encryption key backed up with Velero by running a different command. See xref:../../../backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc#oadp-ssec-encrypted-backups-velero_installing-oadp-aws[Downloading a file with an SSE-C encryption key for files backed up by Velero].
 
 include::modules/oadp-ssec-encrypted-backups-velero.adoc[leveloffset=+3]
 
@@ -52,6 +52,7 @@ include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-configuring-aws-md5sum.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-dpa-multiple-bsl.adoc[leveloffset=+1]
 include::modules/oadp-enabling-csi-dpa.adoc[leveloffset=+2]
 include::modules/oadp-about-disable-node-agent-dpa.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-azure.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-azure.adoc
index 899a3751c1d7..89d847a54b7e 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-azure.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-azure.adoc
@@ -39,6 +39,7 @@ include::modules/oadp-self-signed-certificate.adoc[leveloffset=+2]
 // include::modules/oadp-installing-dpa-1-2-and-earlier.adoc[leveloffset=+1]
 include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-enabling-csi-dpa.adoc[leveloffset=+2]
 include::modules/oadp-about-disable-node-agent-dpa.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.adoc
index 8d39cf3d46c0..8d0b1add23b6 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.adoc
@@ -40,6 +40,7 @@ include::modules/oadp-self-signed-certificate.adoc[leveloffset=+2]
 include::modules/oadp-gcp-wif-cloud-authentication.adoc[leveloffset=+1]
 include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-enabling-csi-dpa.adoc[leveloffset=+2]
 include::modules/oadp-about-disable-node-agent-dpa.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ibm-cloud.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ibm-cloud.adoc
index c56f78758c7f..e2e5348ec22c 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ibm-cloud.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ibm-cloud.adoc
@@ -25,6 +25,8 @@ include::modules/oadp-setting-resource-limits-and-requests.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+1]
 // include the module for client burst and qps config
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+// include module for image pull policy setting
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 // include the module for configuring multiple BSL
 include::modules/oadp-configuring-dpa-multiple-bsl.adoc[leveloffset=+1]
 // include the module for disabling node agent in the DPA
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-kubevirt.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-kubevirt.adoc
index 88dcb8a74a73..8fe2f70adff1 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-kubevirt.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-kubevirt.adoc
@@ -48,6 +48,7 @@ include::modules/oadp-backup-single-vm.adoc[leveloffset=+1]
 include::modules/oadp-restore-single-vm.adoc[leveloffset=+1]
 include::modules/oadp-restore-single-vm-from-multiple-vm-backup.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-incremental-backup-support.adoc[leveloffset=+1]
 
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc
index 83eea3722377..1cd9da28706d 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc
@@ -46,6 +46,7 @@ include::modules/oadp-self-signed-certificate.adoc[leveloffset=+2]
 // include::modules/oadp-installing-dpa-1-2-and-earlier.adoc[leveloffset=+1]
 include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-enabling-csi-dpa.adoc[leveloffset=+2]
 include::modules/oadp-about-disable-node-agent-dpa.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc
index 3cf64bb4fa68..5ee61e5385d4 100644
--- a/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc
+++ b/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc
@@ -49,6 +49,7 @@ include::modules/oadp-self-signed-certificate.adoc[leveloffset=+2]
 // include::modules/oadp-installing-dpa-1-2-and-earlier.adoc[leveloffset=+1]
 include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 include::modules/oadp-configuring-client-burst-qps.adoc[leveloffset=+1]
+include::modules/oadp-configuring-imagepullpolicy.adoc[leveloffset=+1]
 include::modules/oadp-configuring-node-agents.adoc[leveloffset=+2]
 include::modules/oadp-creating-object-bucket-claim.adoc[leveloffset=+2]
 include::modules/oadp-enabling-csi-dpa.adoc[leveloffset=+2]
diff --git a/operators/operator_sdk/java/_attributes b/backup_and_restore/application_backup_and_restore/oadp-3scale/_attributes
similarity index 100%
rename from operators/operator_sdk/java/_attributes
rename to backup_and_restore/application_backup_and_restore/oadp-3scale/_attributes
diff --git a/backup_and_restore/application_backup_and_restore/oadp-3scale/backing-up-and-restoring-3scale-by-using-oadp.adoc b/backup_and_restore/application_backup_and_restore/oadp-3scale/backing-up-and-restoring-3scale-by-using-oadp.adoc
new file mode 100644
index 000000000000..7381a8a42e7a
--- /dev/null
+++ b/backup_and_restore/application_backup_and_restore/oadp-3scale/backing-up-and-restoring-3scale-by-using-oadp.adoc
@@ -0,0 +1,43 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="backing-up-and-restoring-3scale-by-using-oadp_{context}"]
+= Backing up and restoring 3scale by using OADP
+include::_attributes/common-attributes.adoc[]
+:context: backing-up-and-restoring-3scale-by-using-oadp
+
+toc::[]
+
+With Red Hat 3scale API Management (APIM), you can manage your APIs for internal or external users. Share, secure, distribute, control, and monetize your APIs on an infrastructure platform built with performance, customer control, and future growth in mind.
+You can deploy 3scale components on-premise, in the cloud, as a managed service, or in any combination based on your requirement.
+
+[NOTE]
+====
+In this example, the non-service affecting approach is used to back up and restore 3scale on-cluster storage by using the {oadp-first} Operator.
+Additionally, ensure that you are restoring 3scale on the same cluster where it was backed up from. If you want to restore 3scale on a different cluster, ensure that both clusters are using the same custom domain.
+====
+
+.Prerequisites
+
+* You installed and configured Red Hat 3scale. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_3scale_api_management/2.15/html/installing_red_hat_3scale_api_management[Red Hat 3scale API Management].
+
+include::modules/creating-the-data-protection-application.adoc[leveloffset=+1]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc#oadp-installing-dpa_installing-oadp-aws[Installing the Data Protection Application]
+
+include::modules/backing-up-the-3scale-operator.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-creating-backup-cr.adoc#oadp-creating-backup-cr-doc[Creating a Backup CR]
+
+include::modules/backing-up-the-mysql-database.adoc[leveloffset=+1]
+
+include::modules/backing-up-the-backend-redis-database.adoc[leveloffset=+1]
+
+include::modules/restoring-the-secrets-and-apimanager.adoc[leveloffset=+1]
+
+include::modules/restoring-the-mysql-database.adoc[leveloffset=+1]
+
+include::modules/restoring-the-backend-redis-database.adoc[leveloffset=+1]
+
+include::modules/scaling-up-the-3scale-operator-and-deployment.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/operators/operator_sdk/java/images b/backup_and_restore/application_backup_and_restore/oadp-3scale/images
similarity index 100%
rename from operators/operator_sdk/java/images
rename to backup_and_restore/application_backup_and_restore/oadp-3scale/images
diff --git a/operators/operator_sdk/java/modules b/backup_and_restore/application_backup_and_restore/oadp-3scale/modules
similarity index 100%
rename from operators/operator_sdk/java/modules
rename to backup_and_restore/application_backup_and_restore/oadp-3scale/modules
diff --git a/operators/operator_sdk/java/snippets b/backup_and_restore/application_backup_and_restore/oadp-3scale/snippets
similarity index 100%
rename from operators/operator_sdk/java/snippets
rename to backup_and_restore/application_backup_and_restore/oadp-3scale/snippets
diff --git a/backup_and_restore/application_backup_and_restore/oadp-features-plugins.adoc b/backup_and_restore/application_backup_and_restore/oadp-features-plugins.adoc
index 79cd47ad66f9..bfd7b1c4cb7a 100644
--- a/backup_and_restore/application_backup_and_restore/oadp-features-plugins.adoc
+++ b/backup_and_restore/application_backup_and_restore/oadp-features-plugins.adoc
@@ -24,10 +24,8 @@ ifndef::openshift-rosa,openshift-rosa-hcp[]
 
 OpenShift API for Data Protection (OADP) is platform neutral. The information that follows relates only to {ibm-power-name} and to {ibm-z-name}.
 
-* {oadp-short} 1.1.7 was tested successfully against {product-title} 4.11 for both {ibm-power-name} and {ibm-z-name}. The sections that follow give testing and support information for {oadp-short} 1.1.7 in terms of backup locations for these systems.
-* {oadp-short} 1.2.3 was tested successfully against {product-title} 4.12, 4.13, 4.14, and 4.15 for both {ibm-power-name} and {ibm-z-name}. The sections that follow give testing and support information for {oadp-short} 1.2.3 in terms of backup locations for these systems.
 * {oadp-short} {oadp-version-1-3} was tested successfully against {product-title} 4.12, 4.13, 4.14, and 4.15 for both {ibm-power-name} and {ibm-z-name}. The sections that follow give testing and support information for {oadp-short} {oadp-version-1-3} in terms of backup locations for these systems.
-* {oadp-short} {oadp-version-1-4} was tested successfully against {product-title} 4.14, 4.15, and 4.16 for both {ibm-power-name} and {ibm-z-name}. The sections that follow give testing and support information for {oadp-short} {oadp-version-1-4} in terms of backup locations for these systems.
+* {oadp-short} {oadp-version-1-4} was tested successfully against {product-title} 4.14, 4.15, 4.16, and 4.17 for both {ibm-power-name} and {ibm-z-name}. The sections that follow give testing and support information for {oadp-short} {oadp-version-1-4} in terms of backup locations for these systems.
 
 
 include::modules/oadp-ibm-power-test-support.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/oadp-rosa/oadp-rosa-backing-up-applications.adoc b/backup_and_restore/application_backup_and_restore/oadp-rosa/oadp-rosa-backing-up-applications.adoc
index cb78cd2fe8b4..16d46bc603f1 100644
--- a/backup_and_restore/application_backup_and_restore/oadp-rosa/oadp-rosa-backing-up-applications.adoc
+++ b/backup_and_restore/application_backup_and_restore/oadp-rosa/oadp-rosa-backing-up-applications.adoc
@@ -36,6 +36,8 @@ include::modules/preparing-aws-credentials-for-oadp.adoc[leveloffset=+1]
 
 include::modules/installing-oadp-rosa-sts.adoc[leveloffset=+1]
 
+include::modules/updating-role-arn-oadp-rosa-sts.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 .Additional resources
 // This xref points to a topic that is not published in the ROSA docs.
diff --git a/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.adoc b/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.adoc
index aea6a9757fdb..9cc9f2c75379 100644
--- a/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.adoc
+++ b/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.adoc
@@ -14,6 +14,14 @@ The release notes for {oadp-first} describe new features and enhancements, depre
 For additional information about {oadp-short}, see link:https://access.redhat.com/articles/5456281[{oadp-first} FAQs]
 ====
 
+include::modules/oadp-1-4-4-release-notes.adoc[leveloffset=+1]
+include::modules/oadp-1-4-3-release-notes.adoc[leveloffset=+1]
+include::modules/oadp-1-4-2-release-notes.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-deleting-backups.adoc#oadp-about-kopia-repo-maintenance_deleting-backups[About Kopia repository maintenance]
+
 include::modules/oadp-1-4-1-release-notes.adoc[leveloffset=+1]
 include::modules/oadp-1-4-0-release-notes.adoc[leveloffset=+1]
 include::modules/oadp-backing-up-dpa-configuration-1-4-0.adoc[leveloffset=+3]
@@ -31,4 +39,4 @@ endif::openshift-rosa-hcp[]
 
 To upgrade from OADP 1.3 to 1.4, no Data Protection Application (DPA) changes are required.
 
-include::modules/oadp-verifying-upgrade-1-4-0.adoc[leveloffset=+2]
\ No newline at end of file
+include::modules/oadp-verifying-upgrade-1-4-0.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/troubleshooting.adoc b/backup_and_restore/application_backup_and_restore/troubleshooting.adoc
index 3e00d83af4ce..3112e19ca3d5 100644
--- a/backup_and_restore/application_backup_and_restore/troubleshooting.adoc
+++ b/backup_and_restore/application_backup_and_restore/troubleshooting.adoc
@@ -145,14 +145,14 @@ include::modules/migration-combining-must-gather.adoc[leveloffset=+2]
 include::modules/oadp-monitoring.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/monitoring/monitoring-overview.adoc#about-openshift-monitoring[Monitoring stack]
+* xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
 
 include::modules/oadp-monitoring-setup.adoc[leveloffset=+2]
 include::modules/oadp-creating-service-monitor.adoc[leveloffset=+2]
 include::modules/oadp-creating-alerting-rule.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[Managing alerts]
+* xref:../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[Managing alerts as an Administrator]
 
 include::modules/oadp-list-of-metrics.adoc[leveloffset=+2]
 include::modules/oadp-viewing-metrics-ui.adoc[leveloffset=+2]
diff --git a/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/about-disaster-recovery.adoc b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/about-disaster-recovery.adoc
index 28136968142d..326c9ecee553 100644
--- a/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/about-disaster-recovery.adoc
+++ b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/about-disaster-recovery.adoc
@@ -17,10 +17,17 @@ state.
 Disaster recovery requires you to have at least one healthy control plane host.
 ====
 
+xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/quorum-restoration.adoc#dr-quorum-restoration[Quorum restoration]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, then xref:../../../backup_and_restore/control_plane_backup_and_restore/replacing-unhealthy-etcd-member.adoc#replacing-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
 xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]::
 This solution handles situations where you want to restore your cluster to
 a previous state, for example, if an administrator deletes something critical.
-This also includes situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. As long as you have taken an etcd backup, you can follow this procedure to restore your cluster to a previous state.
+If you have taken an etcd backup, you can restore your cluster to a previous state.
 +
 If applicable, you might also need to xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-recovering-expired-certs[recover from expired control plane certificates].
 +
@@ -30,11 +37,6 @@ Restoring to a previous cluster state is a destructive and destablizing action t
 
 Prior to performing a restore, see xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-scenario-2-restoring-cluster-state-about_dr-restoring-cluster-state[About restoring cluster state] for more information on the impact to the cluster.
 ====
-+
-[NOTE]
-====
-If you have a majority of your masters still available and have an etcd quorum, then follow the procedure to xref:../../../backup_and_restore/control_plane_backup_and_restore/replacing-unhealthy-etcd-member.adoc#replacing-unhealthy-etcd-member[replace a single unhealthy etcd member].
-====
 
 xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-recovering-expired-certs[Recovering from expired control plane certificates]::
 This solution handles situations where your control plane certificates have
@@ -42,3 +44,9 @@ expired. For example, if you shut down your cluster before the first certificate
 rotation, which occurs 24 hours after installation, your certificates will not
 be rotated and will expire. You can follow this procedure to recover from
 expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+1]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]
\ No newline at end of file
diff --git a/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/quorum-restoration.adoc b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/quorum-restoration.adoc
new file mode 100644
index 000000000000..890d322f85a4
--- /dev/null
+++ b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/quorum-restoration.adoc
@@ -0,0 +1,19 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="dr-quorum-restoration"]
+= Quorum restoration
+include::_attributes/common-attributes.adoc[]
+:context: dr-quorum-restoration
+
+toc::[]
+
+You can use the `quorum-restore.sh` script to restore etcd quorum on clusters that are offline due to quorum loss. When quorum is lost, the {product-title} API becomes read-only. After quorum is restored, the {product-title} API returns to read/write mode.
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_dr-quorum-restoration"]
+== Additional resources
+
+* xref:../../../installing/installing_bare_metal/upi/installing-bare-metal.adoc#installing-bare-metal[Installing a user-provisioned cluster on bare metal]
+* xref:../../../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
\ No newline at end of file
diff --git a/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc
index 3230a8f43a05..60b3e80a1f5d 100644
--- a/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc
+++ b/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc
@@ -6,22 +6,30 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-To restore the cluster to a previous state, you must have previously xref:../../../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backing-up-etcd-data_backup-etcd[backed up etcd data] by creating a snapshot. You will use this snapshot to restore the cluster state.
+To restore the cluster to a previous state, you must have previously backed up the `etcd` data by creating a snapshot. You will use this snapshot to restore the cluster state. For more information, see "Backing up etcd data".
 
 // About restoring to a previous cluster state
 include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+1]
 
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+1]
+
 // Restoring to a previous cluster state
 include::modules/dr-restoring-cluster-state.adoc[leveloffset=+1]
 
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 [id="additional-resources_dr-restoring-cluster-state"]
 == Additional resources
 
+* xref:../../../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backing-up-etcd-data_backup-etcd[Backing up etcd data]
+
 * xref:../../../installing/installing_bare_metal/upi/installing-bare-metal.adoc#installing-bare-metal[Installing a user-provisioned cluster on bare metal]
+
 * xref:../../../networking/accessing-hosts.adoc#accessing-hosts[Creating a bastion host to access {product-title} instances and the control plane nodes with SSH]
+
 * xref:../../../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
 
 include::modules/dr-scenario-cluster-state-issues.adoc[leveloffset=+1]
-
-
diff --git a/backup_and_restore/hibernating-cluster.adoc b/backup_and_restore/hibernating-cluster.adoc
new file mode 100644
index 000000000000..73a84eba3235
--- /dev/null
+++ b/backup_and_restore/hibernating-cluster.adoc
@@ -0,0 +1,41 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="hibernating-cluster"]
+= Hibernating an {product-title} cluster
+include::_attributes/common-attributes.adoc[]
+:context: hibernating-cluster
+
+toc::[]
+
+You can hibernate your {product-title} cluster for up to 90 days.
+
+// About hibernating a cluster
+include::modules/hibernating-cluster-about.adoc[leveloffset=+1]
+
+[id="hibernating-cluster_prerequisites_{context}"]
+== Prerequisites
+
+* Take an xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backing-up-etcd-data_backup-etcd[etcd backup] prior to hibernating the cluster.
++
+[IMPORTANT]
+====
+It is important to take an etcd backup before hibernating so that your cluster can be restored if you encounter any issues when resuming the cluster.
+
+For example, the following conditions can cause the resumed cluster to malfunction:
+
+* etcd data corruption during hibernation
+* Node failure due to hardware
+* Network connectivity issues
+
+If your cluster fails to recover, follow the steps to xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state].
+====
+
+// Hibernating a cluster
+include::modules/hibernating-cluster-hibernate.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[Backing up etcd]
+
+// Resuming a hibernated cluster
+include::modules/hibernating-cluster-resume.adoc[leveloffset=+1]
diff --git a/build_for_portal.py b/build_for_portal.py
index 357bff6388ad..ffbe7d1bf7c4 100644
--- a/build_for_portal.py
+++ b/build_for_portal.py
@@ -455,32 +455,39 @@ def reformat_for_drupal(info):
 
         ensure_directory(images_dir)
 
+        # ADDED 21 Jan 2025: selective processing of images
+        # the set of file names is to be stored in image_files
+        # The initial value includes images defined in attributes (to copy every time)
+        image_files = set()
+
         log.debug("Copying source files for " + book["Name"])
-        copy_files(book, book_src_dir, src_dir, dest_dir, info)
+        copy_files(book, book_src_dir, src_dir, dest_dir, info, image_files)
 
         log.debug("Copying images for " + book["Name"])
-        copy_images(book, src_dir, images_dir, distro)
+        copy_images(book, src_dir, images_dir, distro, image_files)
 
 
 
-def copy_images(node, src_path, dest_dir, distro):
+def copy_images(node, src_path, dest_dir, distro, image_files):
     """
     Copy images over to the destination directory and flatten all image directories into the one top level dir.
-    """
 
-    def dir_callback(dir_node, parent_dir, depth):
-        node_dir = os.path.join(parent_dir, dir_node["Dir"])
-        src = os.path.join(node_dir, "images")
-
-        if os.path.exists(src):
-            src_files = os.listdir(src)
-            for src_file in src_files:
-                shutil.copy(os.path.join(src, src_file), dest_dir)
+    REWORKED 21 Jan 2025: we now assume that there is a single images directory and
+     that all other images subdirectories are simply symlinks into it. So we do not
+     iterate over the tree but simply copy the necessary files from that one images directory
+    """
 
-    iter_tree(node, distro, dir_callback, parent_dir=src_path)
+    images_source_dir = os.path.join(src_path, "images")
+    for image_file_name in image_files:
+        image_file_pathname = os.path.join(images_source_dir,image_file_name)
+        if os.path.exists(image_file_pathname):
+            shutil.copy(image_file_pathname, dest_dir)
+        # if an image file is not found, this is not an error, because it might
+        # have been picked up from a commented-out line. Actual missing images
+        # should be caught by the asciidoctor/asciibinder part of CI
 
 
-def copy_files(node, book_src_dir, src_dir, dest_dir, info):
+def copy_files(node, book_src_dir, src_dir, dest_dir, info, image_files):
     """
     Recursively copy files from the source directory to the destination directory, making sure to scrub the content, add id's where the
     content is referenced elsewhere and fix any links that should be cross references.
@@ -498,7 +505,7 @@ def topic_callback(topic_node, parent_dir, depth):
         dest_file = os.path.join(node_dest_dir, topic_node["File"] + ".adoc")
 
         # Copy the file
-        copy_file(info, book_src_dir, src_file, dest_dir, dest_file)
+        copy_file(info, book_src_dir, src_file, dest_dir, dest_file, image_files)
 
     iter_tree(node, info["distro"], dir_callback, topic_callback)
 
@@ -509,6 +516,7 @@ def copy_file(
     src_file,
     dest_dir,
     dest_file,
+    image_files,
     include_check=True,
     tag=None,
     cwd=None,
@@ -529,7 +537,7 @@ def copy_file(
     # os.mknod(dest_file)
     open(dest_file, "w").close()
     # Scrub/fix the content
-    content = scrub_file(info, book_src_dir, src_file, tag=tag, cwd=cwd)
+    content = scrub_file(info, book_src_dir, src_file, image_files, tag=tag, cwd=cwd)
 
     # Check for any includes
     if include_check:
@@ -584,6 +592,7 @@ def copy_file(
                     include_file,
                     dest_dir,
                     dest_include_file,
+                    image_files,
                     tag=include_tag,
                     cwd=current_dir,
                 )
@@ -612,8 +621,21 @@ def copy_file(
     with open(dest_file, "w") as f:
         f.write(content)
 
+def detect_images(content, image_files):
+    """
+    Detects all image file names referenced in the content, which is a readlines() output
+    Adds the filenames to the image_files set
+    Does NOT control for false positives such as commented out content,
+        because "false negatives" are worse
 
-def scrub_file(info, book_src_dir, src_file, tag=None, cwd=None):
+    TEMPORARY: use both procedural and RE detection and report any misalignment
+    """
+    image_pattern = re.compile(r'image::?([^\s\[]+)\[.*?\]')
+
+    for content_str in content:
+        image_files.update({os.path.basename(f) for f in image_pattern.findall(content_str)})
+
+def scrub_file(info, book_src_dir, src_file, image_files, tag=None, cwd=None):
     """
     Scrubs a file and returns the cleaned file contents.
     """
@@ -657,6 +679,9 @@ def scrub_file(info, book_src_dir, src_file, tag=None, cwd=None):
     with open(src_file, "r") as f:
         src_file_content = f.readlines()
 
+    # detect image references in the content
+    detect_images(src_file_content, image_files)
+
     # Scrub the content
     content = ""
     header_found = content_found = False
diff --git a/modules/telco-update-upgrading-all-the-olm-operators.adoc b/canary.txt
similarity index 100%
rename from modules/telco-update-upgrading-all-the-olm-operators.adoc
rename to canary.txt
diff --git a/cicd/gitops/monitoring-argo-cd-custom-resource-workloads.adoc b/cicd/gitops/monitoring-argo-cd-custom-resource-workloads.adoc
index 0e2f7bf94666..43941ea9b6c0 100644
--- a/cicd/gitops/monitoring-argo-cd-custom-resource-workloads.adoc
+++ b/cicd/gitops/monitoring-argo-cd-custom-resource-workloads.adoc
@@ -19,7 +19,7 @@ You can enable and disable the setting for monitoring Argo CD custom resource wo
 * {gitops-title} is installed in your cluster.
 * The monitoring stack is configured in your cluster in the `openshift-monitoring` project. In addition, the Argo CD instance is in a namespace that you can monitor through Prometheus.
 * The `kube-state-metrics` service is running in your cluster.
-* Optional: If you are enabling monitoring for an Argo CD instance already present in a user-defined project, ensure that the monitoring is xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[enabled for user-defined projects] in your cluster.
+* Optional: If you are enabling monitoring for an Argo CD instance already present in a user-defined project, ensure that the monitoring is xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[enabled for user-defined projects] in your cluster.
 +
 [NOTE]
 ====
@@ -35,4 +35,4 @@ include::modules/gitops-disabling-monitoring-for-argo-cd-custom-resource-workloa
 [role="_additional-resources"]
 [id="additional-resources_monitoring-argo-cd-custom-resource-workloads"]
 == Additional resources
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
diff --git a/cicd/gitops/viewing-argo-cd-logs.adoc b/cicd/gitops/viewing-argo-cd-logs.adoc
index 556d0f576a45..9ddbd18dd0e1 100644
--- a/cicd/gitops/viewing-argo-cd-logs.adoc
+++ b/cicd/gitops/viewing-argo-cd-logs.adoc
@@ -10,7 +10,9 @@ You can view the Argo CD logs with {logging}. {logging-uc} visualizes the logs o
 
 include::modules/gitops-storing-and-retrieving-argo-cd-logs.adoc[leveloffset=+1]
 
+////
 [role="_additional-resources"]
 [id="additional-resources_viewing-argo-cd-logs"]
 == Additional resources
-* xref:../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploy-console_cluster-logging-deploying[Installing {logging} using the web console]
+* xref :../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploy-console_cluster-logging-deploying[Installing {logging} using the web console]
+////
diff --git a/cicd/pipelines/creating-applications-with-cicd-pipelines.adoc b/cicd/pipelines/creating-applications-with-cicd-pipelines.adoc
index 28e698bd313b..817f094f93b6 100644
--- a/cicd/pipelines/creating-applications-with-cicd-pipelines.adoc
+++ b/cicd/pipelines/creating-applications-with-cicd-pipelines.adoc
@@ -68,7 +68,7 @@ include::modules/op-enabling-monitoring-of-event-listeners-for-triggers-for-user
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
 
 include::modules/op-configuring-pull-request-capabilities-in-GitHub-interceptor.adoc[leveloffset=+1]
 
diff --git a/cicd/pipelines/viewing-pipeline-logs-using-the-openshift-logging-operator.adoc b/cicd/pipelines/viewing-pipeline-logs-using-the-openshift-logging-operator.adoc
index 20e9a3daf1a3..a2dd46308370 100644
--- a/cicd/pipelines/viewing-pipeline-logs-using-the-openshift-logging-operator.adoc
+++ b/cicd/pipelines/viewing-pipeline-logs-using-the-openshift-logging-operator.adoc
@@ -23,9 +23,11 @@ Before trying to view pipeline logs in a Kibana dashboard, ensure the following:
 
 include::modules/op-viewing-pipeline-logs-in-kibana.adoc[leveloffset=+1]
 
+////
 [role="_additional-resources"]
 [id="additional-resources_viewing-pipeline-logs-using-the-openshift-logging-operator"]
 == Additional resources
-* xref:../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing OpenShift Logging]
-* xref:../../observability/logging/log_visualization/log-visualization.adoc#log-visualization-resource-logs_log-visualization[Viewing logs for a resource]
-* xref:../../observability/logging/log_visualization/logging-kibana.adoc#logging-kibana[Log visualization with Kibana]
+* xref :../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing OpenShift Logging]
+* xref :../../observability/logging/log_visualization/log-visualization.adoc#log-visualization-resource-logs_log-visualization[Viewing logs for a resource]
+* xref :../../observability/logging/log_visualization/logging-kibana.adoc#logging-kibana[Log visualization with Kibana]
+////
diff --git a/cli_reference/cli_manager/cli-manager-release-notes.adoc b/cli_reference/cli_manager/cli-manager-release-notes.adoc
index 8d9186a42932..6be5fd704ab0 100644
--- a/cli_reference/cli_manager/cli-manager-release-notes.adoc
+++ b/cli_reference/cli_manager/cli-manager-release-notes.adoc
@@ -15,6 +15,20 @@ These release notes track the development of the {cli-manager} for {product-titl
 
 For more information about the {cli-manager}, see xref:../../cli_reference/cli_manager/index.adoc#cli-manager-overview[About the {cli-manager}].
 
+[id="cli-manager-release-notes-0-1-1_{context}"]
+== {cli-manager} 0.1.1 (Technology Preview)
+
+Issued: 12 March 2025
+
+The following advisory is available for the {cli-manager} 0.1.1:
+
+* link:https://access.redhat.com/errata/RHEA-2025:2680[RHEA-2025:2680]
+
+[id="cli-manager-0-1-1-new-features-and-enhancements_{context}"]
+=== New features and enhancements
+
+This release of the CLI Manager updates the Kubernetes version to 1.32.
+
 [id="cli-manager-release-notes-0-1-0_{context}"]
 == {cli-manager} 0.1.0 (Technology Preview)
 
diff --git a/cli_reference/index.adoc b/cli_reference/index.adoc
index 89c6fb66bac6..4c3eeb91909d 100644
--- a/cli_reference/index.adoc
+++ b/cli_reference/index.adoc
@@ -62,7 +62,6 @@ using the terminal. Unlike the web console, it allows the user to work directly
 
 * xref:../cli_reference/osdk/cli-osdk-install.adoc#cli-osdk-install[Operator SDK]: The Operator SDK, a component of the Operator Framework, provides a CLI tool that Operator developers can use to build, test, and deploy an Operator from the terminal. It simplifies the process of building Kubernetes-native applications, which can require deep, application-specific operational knowledge.
 
-
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 * xref:../cli_reference/rosa_cli/rosa-get-started-cli.adoc#rosa-get-started-cli[ROSA CLI (`rosa`)]: Use the `rosa` CLI to create, update, manage, and delete ROSA clusters and resources.
-endif::openshift-rosa[]
\ No newline at end of file
+endif::openshift-rosa,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/cli_reference/openshift_cli/extending-cli-plugins.adoc b/cli_reference/openshift_cli/extending-cli-plugins.adoc
index 8206dec93d30..6349032ce1b3 100644
--- a/cli_reference/openshift_cli/extending-cli-plugins.adoc
+++ b/cli_reference/openshift_cli/extending-cli-plugins.adoc
@@ -8,12 +8,12 @@ toc::[]
 
 You can write and install plugins to build on the default `oc` commands,
 allowing you to perform new and more complex tasks with the
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 OpenShift
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 CLI.
 
 // Writing CLI plugins
diff --git a/cli_reference/openshift_cli/managing-cli-profiles.adoc b/cli_reference/openshift_cli/managing-cli-profiles.adoc
index f35d40ec2c1e..0979f1b6157c 100644
--- a/cli_reference/openshift_cli/managing-cli-profiles.adoc
+++ b/cli_reference/openshift_cli/managing-cli-profiles.adoc
@@ -7,18 +7,18 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 A CLI configuration file allows you to configure different profiles, or contexts, for use with the xref:../../cli_reference/index.adoc#cli-tools-overview[CLI tools overview]. A context consists of
-ifndef::microshift,openshift-dedicated,openshift-rosa[]
+ifndef::microshift,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 xref:../../authentication/understanding-authentication.adoc#understanding-authentication[user authentication]
-endif::microshift,openshift-dedicated,openshift-rosa[]
+endif::microshift,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ifdef::microshift[]
 user authentication
 endif::[]
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 an {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 the {product-title} (ROSA)
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 server information associated with a _nickname_.
 
 include::modules/about-cli-profiles-switch.adoc[leveloffset=+1]
diff --git a/cli_reference/openshift_cli/usage-oc-kubectl.adoc b/cli_reference/openshift_cli/usage-oc-kubectl.adoc
index 0e841348376c..c165ba727b49 100644
--- a/cli_reference/openshift_cli/usage-oc-kubectl.adoc
+++ b/cli_reference/openshift_cli/usage-oc-kubectl.adoc
@@ -5,53 +5,53 @@ include::_attributes/common-attributes.adoc[]
 :context: usage-oc-kubectl
 
 The Kubernetes command-line interface (CLI), `kubectl`, can be used to run commands against a Kubernetes cluster. Because {product-title}
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 (ROSA)
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 is a certified Kubernetes distribution, you can use the supported `kubectl` binaries that ship with
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 , or you can gain extended functionality by using the `oc` binary.
 
 == The oc binary
 
 The `oc` binary offers the same capabilities as the `kubectl` binary, but it extends to natively support additional
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 features, including:
 
 * **Full support for
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 resources**
 +
 Resources such as `DeploymentConfig`, `BuildConfig`, `Route`, `ImageStream`, and `ImageStreamTag` objects are specific to
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 distributions, and build upon standard Kubernetes primitives.
 +
 * **Authentication**
 +
-ifndef::microshift,openshift-rosa,openshift-dedicated[]
+ifndef::microshift,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 The `oc` binary offers a built-in `login` command for authentication and lets you work with projects, which map Kubernetes namespaces to authenticated users.
 Read xref:../../authentication/understanding-authentication.adoc#understanding-authentication[Understanding authentication] for more information.
-endif::microshift,openshift-rosa,openshift-dedicated[]
+endif::microshift,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
 ifdef::microshift[]
 The `oc` binary offers a built-in `login` command for authentication to {product-title}.
@@ -64,19 +64,19 @@ The additional command `oc new-app`, for example, makes it easier to get new app
 [IMPORTANT]
 ====
 If you installed an earlier version of the `oc` binary, you cannot use it to complete all of the commands in
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title} {product-version}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 . If you want the latest features, you must download and install the latest version of the `oc` binary corresponding to your
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 server version.
 ====
 
@@ -109,19 +109,19 @@ image:redcircle-3.png[] `oc` client might provide options and features that migh
 == The kubectl binary
 
 The `kubectl` binary is provided as a means to support existing workflows and scripts for new
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 users coming from a standard Kubernetes environment, or for those who prefer to use the `kubectl` CLI. Existing users of `kubectl` can continue to use the binary to interact with Kubernetes primitives, with no changes required to the
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 cluster.
 
 You can install the supported `kubectl` binary by following the steps to xref:../../cli_reference/openshift_cli/getting-started-cli.adoc#cli-installing-cli_cli-developer-commands[Install the OpenShift CLI]. The `kubectl` binary is included in the archive if you download the binary, or is installed when you install the CLI by using an RPM.
diff --git a/cli_reference/opm/cli-opm-install.adoc b/cli_reference/opm/cli-opm-install.adoc
index ba076db5f5a3..8709cefc1a9a 100644
--- a/cli_reference/opm/cli-opm-install.adoc
+++ b/cli_reference/opm/cli-opm-install.adoc
@@ -8,20 +8,20 @@ toc::[]
 
 include::modules/olm-about-opm.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * See xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging format] for more information about the bundle format.
 * To create a bundle image using the Operator SDK, see
 xref:../../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-working-bundle-images[Working with bundle images].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/olm-installing-opm.adoc[leveloffset=+1]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 [id="opm-addtl-resources"]
 == Additional resources
 
 * See xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs] for `opm` procedures including creating, updating, and pruning catalogs.
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
\ No newline at end of file
diff --git a/cli_reference/opm/cli-opm-ref.adoc b/cli_reference/opm/cli-opm-ref.adoc
index 3d1e38f9887c..4c6bb6e96a9e 100644
--- a/cli_reference/opm/cli-opm-ref.adoc
+++ b/cli_reference/opm/cli-opm-ref.adoc
@@ -38,14 +38,14 @@ include::snippets/deprecated-feature.adoc[]
 include::modules/opm-cli-ref-generate.adoc[leveloffset=+1]
 include::modules/opm-cli-ref-index.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[Managing custom catalogs]
 * xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/opm-cli-ref-init.adoc[leveloffset=+1]
 include::modules/opm-cli-ref-migrate.adoc[leveloffset=+1]
diff --git a/cli_reference/osdk/cli-osdk-install.adoc b/cli_reference/osdk/cli-osdk-install.adoc
index c8d28a2a01f8..41819e53dfe9 100644
--- a/cli_reference/osdk/cli-osdk-install.adoc
+++ b/cli_reference/osdk/cli-osdk-install.adoc
@@ -11,14 +11,14 @@ The Operator SDK provides a command-line interface (CLI) tool that Operator deve
 include::snippets/osdk-deprecation.adoc[]
 
 Operator authors with cluster administrator access to a Kubernetes-based cluster, such as {product-title}, can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 See xref:../../operators/operator_sdk/osdk-about.adoc#osdk-about[Developing Operators] for full documentation on the Operator SDK.
 
 [NOTE]
 ====
 {product-title} {product-version} supports Operator SDK {osdk_ver}.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/osdk-installing-cli-linux-macos.adoc[leveloffset=+1]
 
diff --git a/cli_reference/osdk/cli-osdk-ref.adoc b/cli_reference/osdk/cli-osdk-ref.adoc
index fe567854fa77..2a475f03ac48 100644
--- a/cli_reference/osdk/cli-osdk-ref.adoc
+++ b/cli_reference/osdk/cli-osdk-ref.adoc
@@ -15,9 +15,9 @@ include::snippets/osdk-deprecation.adoc[]
 ----
 $ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
 ----
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 See xref:../../operators/operator_sdk/osdk-about.adoc#osdk-about[Developing Operators] for full documentation on the Operator SDK.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/osdk-cli-ref-bundle.adoc[leveloffset=+1]
 include::modules/osdk-cli-ref-cleanup.adoc[leveloffset=+1]
@@ -26,31 +26,31 @@ include::modules/osdk-cli-ref-create.adoc[leveloffset=+1]
 include::modules/osdk-cli-ref-generate.adoc[leveloffset=+1]
 include::modules/osdk-cli-ref-generate-bundle.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * See xref:../../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-bundle-deploy-olm_osdk-working-bundle-images[Bundling an Operator and deploying with Operator Lifecycle Manager] for a full procedure that includes using the `make bundle` command to call the `generate bundle` subcommand.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/osdk-cli-ref-generate-kustomize.adoc[leveloffset=+2]
 
 include::modules/osdk-cli-ref-init.adoc[leveloffset=+1]
 include::modules/osdk-cli-ref-run.adoc[leveloffset=+1]
 include::modules/osdk-cli-ref-run-bundle.adoc[leveloffset=+2]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * See xref:../../operators/understanding/olm/olm-understanding-operatorgroups.adoc#olm-operatorgroups-membership_olm-understanding-operatorgroups[Operator group membership] for details on possible install modes.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/osdk-cli-ref-run-bundle-upgrade.adoc[leveloffset=+2]
 include::modules/osdk-cli-ref-scorecard.adoc[leveloffset=+1]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [role="_additional-resources"]
 .Additional resources
 
 * See xref:../../operators/operator_sdk/osdk-scorecard.adoc#osdk-scorecard[Validating Operators using the scorecard tool] for details about running the scorecard tool.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/cli_reference/rosa_cli/rosa-cli-permission-examples.adoc b/cli_reference/rosa_cli/rosa-cli-permission-examples.adoc
index 3328d473376c..a5c68e2b81d4 100644
--- a/cli_reference/rosa_cli/rosa-cli-permission-examples.adoc
+++ b/cli_reference/rosa_cli/rosa-cli-permission-examples.adoc
@@ -12,16 +12,19 @@ You can create roles with permissions that adhere to the principal of least priv
 Although the policies and commands presented in this topic will work in conjunction with one another, you might have other restrictions within your AWS environment that make the policies for these commands insufficient for your specific needs. Red{nbsp}Hat provides these examples as a baseline, assuming no other AWS Identity and Access Management (IAM) restrictions are present.
 ====
 
-[NOTE]
-====
-The examples listed cover several of the most common ROSA CLI commands. For more information regarding ROSA CLI commands, see xref:../../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-common-commands_rosa-managing-objects-cli[Common commands and arguments].
-====
+// Omitting from HCP build until BM gets to review
+// [NOTE]
+// ====
+// The examples listed cover several of the most common ROSA CLI commands. For more information regarding ROSA CLI commands, see xref:../../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-common-commands_rosa-managing-objects-cli[Common commands and arguments].
+// ====
 
 For more information about configuring permissions, policies, and roles in the AWS console, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html[AWS Identity and Access Management] in the AWS documentation.
 
 include::modules/rosa-cli-hcp-classic-examples.adoc[leveloffset=+1]
+
 include::modules/rosa-cli-hcp-examples.adoc[leveloffset=+1]
 include::modules/rosa-cli-classic-examples.adoc[leveloffset=+1]
+
 include::modules/rosa-cli-no-permissions-required.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
diff --git a/cli_reference/rosa_cli/rosa-manage-objects-cli.adoc b/cli_reference/rosa_cli/rosa-manage-objects-cli.adoc
index 8a85b8f77233..9ccb901bedcd 100644
--- a/cli_reference/rosa_cli/rosa-manage-objects-cli.adoc
+++ b/cli_reference/rosa_cli/rosa-manage-objects-cli.adoc
@@ -18,19 +18,25 @@ include::modules/rosa-common-commands.adoc[leveloffset=+1]
 include::modules/rosa-parent-commands.adoc[leveloffset=+1]
 include::modules/rosa-create-objects.adoc[leveloffset=+1]
 
+ifdef::openshift-rosa[]
 [role="_additional-resources"]
 == Additional resources
+
 * See xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-aws-instance-types_rosa-service-definition[AWS Instance types] for a list of supported instance types.
 * See xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies_rosa-sts-about-iam-resources[Account-wide IAM role and policy reference] for a list of IAM roles needed for cluster creation.
 * See xref:../../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-understanding-aws-account-association_rosa-sts-creating-a-cluster-with-customizations[Understanding AWS account association] for more information about the OCM role and user role.
 * See xref:../../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc#rosa-security-groups_prerequisites[Additional custom security groups] for information about security group requirements.
+endif::openshift-rosa[]
 
 include::modules/rosa-edit-objects.adoc[leveloffset=+1]
 
 [role="_additional-resources_1"]
 == Additional resources
+ifdef::openshift-rosa[]
 * See xref:../../networking/networking_operators/ingress-operator.adoc#configuring-ingress-controller[Configuring the Ingress Controller] for information regarding editing non-default application routers.
-
+endif::openshift-rosa[]
+//Classic to HCP breakout. Remove ROSA-specific conditionals when networking is added to HCP. 
+ 
 include::modules/rosa-delete-objects.adoc[leveloffset=+1]
 include::modules/rosa-install-uninstall-addon.adoc[leveloffset=+1]
 include::modules/rosa-list-objects.adoc[leveloffset=+1]
diff --git a/cli_reference/tkn_cli/installing-tkn.adoc b/cli_reference/tkn_cli/installing-tkn.adoc
index 2d69b96261e7..afdf468f6e9d 100644
--- a/cli_reference/tkn_cli/installing-tkn.adoc
+++ b/cli_reference/tkn_cli/installing-tkn.adoc
@@ -11,17 +11,22 @@ Use the CLI tool to manage {pipelines-title} from a terminal. The following sect
 ifndef::openshift-rosa,openshift-dedicated[]
 You can also find the URL to the latest binaries from the {product-title} web console by clicking the *?* icon in the upper-right corner and selecting *Command Line Tools*.
 endif::openshift-rosa,openshift-dedicated[]
+
+ifndef::openshift-enterprise,openshift-dedicated[]
+
 :FeatureName: Running {pipelines-title} on ARM hardware
 include::snippets/technology-preview.adoc[]
 
+endif::openshift-enterprise,openshift-dedicated[]
+
 [NOTE]
 ====
 Both the archives and the RPMs contain the following executables:
 
-* tkn
-* tkn-pac
+* `tkn`
+* `tkn-pac`
 ifndef::openshift-rosa,openshift-dedicated[]
-* opc
+* `opc`
 endif::openshift-rosa,openshift-dedicated[]
 ====
 ifndef::openshift-rosa,openshift-dedicated[]
diff --git a/cloud_experts_tutorials/cloud-experts-aws-load-balancer-operator.adoc b/cloud_experts_tutorials/cloud-experts-aws-load-balancer-operator.adoc
index 965411acfdd5..e0416c26f0e2 100644
--- a/cloud_experts_tutorials/cloud-experts-aws-load-balancer-operator.adoc
+++ b/cloud_experts_tutorials/cloud-experts-aws-load-balancer-operator.adoc
@@ -20,10 +20,18 @@ toc::[]
 
 include::snippets/mobb-support-statement.adoc[leveloffset=+1]
 
+ifndef::openshift-rosa-hcp[]
 [TIP]
 ====
 Load Balancers created by the AWS Load Balancer Operator cannot be used for xref:../networking/routes/route-configuration.adoc#route-configuration[OpenShift Routes], and should only be used for individual services or ingress resources that do not need the full layer 7 capabilities of an OpenShift Route.
 ====
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+[TIP]
+====
+Load Balancers created by the AWS Load Balancer Operator cannot be used for link:https://docs.openshift.com/rosa/networking/routes/route-configuration.html[OpenShift Routes], and should only be used for individual services or ingress resources that do not need the full layer 7 capabilities of an OpenShift Route.
+====
+endif::openshift-rosa-hcp[]
 
 The link:https://kubernetes-sigs.github.io/aws-load-balancer-controller/[AWS Load Balancer Controller] manages AWS Elastic Load Balancers for a {product-title} (ROSA) cluster. The controller provisions link:https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html[AWS Application Load Balancers (ALB)] when you create Kubernetes Ingress resources and link:https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html[AWS Network Load Balancers (NLB)] when implementing Kubernetes Service resources with a type of LoadBalancer.
 
@@ -44,7 +52,12 @@ The link:https://github.com/openshift/aws-load-balancer-operator[AWS Load Balanc
 AWS ALBs require a multi-AZ cluster, as well as three public subnets split across three AZs in the same VPC as the cluster. This makes ALBs unsuitable for many PrivateLink clusters. AWS NLBs do not have this restriction.
 ====
 
+ifndef::openshift-rosa-hcp[]
 * xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[A multi-AZ ROSA classic cluster]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.openshift.com/rosa-hcp/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html[A multi-AZ ROSA cluster]
+endif::openshift-rosa-hcp[]
 * BYO VPC cluster
 * AWS CLI
 * OC CLI
diff --git a/cloud_experts_tutorials/cloud-experts-aws-secret-manager.adoc b/cloud_experts_tutorials/cloud-experts-aws-secret-manager.adoc
index 1c2b8ea88c96..d69e8831b938 100644
--- a/cloud_experts_tutorials/cloud-experts-aws-secret-manager.adoc
+++ b/cloud_experts_tutorials/cloud-experts-aws-secret-manager.adoc
@@ -58,7 +58,13 @@ $ oc get authentication.config.openshift.io cluster -o json \
 "https://xxxxx.cloudfront.net/xxxxx"
 ----
 +
-If your output is different, do not proceed. See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Red{nbsp}Hat documentation on creating an STS cluster] before continuing this process.
+If your output is different, do not proceed. 
+ifndef::openshift-rosa-hcp[]
+See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Red{nbsp}Hat documentation on creating an STS cluster] before continuing this process.
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+See link:https://docs.openshift.com/rosa-hcp/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html[Creating ROSA with HCP clusters using the default options] before continuing this process.
+endif::openshift-rosa-hcp[]
 
 . Set the `SecurityContextConstraints` permission to allow the CSI driver to run by running the following command:
 +
diff --git a/cloud_experts_tutorials/cloud-experts-consistent-egress-ip.adoc b/cloud_experts_tutorials/cloud-experts-consistent-egress-ip.adoc
index 990184fdd26c..191cec92169b 100644
--- a/cloud_experts_tutorials/cloud-experts-consistent-egress-ip.adoc
+++ b/cloud_experts_tutorials/cloud-experts-consistent-egress-ip.adoc
@@ -21,7 +21,12 @@ You can assign a consistent IP address for traffic that leaves your cluster such
 
 By default, {product-title} (ROSA) uses the OVN-Kubernetes container network interface (CNI) to assign random IP addresses from a pool. This can make configuring security lockdowns unpredictable or open.
 
+ifndef::openshift-rosa-hcp[]
 See xref:../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[Configuring an egress IP address] for more information.
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+See link:https://docs.openshift.com/rosa/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.html[Configuring an egress IP address] for more information.
+endif::openshift-rosa-hcp[]
 
 .Objectives
 
@@ -30,10 +35,17 @@ See xref:../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ov
 .Prerequisites
 
 * A ROSA cluster deployed with OVN-Kubernetes
+ifndef::openshift-rosa-hcp[]
 * The xref:../cli_reference/openshift_cli/getting-started-cli.adoc#cli-getting-started[OpenShift CLI] (`oc`)
 * The xref:../cli_reference/rosa_cli/rosa-get-started-cli.adoc#rosa-get-started-cli[ROSA CLI] (`rosa`)
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* The link:https://docs.openshift.com/rosa/cli_reference/openshift_cli/getting-started-cli.html[OpenShift CLI] (`oc`)
+* The link:https://docs.openshift.com/rosa/cli_reference/rosa_cli/rosa-get-started-cli.html[ROSA CLI] (`rosa`)
+endif::openshift-rosa-hcp[]
 * link:https://stedolan.github.io/jq/[`jq`]
 
+
 == Setting your environment variables
 
 * Set your environment variables by running the following command:
diff --git a/cloud_experts_tutorials/cloud-experts-custom-dns-resolver.adoc b/cloud_experts_tutorials/cloud-experts-custom-dns-resolver.adoc
index ce4df8e6cfd7..3260ed64c306 100644
--- a/cloud_experts_tutorials/cloud-experts-custom-dns-resolver.adoc
+++ b/cloud_experts_tutorials/cloud-experts-custom-dns-resolver.adoc
@@ -124,8 +124,7 @@ $ aws route53resolver list-resolver-endpoint-ip-addresses \
 
 Use the following procedure to configure your DNS server to forward the necessary private hosted zones to your Amazon Route 53 Inbound Resolver. 
 
-=== ROSA with HCP
-
+ifdef::openshift-rosa-hcp[]
 ROSA with HCP clusters require you to configure DNS forwarding for two private hosted zones:
 
 * `<cluster-name>.hypershift.local`
@@ -151,7 +150,7 @@ zone "<cluster-name>.hypershift.local" { <1>
 <1> Replace `<cluster-name>` with your ROSA HCP cluster name.
 <2> Replace with the IP addresses of your inbound resolver endpoints collected above, ensuring that following each IP address there is a `;`.
 +
-. xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-hcp-sts-creating-a-cluster-quickly[Create your cluster].
+. link:https://docs.openshift.com/rosa/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html[Create your cluster].
 +
 . Once your cluster has begun the creation process, locate the newly created private hosted zone:
 +
@@ -198,16 +197,18 @@ zone "rosa.<domain-prefix>.<unique-ID>.p3.openshiftapps.com" { <1>
 ----
 <1> Replace `<domain-prefix>` with your cluster domain prefix and `<unique-ID>` with your unique ID collected above.
 <2> Replace with the IP addresses of your inbound resolver endpoints collected above, ensuring that following each IP address there is a `;`.
+endif::openshift-rosa-hcp[]
 
-=== ROSA Classic
-
+ifdef::openshift-rosa[]
 ROSA Classic clusters require you to configure DNS forwarding for one private hosted zones:
 
 * `<domain-prefix>.<unique-ID>.p1.openshiftapps.com`
 
 This Amazon Route 53 private hosted zones is created during cluster creation. The `domain-prefix` is a customer-specified value, but the `unique-ID` is randomly generated during cluster creation and cannot be preselected. As such, you must wait for the cluster creation process to begin before configuring forwarding for the `p1.openshiftapps.com` private hosted zone. 
 
+ifndef::openshift-rosa-hcp[]
 . xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[Create your cluster].
+endif::openshift-rosa-hcp[]
 +
 . Once your cluster has begun the creation process, locate the newly created private hosted zone:
 +
@@ -252,4 +253,5 @@ zone "<domain-prefix>.<unique-ID>.p1.openshiftapps.com" { <1>
 };
 ----
 <1> Replace `<domain-prefix>` with your cluster domain prefix and `<unique-ID>` with your unique ID collected above.
-<2> Replace with the IP addresses of your inbound resolver endpoints collected above, ensuring that following each IP address there is a `;`.
\ No newline at end of file
+<2> Replace with the IP addresses of your inbound resolver endpoints collected above, ensuring that following each IP address there is a `;`.
+endif::openshift-rosa[]
\ No newline at end of file
diff --git a/cloud_experts_tutorials/cloud-experts-deploy-api-data-protection.adoc b/cloud_experts_tutorials/cloud-experts-deploy-api-data-protection.adoc
index 1eb232b17cf3..1b3a9fb7b60d 100644
--- a/cloud_experts_tutorials/cloud-experts-deploy-api-data-protection.adoc
+++ b/cloud_experts_tutorials/cloud-experts-deploy-api-data-protection.adoc
@@ -21,7 +21,12 @@ include::snippets/mobb-support-statement.adoc[leveloffset=+1]
 
 .Prerequisites
 
+ifndef::openshift-rosa-hcp[]
 * A xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[ROSA classic cluster]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* A link:https://docs.openshift.com/rosa-hcp/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html[ROSA cluster]
+endif::openshift-rosa-hcp[]
 
 .Environment
 
@@ -160,11 +165,13 @@ $ cat <<EOF > ${SCRATCH}/credentials
 [default]
 role_arn = ${ROLE_ARN}
 web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
+region=<aws_region> # <1>
 EOF
 $ oc -n openshift-adp create secret generic cloud-credentials \
  --from-file=${SCRATCH}/credentials
 ----
-
++
+<1> Replace `<aws_region>` with the AWS region to use for the {sts-first} endpoint.
 . Deploy the OADP Operator:
 +
 [NOTE]
@@ -606,4 +613,4 @@ $ aws iam detach-role-policy --role-name "${ROLE_NAME}" \
 [source,terminal]
 ----
 $ aws iam delete-role --role-name "${ROLE_NAME}"
-----
\ No newline at end of file
+----
diff --git a/cloud_experts_tutorials/cloud-experts-deploying-application/cloud-experts-deploying-application-logging.adoc b/cloud_experts_tutorials/cloud-experts-deploying-application/cloud-experts-deploying-application-logging.adoc
index c1c80a1e4705..1b3cf4b7efbc 100644
--- a/cloud_experts_tutorials/cloud-experts-deploying-application/cloud-experts-deploying-application-logging.adoc
+++ b/cloud_experts_tutorials/cloud-experts-deploying-application/cloud-experts-deploying-application-logging.adoc
@@ -16,15 +16,15 @@ There are various methods to view your logs in {product-rosa} (ROSA). Use the fo
 ====
 ROSA is not preconfigured with a logging solution.
 ====
-
+////
 .Prerequisites
 
-* Set up a logging solution before viewing your logs. See the xref:../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing logging] documentation for more information.
+* Set up a logging solution before viewing your logs. See the xref :../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing logging] documentation for more information.
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/logging/cluster-logging.adoc#cluster-logging[Cluster logging]
-
+* xref :../../observability/logging/cluster-logging.adoc#cluster-logging[Cluster logging]
+////
 == Forwarding logs to CloudWatch
 
 Install the logging add-on service to forward the logs to AWS CloudWatch.
@@ -126,7 +126,7 @@ pod/ostoy-frontend-679cb85695-5cn7x <1>
 pod/ostoy-microservice-86b4c6f559-p594d
 ----
 <1> The pod name is `ostoy-frontend-679cb85695-5cn7x`.
-+  
++
 . Run the following command to see both the `stdout` and `stderr` messages:
 +
 [source,terminal]
@@ -174,4 +174,4 @@ image:cloud-experts-deploying-application-logging-messages.png[]
 
 [role="_additional-resources"]
 .Additional resources
-* link:https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html[What is Amazon CloudWatch]
\ No newline at end of file
+* link:https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html[What is Amazon CloudWatch]
diff --git a/cloud_experts_tutorials/cloud-experts-entra-id-idp.adoc b/cloud_experts_tutorials/cloud-experts-entra-id-idp.adoc
index ed250313f800..bbb5f609ab35 100644
--- a/cloud_experts_tutorials/cloud-experts-entra-id-idp.adoc
+++ b/cloud_experts_tutorials/cloud-experts-entra-id-idp.adoc
@@ -28,12 +28,10 @@ This tutorial guides you to complete the following tasks:
 . Configure the {product-title} cluster to use Entra ID as the identity provider.
 . Grant additional permissions to individual groups.
 
-[id="cloud-experts-entra-id-idp-prerequisites"]
 == Prerequisites
 
 * You created a set of security groups and assigned users by following link:https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/how-to-manage-groups[the Microsoft documentation].
 
-[id="cloud-experts-entra-id-idp-register-application"]
 == Registering a new application in Entra ID for authentication
 
 To register your application in Entra ID, first create the OAuth callback URL, then register your application.
@@ -50,7 +48,7 @@ Remember to save this callback URL; it will be required later in the process.
 [source,terminal]
 ----
 $ domain=$(rosa describe cluster -c <cluster_name> | grep "DNS" | grep -oE '\S+.openshiftapps.com')
-$ echo "OAuth callback URL: https://oauth-openshift.apps.$domain/oauth2callback/AAD"
+echo "OAuth callback URL: https://oauth.${domain}/oauth2callback/AAD"
 ----
 +
 The "AAD" directory at the end of the OAuth callback URL must match the OAuth identity provider name that you will set up later in this process.
@@ -82,15 +80,12 @@ image:azure-portal_add-a-client-secret-page.png[Azure Portal - Add a Client Secr
 +
 image:azure-portal_copy-client-secret-page.png[Azure Portal - Copy Client Secret page]
 
-[id="rosa-mobb-entra-id-configure-claims"]
 == Configuring the application registration in Entra ID to include optional and group claims
 
 So that {product-title} has enough information to create the user's account, you must configure Entra ID to give two optional claims: `email` and `preferred_username`. For more information about optional claims in Entra ID, see link:https://learn.microsoft.com/en-us/azure/active-directory/develop/optional-claims[the Microsoft documentation].
 
 In addition to individual user authentication, {product-title} provides group claim functionality. This functionality allows an OpenID Connect (OIDC) identity provider, such as Entra ID, to offer a user's group membership for use within {product-title}.
 
-[discrete]
-[id="rosa-mobb-entra-id-configure-optional-claims"]
 === Configuring optional claims
 
 You can configure the optional claims in Entra ID.
@@ -115,8 +110,6 @@ image:azure-portal_add-optional-preferred_username-claims-page.png[Azure Portal
 +
 image:azure-portal_add-optional-claims-graph-permissions-prompt.png[Azure Portal - Add Optional Claims - Graph Permissions Prompt]
 
-[discrete]
-[id="rosa-mobb-entra-id-configure-group-claims"]
 === Configuring group claims (optional)
 
 Configure Entra ID to offer a groups claim.
@@ -135,7 +128,6 @@ In this example, the group claim includes all of the security groups that a user
 +
 image:azure-portal_edit-group-claims-page.png[Azure Portal - Edit Groups Claim Page]
 
-[id="cloud-experts-entra-id-idp-configure-cluster"]
 == Configuring the {product-title} cluster to use Entra ID as the identity provider
 
 You must configure {product-title} to use Entra ID as its identity provider.
@@ -201,15 +193,12 @@ $ rosa create idp \
 
 After a few minutes, the cluster authentication Operator reconciles your changes, and you can log in to the cluster by using Entra ID.
 
-[id="rosa-mobb-azure-oidc-grant-permissions"]
 == Granting additional permissions to individual users and groups
 
 When your first log in, you might notice that you have very limited permissions. By default, {product-title} only grants you the ability to create new projects, or namespaces, in the cluster. Other projects are restricted from view.
 
 You must grant these additional abilities to individual users and groups.
 
-[discrete]
-[id="rosa-mobb-azure-oidc-grant-permissions-users"]
 === Granting additional permissions to individual users
 
 {product-title} includes a significant number of preconfigured roles, including the `cluster-admin` role that grants full access and control over the cluster.
@@ -228,8 +217,6 @@ $ rosa grant user cluster-admin \
 <1> Provide the Entra ID username that you want to have cluster admin permissions.
 --
 
-[discrete]
-[id="cloud-experts-entra-id-idp-additional-permissions-groups"]
 === Granting additional permissions to individual groups
 
 If you opted to enable group claims, the cluster OAuth provider automatically creates or updates the user's group memberships by using the group ID. The cluster OAuth provider does not automatically create `RoleBindings` and `ClusterRoleBindings` for the groups that are created; you are responsible for creating those bindings by using your own processes.
@@ -252,7 +239,6 @@ $ oc create clusterrolebinding cluster-admin-group \
 +
 Now, any user in the specified group automatically receives `cluster-admin` access.
 
-[id="cloud-experts-entra-id-idp-additional-resources"]
 [role="_additional-resources"]
 == Additional resources
 
diff --git a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-what-is-rosa.adoc b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-what-is-rosa.adoc
index fafa09dc9969..c58e0dd06505 100644
--- a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-what-is-rosa.adoc
+++ b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-what-is-rosa.adoc
@@ -60,7 +60,13 @@ For a complete list of supported instances for worker nodes see xref:../../rosa_
 Autoscaling allows you to automatically adjust the size of the cluster based on the current workload. See xref:../../rosa_cluster_admin/rosa_nodes/rosa-nodes-about-autoscaling-nodes.adoc#rosa-nodes-about-autoscaling-nodes[About autoscaling nodes on a cluster] for more details.
 
 === Maximum number of worker nodes
-The maximum number of worker nodes is 180 worker nodes for each ROSA cluster. See xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability] for more details on node counts.
+The maximum number of worker nodes in ROSA clusters versions 4.14.14 and later is 249. For earlier versions, the limit is 180 nodes.
+ifdef::temp-ifdef[]
+See xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability] for more details on node counts.
+endif::[]
+ifdef::temp-ifdef[]
+See xref:../../rosa_planning/rosa-hcp-limits-scalability.adoc#rosa-hcp-limits-scalability[limits and scalability] for more details on node counts.
+endif::[]
 
 A list of the account-wide and per-cluster roles is provided in the xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[ROSA documentation].
 
@@ -201,8 +207,13 @@ Ingress can be limited to a PrivateLink for Red{nbsp}Hat SREs and a VPN for cust
 ** xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-process-security[Understanding Process and Security]
 ** xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-understand-availability.adoc#rosa-policy-understand-availability[About Availability]
 ** xref:../../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle[Updates Lifecycle]
-** xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and Scalability]
+ifdef::temp-ifdef[]
+** xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability]
+endif::[]
+ifdef::temp-ifdef[]
+** xref:../../rosa_planning/rosa-hcp-limits-scalability.adoc#rosa-hcp-limits-scalability[limits and scalability]
+endif::[]
 ** link:https://red.ht/rosa-roadmap[ROSA roadmap]
 * link:https://learn.openshift.com[Learn about OpenShift]
 * {cluster-manager-url}
-* link:https://support.redhat.com[Red{nbsp}Hat Support]
+* link:https://support.redhat.com[Red{nbsp}Hat Support]
\ No newline at end of file
diff --git a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-rosa-sts-explained.adoc b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-rosa-sts-explained.adoc
index 10c83c203915..a67ec4224208 100644
--- a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-rosa-sts-explained.adoc
+++ b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-rosa-sts-explained.adoc
@@ -66,16 +66,16 @@ STS roles and policies must be created for each ROSA cluster. To make this easie
 * *OpenID Connect (OIDC)* - This provides a mechanism for cluster Operators to authenticate with AWS, assume the cluster roles through a trust policy, and obtain temporary credentials from STS to make the required API calls.
 * *Roles and policies* - The roles and policies are one of the main differences between ROSA with STS and ROSA with IAM Users. For ROSA with STS, the roles and policies used by ROSA are broken into account-wide roles and policies and Operator roles and policies.
 +
-The policies determine the allowed actions for each of the roles. See xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS] for more details about the individual roles and policies.
+The policies determine the allowed actions for each of the roles. See xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources] for more details about the individual roles and policies.
 +
-** The account-wide roles are:
+** The following account-wide roles are required:
 +
 *** ManagedOpenShift-Installer-Role
 *** ManagedOpenShift-ControlPlane-Role
 *** ManagedOpenShift-Worker-Role
 *** ManagedOpenShift-Support-Role
 +
-** The account-wide policies are:
+** The following account-wide policies are required:
 +
 *** ManagedOpenShift-Installer-Role-Policy
 *** ManagedOpenShift-ControlPlane-Role-Policy
diff --git a/cloud_experts_tutorials/cloud-experts-rosa-hcp-activation-and-account-linking-tutorial.adoc b/cloud_experts_tutorials/cloud-experts-rosa-hcp-activation-and-account-linking-tutorial.adoc
index ee13703379a5..179c5d861324 100644
--- a/cloud_experts_tutorials/cloud-experts-rosa-hcp-activation-and-account-linking-tutorial.adoc
+++ b/cloud_experts_tutorials/cloud-experts-rosa-hcp-activation-and-account-linking-tutorial.adoc
@@ -24,7 +24,7 @@ If you have received a private offer for the product, make sure to proceed accor
 
 == Prerequisites
 
-* Make sure to log in to the Red{nbsp}Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
+* Log in to the Red{nbsp}Hat account that you want to associate with the AWS account that will activate the {hcp-title} product subscription.
 * The AWS account used for service billing can only be associated with a single Red{nbsp}Hat account. Typically an AWS payer account is the one that is used to subscribe to ROSA and used for account linking and billing.
 * All team members belonging to the same Red{nbsp}Hat organization can use the linked AWS account for service billing while creating {hcp-title} clusters.
 
@@ -87,7 +87,7 @@ Your AWS account must be linked to a single Red{nbsp}Hat organization.
 image::rosa-login-rh-account-7.png[]
 +
 * You can also register for a new Red{nbsp}Hat account or reset your password on this page.
-* Make sure to log in to the Red{nbsp}Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
+* Log in to the Red{nbsp}Hat account that you want to associate with the AWS account that has activated the {hcp-title} product subscription.
 * The AWS account used for service billing can only be associated with a single Red{nbsp}Hat account. Typically an AWS payer account is the one that is used to subscribe to ROSA and used for account linking and billing.
 * All team members belonging to the same Red{nbsp}Hat organization can use the linked AWS account for service billing while creating {hcp-title} clusters.
 
diff --git a/cloud_experts_tutorials/index.adoc b/cloud_experts_tutorials/index.adoc
index 0e79a967853b..b46bb742de27 100644
--- a/cloud_experts_tutorials/index.adoc
+++ b/cloud_experts_tutorials/index.adoc
@@ -4,6 +4,9 @@
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: tutorials-overview
 
-Step-by-step tutorials from Red{nbsp}Hat experts to help you get the most out of your Managed OpenShift cluster.
+Use the step-by-step tutorials from Red{nbsp}Hat experts to get the most out of your Managed OpenShift cluster.
 
-In an effort to make this Cloud Expert tutorial content available quickly, it may not yet be tested on every supported configuration.
+[IMPORTANT]
+====
+This content is authored by Red Hat experts but has not yet been tested on every supported configuration.
+====
diff --git a/cloud_experts_tutorials/rosa-mobb-verify-permissions-sts-deployment.adoc b/cloud_experts_tutorials/rosa-mobb-verify-permissions-sts-deployment.adoc
index 80d543002c0f..adb1292853c6 100644
--- a/cloud_experts_tutorials/rosa-mobb-verify-permissions-sts-deployment.adoc
+++ b/cloud_experts_tutorials/rosa-mobb-verify-permissions-sts-deployment.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="rosa-mobb-verify-permissions-sts-deployment"]
-= Tutorial: Verifying Permissions for a ROSA STS Deployment
+= Tutorial: Verifying permissions for a ROSA STS deployment
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: rosa-mobb-verify-permissions-sts-deployment
 
@@ -16,16 +16,27 @@ toc::[]
 // ---
 
 To proceed with the deployment of a ROSA cluster, an account must support the required roles and permissions.
-AWS Service Control Policies (SCPs) cannot block the API calls made by the installer or operator roles.
+AWS Service Control Policies (SCPs) cannot block the API calls made by the installer or Operator roles.
 
+Details about the IAM resources required for an STS-enabled installation of ROSA can be found here: xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources]
+ifndef::openshift-rosa-hcp[]
 Details about the IAM resources required for an STS-enabled installation of ROSA can be found here: xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+Details about the IAM resources required for an STS-enabled installation of ROSA can be found here: link:https://docs.openshift.com/rosa/rosa_architecture/rosa-sts-about-iam-resources.html[About IAM resources for ROSA clusters]
+endif::openshift-rosa-hcp[]
 
 This guide is validated for ROSA v4.11.X.
 
 == Prerequisites
 
 * link:https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html[AWS CLI]
+ifndef::openshift-rosa-hcp[]
 * xref:../cli_reference/rosa_cli/rosa-get-started-cli.adoc#rosa-get-started-cli[ROSA CLI] v1.2.6
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.openshift.com/rosa/cli_reference/rosa_cli/rosa-get-started-cli.html[ROSA CLI] v1.2.6
+endif::openshift-rosa-hcp[]
 * link:https://stedolan.github.io/jq/[jq CLI]
 * link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html[AWS role with required permissions]
 
diff --git a/contributing_to_docs/doc_guidelines.adoc b/contributing_to_docs/doc_guidelines.adoc
index 82b865566b5d..b2c5a2698f48 100644
--- a/contributing_to_docs/doc_guidelines.adoc
+++ b/contributing_to_docs/doc_guidelines.adoc
@@ -490,19 +490,31 @@ A _procedure_ contains the steps that users follow to complete a single process
 
 Use a gerund in the procedure title, such as "Creating".
 
+[IMPORTANT]
+====
+Modules cannot contain xrefs. If you _must_ use a link in your module, use the `link` attribute type and treat it as an external reference.
+
+Use version attributes for the maintainability of xrefs and links whenever you can.
+====
+
 For more information about writing procedures, see the
 link:https://redhat-documentation.github.io/modular-docs/#con-creating-procedure-modules_writing-mod-docs[_Red Hat modular docs reference guide_] and the link:https://raw.githubusercontent.com/redhat-documentation/modular-docs/master/modular-docs-manual/files/TEMPLATE_PROCEDURE_doing-one-procedure.adoc[procedure template].
 
 [NOTE]
 ====
-When needed, use `.Prerequisites`, `.Next steps`, or `.Additional resources` syntax to suppress TOC formatting within a module. Do not use `==` syntax for these headings in modules. Because you cannot use the xrefs in modules, if you need to include a link under one of these headings, place the entire subsection in the assembly instead.
+When needed, use the _<.section_title>_ syntax suppress TOC formatting within a module, for example, `.Prerequisites`, `.Procedure`, `.Next steps`, or `.Additional resources`. Do not use the heading-level syntax, such as `==`, for these headings in modules.
 ====
 
 [id="writing-text-snippets"]
 == Writing text snippets
 A _text snippet_ is an optional component that lets you reuse content in multiple modules and assemblies. Text snippets are not a substitute for modules but instead are a more granular form of content reuse. While a module is content that a reader can understand on its own (like an article) or as part of a larger body of work (like an assembly), a text snippet is not self-contained and is not intended to be published or cross referenced on its own.
 
-In the context of modules and assemblies, text snippets do not include headings or anchor IDs. Text snippets also cannot contain xrefs. This type of component is text only. Examples include the following:
+[IMPORTANT]
+====
+Like modules, text snippets cannot contain xrefs. If you _must_ use a link in your snippet, use the `link` attribute type and treat it as an external reference. It is recommended to use version attributes for maintainability of the link.
+====
+
+In the context of modules and assemblies, text snippets do not include headings or anchor IDs. Examples include the following:
 
 * Admonitions that appear in multiple modules.
 * An introductory paragraph that appears in multiple assemblies.
@@ -603,22 +615,22 @@ possible values for `{product-title}` and `{product-version}`, depending on the
 |`openshift-origin`
 |OKD
 a|* 3.6, 3.7, 3.9, 3.10, 3.11
-* 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
+* 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, 4.18
 * 4 for the `latest/` build from the `main` branch
 
 |`openshift-enterprise`
 |OpenShift Container Platform
 a|* 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.9, 3.10, 3.11
-* 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, 4.18
+* 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, 4.18, 4.19
 
 |`openshift-dedicated`
 |OpenShift Dedicated
-a|* No value set for the latest `dedicated/` build from the `enterprise-4.17` branch
+a|* No value set for the latest `dedicated/` build from the `enterprise-4.18` branch
 * 3 for the `dedicated/3` build from the `enterprise-3.11` branch
 
 |`openshift-rosa`
 |Red Hat OpenShift Service on AWS
-|No value set for the `rosa/` build from the `enterprise-4.17` branch
+|No value set for the `rosa/` build from the `enterprise-4.18` branch
 
 |`openshift-online`
 |OpenShift Online
@@ -741,7 +753,32 @@ If you are upgrading a cluster in a restricted network, install the `oc` version
 
 Note that you must set and unset each temporary attribute that you introduce to an assembly. Use the temporary attributes in the applicable ifdef and ifndef statements to vary text between the assemblies. The preceeding example uses `restricted` as the temporary attribute to display an additional paragraph for the assembly with the `updating-restricted-network-cluster` context attribute.
 
-== Node names
+[id="do-not-use-sensitive-information-in-docs"]
+== Ensuring that you do not include sensitive information
+
+If you use sample code that you get from Engineering or QE team members, review the code for potentially sensitive data from customer or test environments.
+Do not include test or customer data in any field or comment in the YAML.
+
+Examples of sensitive information from customer or test environments can include:
+
+Node names::
+For example, internal company or customer server names.
+See <<node-names>> for more information.
+
+IP addresses::
+Replace all public IP addresses with generic IP addresses.
+See <<ip-addresses>> for more information.
+
+MAC addresses::
+Ensure that any MAC addresses that you include in source example are generic and do not identify real machines.
+See <<mac-addresses>> for more information.
+
+Sensitive Red Hat, customer, or partner information::
+Remove or rework text or comments that inadvertently describe sensitive Red Hat, customer, or partner data, or names new or un-released features or products.
+See <<sensitive-or-unreleased-information>> for more information.
+
+[id="node-names"]
+=== Node names
 
 Do not use internal company server names in commands or example output. Provide generic OpenShift Container Platform node name examples that are not provider-specific, unless required. Where possible, use the example.com domain name when providing fully qualified domain names (FQDNs).
 
@@ -801,7 +838,8 @@ control-plane-3.example.com   Ready    master   41m   v1.19.0+9f84db3
 Some provider-formatted hostnames include IPv4 addresses. An OpenShift Container Platform node name typically reflects the hostname of a node. If node names in your output need to be provider-specific and require this format, use private IPv4 addresses. For example, you could use `ip-10-0-48-9.example.com` as a node name that includes a private IPv4 address.
 ====
 
-== IP addresses
+[id="ip-addresses"]
+=== IP addresses
 
 You may include IPv4 addresses from test clusters in examples in the documentation, provided that they are private. Private IPv4 addresses fall into one of the following ranges:
 
@@ -820,6 +858,39 @@ Replace all public IP addresses with an address from the following blocks. These
 There might be advanced networking examples that require specific IP addresses, or cloud provider-specific examples that require a public IP address. Contact a subject matter expert if you need assistance with replacing IP addresses.
 ====
 
+[id="mac-addresses"]
+=== MAC addresses
+
+Ensure that any MAC addresses that you include in source example are generic and do not identify real hosts.
+
+[id="sensitive-or-unreleased-information"]
+=== Sensitive or customer-identifying data
+
+Ensure that you do not include text or comments that inadvertently describes sensitive Red Hat, customer, or partner data.
+
+Possible sources of customer-identifying data includes:
+
+* Unreleased product names or project code words
+* Customer and partner names
+* Code comments
+* Example YAML CR snippets
+* Sample application code
+* Logs
+* Configuration files
+* Command output
+* Network or architecture diagrams
+* Network packet captures
+* Package version numbers
+* Heap dumps
+
+Where possible, replace specific details with generic examples.
+
+[NOTE]
+====
+There might be advanced examples that require specific details, or multipart examples that require specific names to make sense.
+If you have any doubt about what you are documenting, contact a subject matter expert or team lead.
+====
+
 [id="links-conditionals-assemblies"]
 == Links, hyperlinks, and cross references
 Links can be used to cross-reference internal assemblies or send readers to external information resources for further reading.
@@ -827,7 +898,7 @@ Links can be used to cross-reference internal assemblies or send readers to exte
 In OpenShift Container Platform docs:
 
 * All links to internal content is created by using an `xref`, and each `xref` **must have an anchor ID**.
-* Only use `xref` in assemblies, not in modules.
+* Only use `xref` in assemblies, not in modules or snippets.
 * All links to external websites are created by using the `link` attribute.
 * Links between different distributions, or _distros_, such as from ROSA to OpenShift Container Platform, are external links and not cross-references. These external links use `link` instead of `xref` and must be in distro-specific files or a conditionalized state to apply to the relevant distros.
 
diff --git a/contributing_to_docs/term_glossary.adoc b/contributing_to_docs/term_glossary.adoc
index 6c994df69ebd..3ae952157959 100644
--- a/contributing_to_docs/term_glossary.adoc
+++ b/contributing_to_docs/term_glossary.adoc
@@ -328,6 +328,17 @@ While "GroupVersionKind" does appear in the API guide, typically there should no
 
 == H
 
+''''
+=== hosted control planes
+
+Usage: hosted control planes or Hosted control planes
+
+When referencing hosted control planes for the first time, write as "hosted control planes for {product-title}". Capitalize the “h” in “hosted control planes” only when “hosted” is the first word in a title, heading, or sentence. Use lowercase “h” for subsequent references of hosted control planes.
+
+Avoid referencing hosted control planes as HyperShift in any customer-facing content as HyperShift is the internal name.
+
+In the documentation for hosted control planes with ROSA, the writers are allowed to use “HCP with ROSA”, per branding.
+
 == I
 
 ''''
diff --git a/disconnected/about.adoc b/disconnected/about.adoc
index 29ba822c3e30..733428a8892a 100644
--- a/disconnected/about.adoc
+++ b/disconnected/about.adoc
@@ -54,7 +54,7 @@ However, some options provide a simpler and more convenient user experience for
 
 Unless your organizational needs require you to choose another option, use the following methods for mirroring images, installing your cluster, and updating your cluster:
 
-* Mirror your images using the xref:../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[oc-mirror plugin].
+* Mirror your images using the xref:../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[oc-mirror plugin v2].
 
 * Install your cluster using the xref:../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Agent-based Installer].
 
diff --git a/disconnected/mirroring/about-installing-oc-mirror-v2.adoc b/disconnected/mirroring/about-installing-oc-mirror-v2.adoc
index b2635378502a..414bb5f559cf 100644
--- a/disconnected/mirroring/about-installing-oc-mirror-v2.adoc
+++ b/disconnected/mirroring/about-installing-oc-mirror-v2.adoc
@@ -8,10 +8,7 @@ toc::[]
 
 You can run your cluster in a disconnected environment if you install the cluster from a mirrored set of {product-title} container images in a private registry. This registry must be running whenever your cluster is running.
 
-Just as you can use the `oc-mirror` OpenShift CLI (`oc`) plugin, you can also use oc-mirror plugin v2 to mirror images to a mirror registry in your fully or partially disconnected environments. To download the required images from the official Red{nbsp}Hat registries, you must run oc-mirror plugin v2 from a system with internet connectivity.
-
-:FeatureName: oc-mirror plugin v2
-include::snippets/technology-preview.adoc[]
+You can use oc-mirror plugin v2 to mirror images to a mirror registry in your fully or partially disconnected environments. To download the required images from the official Red{nbsp}Hat registries, you must run oc-mirror plugin v2 from a system with internet connectivity.
 
 // About oc-mirror plugin v2
 include::modules/oc-mirror-v2-about.adoc[leveloffset=+1]
@@ -63,7 +60,7 @@ include::modules/oc-mirror-workflows-fully-disconnected-v2.adoc[leveloffset=+2]
 include::modules/oc-mirror-mirror-to-disk-v2.adoc[leveloffset=+2]
 include::modules/oc-mirror-disk-to-mirror-v2.adoc[leveloffset=+2]
 
-// About custom resources generated by v2
+// About custom resources generated by oc-mirror plugin v2
 include::modules/oc-mirror-IDMS-ITMS-about.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -73,15 +70,28 @@ include::modules/oc-mirror-IDMS-ITMS-about.adoc[leveloffset=+1]
 
 * xref:../../rest_api/config_apis/imagetagmirrorset-config-openshift-io-v1.adoc#imagetagmirrorset-config-openshift-io-v1[ImageTagMirrorSet]
 
+* xref:../../extensions/catalogs/managing-catalogs.adoc#olmv1-about-catalogs_managing-catalogs[About catalogs in {olmv1}]
+
 // Configuring your cluster to use the resources generated by oc-mirror
 include::modules/oc-mirror-updating-cluster-manifests-v2.adoc[leveloffset=+2]
 
-Once your cluster is configured to use the resources generated by oc-mirror plugin v2, see xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#next-steps_about-installing-oc-mirror-v2[Next Steps] for information about tasks that you can perform using your mirrored images.
+After your cluster is configured to use the resources generated by oc-mirror plugin v2, see xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#next-steps_about-installing-oc-mirror-v2[Next Steps] for information about tasks that you can perform using your mirrored images.
 
-//Delete Feature
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../extensions/catalogs/disconnected-catalogs.adoc#disconnected-catalogs[Disconnected environment support in {olmv1}]
+
+// Delete Feature
 // workflows of delete feature
 include::modules/oc-mirror-workflows-delete-v2.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-v2-procedure-garbage-collector_about-installing-oc-mirror-v2[Resolving storage cleanup issues in the distribution registry]
+
+include::modules/oc-mirror-v2-procedure-garbage-collector.adoc[leveloffset=+2]
+
 // procedure for delete feature
 include::modules/oc-mirror-procedure-delete-v2.adoc[leveloffset=+2]
 
@@ -94,24 +104,32 @@ include::modules/oc-mirror-dry-run-v2.adoc[leveloffset=+2]
 // Troubleshooting
 include::modules/oc-mirror-troubleshooting-v2.adoc[leveloffset=+1]
 
-//oc-mirror-enclave-support-about
+// oc-mirror-enclave-support-about
 include::modules//oc-mirror-enclave-support-about.adoc[leveloffset=+1]
 
 // How to mirror to an Enclave
 include::modules/oc-mirror-enclave-support.adoc[leveloffset=+2]
 
+// Proxy support
+include::modules/oc-mirror-proxy-support.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 .Additional resources
 * xref:../../disconnected/updating/disconnected-update-osus.adoc#updating-disconnected-cluster-osus[Updating a cluster in a disconnected environment using the OpenShift Update Service]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-v2-procedure-garbage-collector_about-installing-oc-mirror-v2[Resolving storage cleanup issues in the distribution registry]
 
-//operator catalog filtering
+// Operator catalog filtering
 include::modules/oc-mirror-operator-catalog-filtering.adoc[leveloffset=+1]
 
-//Image set configuration parameters
+// Image set configuration parameters
 include::modules/oc-mirror-imageset-config-parameters-v2.adoc[leveloffset=+1]
 
 // Command reference for oc-mirror v2
 include::modules/oc-mirror-command-reference-v2.adoc[leveloffset=+1]
+include::modules/oc-mirror-command-reference-v2-delete.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
 * xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-updating-cluster-manifests-v2_about-installing-oc-mirror-v2[Configuring your cluster to use the resources generated by oc-mirror]
 
 [id="next-steps_{context}"]
diff --git a/disconnected/mirroring/index.adoc b/disconnected/mirroring/index.adoc
index fc0194dd28fc..f32f8456f2d7 100644
--- a/disconnected/mirroring/index.adoc
+++ b/disconnected/mirroring/index.adoc
@@ -19,4 +19,4 @@ If you already have a container image registry, such as Red Hat Quay, you can us
 You can use one of the following procedures to mirror your {product-title} image repository to your mirror registry:
 
 * xref:../../disconnected/mirroring/installing-mirroring-installation-images.adoc#installing-mirroring-installation-images[Mirroring images for a disconnected installation by using the oc adm command]
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]
diff --git a/disconnected/mirroring/installing-mirroring-disconnected.adoc b/disconnected/mirroring/installing-mirroring-disconnected.adoc
index ec2d25c043fe..df604a25a22d 100644
--- a/disconnected/mirroring/installing-mirroring-disconnected.adoc
+++ b/disconnected/mirroring/installing-mirroring-disconnected.adoc
@@ -10,6 +10,11 @@ Running your cluster in a restricted network without direct internet connectivit
 
 You can use the oc-mirror OpenShift CLI (`oc`) plugin to mirror images to a mirror registry in your fully or partially disconnected environments. You must run oc-mirror from a system with internet connectivity in order to download the required images from the official Red Hat registries.
 
+[IMPORTANT]
+====
+The oc-mirror plugin v1 is now deprecated. Transition to the xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#installation-oc-mirror-v2-about_about-installing-oc-mirror-v2[oc-mirror plugin v2] for continued support and improvements.
+====
+
 // About the oc-mirror plugin
 include::modules/oc-mirror-about.adoc[leveloffset=+1]
 
@@ -96,6 +101,11 @@ include::modules/oc-mirror-disk-to-mirror.adoc[leveloffset=+3]
 // Configuring your cluster to use the resources generated by oc-mirror
 include::modules/oc-mirror-updating-cluster-manifests.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../extensions/catalogs/managing-catalogs.adoc#olmv1-adding-a-catalog-to-a-cluster_managing-catalogs[Adding a catalog to a cluster] in "Extensions"
+
 // About updating your mirror registry content
 include::modules/oc-mirror-updating-registry-about.adoc[leveloffset=+1]
 
diff --git a/disconnected/mirroring/oc-mirror-migration-v1-to-v2.adoc b/disconnected/mirroring/oc-mirror-migration-v1-to-v2.adoc
new file mode 100644
index 000000000000..c0c5e9b6e7fd
--- /dev/null
+++ b/disconnected/mirroring/oc-mirror-migration-v1-to-v2.adoc
@@ -0,0 +1,29 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="oc-mirror-migration-v1-to-v2"]
+= Migrating from oc-mirror plugin v1 to v2
+include::_attributes/common-attributes.adoc[]
+:context: oc-mirror-migration-v1-to-v2
+
+toc::[]
+
+The oc-mirror v2 plugin introduces major changes to image mirroring workflows. This guide provides step-by-step instructions for migration while ensuring compatibility with oc-mirror plugin v2.
+
+[IMPORTANT]
+====
+You must manually update the configurations by modifying the API version and removing deprecated fields. For more information, see "Changes from oc-mirror plugin v1 to v2".
+====
+
+// Differences between oc-mirror plugin v1 and v2
+include::modules/oc-mirror-migration-differences.adoc[leveloffset=+1]
+
+// Migrating from oc-mirror plugin v1 to oc-mirror plugin v2
+include::modules/oc-mirror-migration-process.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2#oc-mirror-workflows-partially-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a partially disconnected environment]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2#oc-mirror-workflows-fully-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a fully disconnected environment]
+* For details regarding configuration changes, see xref:../../disconnected/mirroring/oc-mirror-migration-v1-to-v2#oc-mirror-migration-differences_oc-mirror-migration-v1-to-v2[Changes from oc-mirror plugin v1 to v2].
+* For more information about deleting images, see xref:../../disconnected/mirroring/about-installing-oc-mirror-v2#oc-mirror-procedure-delete-v2_about-installing-oc-mirror-v2[Deletion of images from your disconnected environment].
diff --git a/disconnected/updating/mirroring-image-repository.adoc b/disconnected/updating/mirroring-image-repository.adoc
index a5a4167ba5ae..c9dd5c25c97d 100644
--- a/disconnected/updating/mirroring-image-repository.adoc
+++ b/disconnected/updating/mirroring-image-repository.adoc
@@ -52,7 +52,7 @@ Compared to using the `oc adm release mirror` command, the oc-mirror plugin has
 
 You can use the oc-mirror OpenShift CLI (`oc`) plugin to mirror images to a mirror registry in your fully or partially disconnected environments. You must run oc-mirror from a system with internet connectivity to download the required images from the official Red{nbsp}Hat registries.
 
-See xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin] for additional details.
+See xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2] for additional details.
 
 [id="update-mirror-repository-adm-release-mirror_{context}"]
 == Mirroring images using the oc adm release mirror command
diff --git a/disconnected/using-olm.adoc b/disconnected/using-olm.adoc
index 8737b18ed0c9..fb0ab8ad3d97 100644
--- a/disconnected/using-olm.adoc
+++ b/disconnected/using-olm.adoc
@@ -61,7 +61,7 @@ As of {product-title} 4.11, the default Red{nbsp}Hat-provided Operator catalog r
 
 The `opm` subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.
 
-Many of the `opm` subcommands and flags for working with the SQLite database format, such as `opm index prune`, do not work with the file-based catalog format. For more information about working with file-based catalogs, see xref:../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format], xref:../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[Managing custom catalogs], and xref:../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
+Many of the `opm` subcommands and flags for working with the SQLite database format, such as `opm index prune`, do not work with the file-based catalog format. For more information about working with file-based catalogs, see xref:../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format], xref:../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[Managing custom catalogs], and xref:../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2].
 ====
 
 include::modules/olm-creating-catalog-from-index.adoc[leveloffset=+1]
diff --git a/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc b/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc
index 30b84c6480f2..1abb017bdbb9 100644
--- a/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc
+++ b/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc
@@ -18,18 +18,18 @@ include::modules/telco-observability-monitoring-stack.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../../observability/monitoring/monitoring-overview.adoc#understanding-the-monitoring-stack_monitoring-overview[Understanding the monitoring stack]
+* xref:../../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
 
-* xref:../../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[Configuring the monitoring stack]
+* xref:../../../observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc#core-platform-monitoring-first-steps[Core platform monitoring first steps]
 
 include::modules/telco-observability-key-performance-metrics.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[Accessing metrics as an administrator]
+
 * xref:../../../storage/persistent_storage/persistent_storage_local/persistent-storage-local.adoc#local-storage-install_persistent-storage-local[Persistent storage using local volumes]
-* xref:../../../scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#cluster-tuning-crs_ran-ref-design-crs[Cluster tuning reference CRs]
 
 include::modules/telco-observability-monitoring-the-edge.adoc[leveloffset=+1]
 
@@ -38,7 +38,7 @@ include::modules/telco-observability-alerting.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerts[Managing alerts]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-managing-alerts_key-concepts[Managing alerts]
 
 include::modules/telco-observability-workload-monitoring.adoc[leveloffset=+1]
 
@@ -47,6 +47,7 @@ include::modules/telco-observability-workload-monitoring.adoc[leveloffset=+1]
 
 * xref:../../../rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc#servicemonitor-monitoring-coreos-com-v1[ServiceMonitor[monitoring.coreos.com/v1]]
 
-* xref:../../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts-as-an-administrator[Managing alerting rules for user-defined projects]
 
-* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts[Managing alerting rules for user-defined projects]
diff --git a/edge_computing/image_based_upgrade/cnf-image-based-upgrade-base.adoc b/edge_computing/image_based_upgrade/cnf-image-based-upgrade-base.adoc
index bd0b98174100..866fe6ae258a 100644
--- a/edge_computing/image_based_upgrade/cnf-image-based-upgrade-base.adoc
+++ b/edge_computing/image_based_upgrade/cnf-image-based-upgrade-base.adoc
@@ -18,6 +18,8 @@ include::modules/cnf-image-based-upgrade-prep.adoc[leveloffset=+1]
 
 * xref:../../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-prep-resources.adoc#cnf-image-based-upgrade-prep-resources[Creating ConfigMap objects for the image-based upgrade with {lcao}]
 
+* xref:../../openshift_images/image-configuration.adoc#images-configuration-registry-mirror-configuring_image-configuration[Configuring image registry repository mirroring]
+
 include::modules/cnf-image-based-upgrade-with-backup.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
diff --git a/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc b/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc
index 9250769a5709..8fc5e0bbd1d0 100644
--- a/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc
+++ b/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc
@@ -45,7 +45,7 @@ include::modules/ztp-using-pgt-to-configure-power-states.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#configuring-workload-hints_cnf-low-latency-perf-profile[Configuring node power consumption and realtime processing with workload hints]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#configuring-workload-hints_cnf-low-latency-perf-profile[Configuring node power consumption and realtime processing with workload hints]
 
 include::modules/ztp-using-pgt-to-configure-performance-mode.adoc[leveloffset=+2]
 
@@ -56,7 +56,7 @@ include::modules/ztp-using-pgt-to-configure-power-saving-mode.adoc[leveloffset=+
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
 
 * xref:../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
 
diff --git a/edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc b/edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc
index eda85b1db603..d0eaeb95922d 100644
--- a/edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc
+++ b/edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc
@@ -41,7 +41,7 @@ include::modules/ztp-using-pgt-to-configure-power-states.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#configuring-workload-hints_cnf-low-latency-perf-profile[Configuring node power consumption and realtime processing with workload hints]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#configuring-workload-hints_cnf-low-latency-perf-profile[Configuring node power consumption and realtime processing with workload hints]
 
 include::modules/ztp-using-pgt-to-configure-performance-mode.adoc[leveloffset=+2]
 
@@ -54,7 +54,7 @@ include::modules/ztp-using-pgt-to-configure-power-saving-mode.adoc[leveloffset=+
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
 
 * xref:../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
 
diff --git a/edge_computing/ztp-advanced-install-ztp.adoc b/edge_computing/ztp-advanced-install-ztp.adoc
index 0374aea69c97..b3d281b5aed1 100644
--- a/edge_computing/ztp-advanced-install-ztp.adoc
+++ b/edge_computing/ztp-advanced-install-ztp.adoc
@@ -8,6 +8,8 @@ toc::[]
 
 You can use `SiteConfig` custom resources (CRs) to deploy custom functionality and configurations in your managed clusters at installation time.
 
+include::snippets/siteconfig-deprecation-notice.adoc[]
+
 include::modules/ztp-customizing-the-install-extra-manifests.adoc[leveloffset=+1]
 
 include::modules/ztp-filtering-ai-crs-using-siteconfig.adoc[leveloffset=+1]
diff --git a/edge_computing/ztp-preparing-the-hub-cluster.adoc b/edge_computing/ztp-preparing-the-hub-cluster.adoc
index 7a93e3f19145..6d757bce6773 100644
--- a/edge_computing/ztp-preparing-the-hub-cluster.adoc
+++ b/edge_computing/ztp-preparing-the-hub-cluster.adoc
@@ -62,3 +62,14 @@ include::snippets/pgt-deprecation-notice.adoc[]
 * xref:../edge_computing/policygenerator_for_ztp/ztp-configuring-managed-clusters-policygenerator.adoc#ztp-comparing-pgt-and-rhacm-pg-patching-strategies_ztp-configuring-managed-clusters-policygenerator[Comparing {rh-rhacm} PolicyGenerator and PolicyGenTemplate resource patching]
 
 include::modules/ztp-preparing-the-ztp-git-repository-ver-ind.adoc[leveloffset=+1]
+
+include::modules/ztp-configuring-the-hub-cluster-for-backup-and-restore.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/latest/html/business_continuity/business-cont-overview#managed-cluster-activation-data[Restoring managed cluster activation data]
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/latest/html/business_continuity/business-cont-overview#active-passive-config[Active-passive configuration]
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/latest/html/business_continuity/business-cont-overview#restore-activation-resources[Restoring activation resources]
diff --git a/extensions/catalogs/catalog-content-resolution.adoc b/extensions/catalogs/catalog-content-resolution.adoc
new file mode 100644
index 000000000000..becd134a6dd7
--- /dev/null
+++ b/extensions/catalogs/catalog-content-resolution.adoc
@@ -0,0 +1,25 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="catalog-content-resolution"]
+= Catalog content resolution
+include::_attributes/common-attributes.adoc[]
+:context: catalog-content-resolution
+
+toc::[]
+
+When you specify the cluster extension you want to install in a custom resource (CR), {olmv1-first} uses catalog selection to resolve what content is installed.
+
+You can perform the following actions to control the selection of catalog content:
+
+* Specify labels to select the catalog.
+* Use match expressions to perform complex filtering across catalogs.
+* Set catalog priority.
+
+If you do not specify any catalog selection criteria, {olmv1-first} selects an extension from any available catalog on the cluster that provides the requested package.
+
+During resolution, bundles that are not deprecated are preferred over deprecated bundles by default.
+
+include::modules/olmv1-catalog-selection-by-name.adoc[leveloffset=1]
+include::modules/olmv1-catalog-selection-by-labels-or-expressions.adoc[leveloffset=1]
+include::modules/olmv1-catalog-exclusion-by-labels-or-expressions.adoc[leveloffset=1]
+include::modules/olmv1-catalog-selection-by-priority.adoc[leveloffset=1]
+include::modules/olmv1-troubleshooting-catalog-selection-errors.adoc[leveloffset=1]
diff --git a/extensions/catalogs/disconnected-catalogs.adoc b/extensions/catalogs/disconnected-catalogs.adoc
new file mode 100644
index 000000000000..d1ae48d488fb
--- /dev/null
+++ b/extensions/catalogs/disconnected-catalogs.adoc
@@ -0,0 +1,16 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="disconnected-catalogs"]
+= Disconnected environment support in {olmv1}
+include::_attributes/common-attributes.adoc[]
+:context: disconnected-catalogs
+
+toc::[]
+
+To support cluster administrators that prioritize high security by running their clusters in internet-disconnected environments, especially for mission-critical production workloads, {olmv1-first} includes cluster extension lifecycle management functionality that works within these disconnected environments, starting in {product-title} 4.18.
+
+include::modules/olmv1-about-disconnected.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin v1]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation using the oc-mirror plugin v2]
\ No newline at end of file
diff --git a/extensions/catalogs/managing-catalogs.adoc b/extensions/catalogs/managing-catalogs.adoc
index ed31693f80b4..530a8a5703c5 100644
--- a/extensions/catalogs/managing-catalogs.adoc
+++ b/extensions/catalogs/managing-catalogs.adoc
@@ -28,3 +28,4 @@ include::modules/olmv1-about-catalogs.adoc[leveloffset=+1]
 include::modules/olmv1-red-hat-catalogs.adoc[leveloffset=+1]
 include::modules/olmv1-adding-a-catalog.adoc[leveloffset=+1]
 include::modules/olmv1-deleting-catalog.adoc[leveloffset=+1]
+include::modules/olmv1-disabling-a-default-catalog.adoc[leveloffset=+1]
diff --git a/extensions/ce/managing-ce.adoc b/extensions/ce/managing-ce.adoc
index 6c6ba06d0ea1..47c744bd6a15 100644
--- a/extensions/ce/managing-ce.adoc
+++ b/extensions/ce/managing-ce.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 After a catalog has been added to your cluster, you have access to the versions, patches, and over-the-air updates of the extensions and Operators that are published to the catalog.
 
-You can manage extensions declaratively from the CLI using custom resources (CRs).
+You can use custom resources (CRs) to manage extensions declaratively from the CLI.
 
 include::modules/olmv1-supported-extensions.adoc[leveloffset=+1]
 
@@ -18,20 +18,27 @@ include::modules/olmv1-supported-extensions.adoc[leveloffset=+1]
 
 include::modules/olmv1-finding-operators-to-install.adoc[leveloffset=+1]
 include::modules/olmv1-catalog-queries.adoc[leveloffset=+2]
-include::modules/olmv1-creating-a-service-account.adoc[leveloffset=+1]
+include::modules/olmv1-cluster-extension-permissions.adoc[leveloffset=+1]
+include::modules/olmv1-creating-a-namespace.adoc[leveloffset=+2]
+include::modules/olmv1-creating-a-service-account.adoc[leveloffset=+2]
+include::modules/olmv1-downloading-bundle-manifests.adoc[leveloffset=+2]
+include::modules/olmv1-required-rbac-to-install-and-manage-extension-resources.adoc[leveloffset=+2]
+include::modules/olmv1-creating-a-cluster-role.adoc[leveloffset=+2]
+include::modules/olmv1-example-pipelines-operator-cluster-role.adoc[leveloffset=+2]
+include::modules/olmv1-creating-a-cluster-role-binding.adoc[leveloffset=+2]
 include::modules/olmv1-installing-an-operator.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../extensions/ce/managing-ce.adoc#olmv1-supported-extensions_managing-ce[Supported extensions]
 * xref:../../extensions/ce/managing-ce.adoc#olmv1-creating-a-service-account_managing-ce[Creating a service account]
-* xref:../../extensions/ce/upgrade-edges.adoc#olmv1-about-target-versions_upgrade-edges[Example custom resources (CRs) that specify a target version]
-* xref:../../extensions/ce/upgrade-edges.adoc#olmv1-version-range-support_upgrade-edges[Support for version ranges]
+* xref:../../extensions/ce/update-paths.adoc#olmv1-about-target-versions_update-paths[Example custom resources (CRs) that specify a target version]
+* xref:../../extensions/ce/update-paths.adoc#olmv1-version-range-support_update-paths[Support for version ranges]
 
 include::modules/olmv1-updating-an-operator.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../extensions/ce/upgrade-edges.adoc#upgrade-edges[Upgrade edges]
+* xref:../../extensions/ce/update-paths.adoc#update-paths[Update paths]
 
 include::modules/olmv1-deleting-an-operator.adoc[leveloffset=+1]
diff --git a/extensions/ce/update-paths.adoc b/extensions/ce/update-paths.adoc
new file mode 100644
index 000000000000..02164122ab32
--- /dev/null
+++ b/extensions/ce/update-paths.adoc
@@ -0,0 +1,66 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="update-paths"]
+= Update paths
+include::_attributes/common-attributes.adoc[]
+:context: update-paths
+
+toc::[]
+
+When determining _update paths_, also known as upgrade edges or upgrade constraints, for an installed cluster extension, {olmv1-first} supports {olmv0} semantics starting in {product-title} 4.16. This support follows the behavior from {olmv0}, including `replaces`, `skips`, and `skipRange` directives, with a few noted differences.
+
+By supporting {olmv0} semantics, {olmv1} accurately reflects the update graph from catalogs.
+
+.Differences from original {olmv0} implementation
+
+* If there are multiple possible successors, {olmv1} behavior differs in the following ways:
+** In {olmv0}, the successor closest to the channel head is chosen.
+** In {olmv1}, the successor with the highest semantic version (semver) is chosen.
+
+* Consider the following set of file-based catalog (FBC) channel entries:
++
+[source,yaml]
+----
+# ...
+- name: example.v3.0.0
+  skips: ["example.v2.0.0"]
+- name: example.v2.0.0
+  skipRange: >=1.0.0 <2.0.0
+----
++
+If `1.0.0` is installed, {olmv1} behavior differs in the following ways:
++
+--
+** {olmv0-caps} will not detect an update path to `v2.0.0` because `v2.0.0` is skipped and not on the `replaces` chain.
+** {olmv1} will detect the update path because {olmv1} does not have a concept of a `replaces` chain. {olmv1} finds all entries that have a `replace`, `skip`, or `skipRange` value that covers the currently installed version.
+--
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../operators/understanding/olm/olm-workflow.adoc#olm-upgrades_olm-workflow[{olmv0-caps} upgrade semantics]
+
+include::modules/olmv1-version-range-support.adoc[leveloffset=+1]
+
+include::modules/olmv1-version-range-comparisons.adoc[leveloffset=+1]
+include::modules/olmv1-about-target-versions.adoc[leveloffset=+1]
+include::modules/olmv1-forcing-an-update-or-rollback.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../extensions/ce/update-paths.adoc#olmv1-version-range-support_update-paths[Support for version ranges]
+// after #82245 merges, add an xref to _Creating a service account to manage cluster extensions_
+
+include::modules/olmv1-ocp-compat.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/[Deprecated API Migration Guide] (Kubernetes documentation)
+
+
+include::modules/olmv1-blocked-cluster-updates.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../updating/understanding_updates/intro-to-updates.adoc#understanding_clusteroperator_conditiontypes_understanding-openshift-updates[Understanding cluster Operator condition types]
+* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Upgrading installed Operators]
+* xref:../../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster]
+* xref:../../operators/operator-reference.adoc#cluster-operators-ref-olmv1_cluster-operators-ref[Cluster Operators reference -> {olmv1-first} Operator]
diff --git a/extensions/ce/upgrade-edges.adoc b/extensions/ce/upgrade-edges.adoc
deleted file mode 100644
index 3f91a264ccb3..000000000000
--- a/extensions/ce/upgrade-edges.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="upgrade-edges"]
-= Upgrade edges
-include::_attributes/common-attributes.adoc[]
-:context: upgrade-edges
-
-toc::[]
-
-When determining upgrade edges, also known as upgrade paths or upgrade constraints, for an installed cluster extension, {olmv1-first} supports {olmv0} semantics starting in {product-title} 4.16. This support follows the behavior from {olmv0}, including `replaces`, `skips`, and `skipRange` directives, with a few noted differences.
-
-By supporting {olmv0} semantics, {olmv1} now honors the upgrade graph from catalogs accurately.
-
-.Differences from original {olmv0} implementation
-
-* If there are multiple possible successors, {olmv1} behavior differs in the following ways:
-** In {olmv0}, the successor closest to the channel head is chosen.
-** In {olmv1}, the successor with the highest semantic version (semver) is chosen.
-
-* Consider the following set of file-based catalog (FBC) channel entries:
-+
-[source,yaml]
-----
-# ...
-- name: example.v3.0.0
-  skips: ["example.v2.0.0"]
-- name: example.v2.0.0
-  skipRange: >=1.0.0 <2.0.0
-----
-+
-If `1.0.0` is installed, {olmv1} behavior differs in the following ways:
-+
---
-** {olmv0-caps} will not detect an upgrade edge to `v2.0.0` because `v2.0.0` is skipped and not on the `replaces` chain.
-** {olmv1} will detect the upgrade edge because {olmv1} does not have a concept of a `replaces` chain. {olmv1} finds all entries that have a `replace`, `skip`, or `skipRange` value that covers the currently installed version.
---
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../operators/understanding/olm/olm-workflow.adoc#olm-upgrades_olm-workflow[{olmv0-caps} upgrade semantics]
-
-include::modules/olmv1-version-range-support.adoc[leveloffset=+1]
-
-include::modules/olmv1-version-range-comparisons.adoc[leveloffset=+1]
-include::modules/olmv1-about-target-versions.adoc[leveloffset=+1]
-include::modules/olmv1-forcing-an-update-or-rollback.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../extensions/ce/upgrade-edges.adoc#olmv1-version-range-support_upgrade-edges[Support for version ranges]
-// after #82245 merges, add an xref to _Creating a service account to manage cluster extensions_
diff --git a/extensions/ce/user-access-resources.adoc b/extensions/ce/user-access-resources.adoc
new file mode 100644
index 000000000000..22efc68738ad
--- /dev/null
+++ b/extensions/ce/user-access-resources.adoc
@@ -0,0 +1,35 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="user-access-resources"]
+= User access to extension resources
+include::_attributes/common-attributes.adoc[]
+:context: user-access-resources
+
+toc::[]
+
+After a cluster extension has been installed and is being managed by {olmv1-first}, the extension can often provide `CustomResourceDefinition` objects (CRDs) that expose new API resources on the cluster. Cluster administrators typically have full management access to these resources by default, whereas non-cluster administrator users, or _regular users_, might lack sufficient permissions.
+
+{olmv1} does not automatically configure or manage role-based access control (RBAC) for regular users to interact with the APIs provided by installed extensions. Cluster administrators must define the required RBAC policy to create, view, or edit these custom resources (CRs) for such users.
+
+[NOTE]
+====
+The RBAC permissions described for user access to extension resources are different from the permissions that must be added to a service account to enable {olmv1}-based initial installation of a cluster extension itself. For more on RBAC requirements while installing an extension, see "Cluster extension permissions" in "Managing extensions".
+====
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../extensions/ce/managing-ce.adoc#olmv1-cluster-extension-permissions_managing-ce["Managing extensions" -> "Cluster extension permissions"]
+
+include::modules/olmv1-default-cluster-roles-users.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles[User-facing roles] (Kubernetes documentation)
+
+include::modules/olmv1-finding-ce-resources.adoc[leveloffset=+1]
+include::modules/olmv1-granting-user-access-binding.adoc[leveloffset=+1]
+include::modules/olmv1-granting-user-access-aggregated.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles[Aggregated ClusterRoles] (Kubernetes documentation)
+
diff --git a/extensions/index.adoc b/extensions/index.adoc
index 365ae5456b87..e6bc3a7fa8d8 100644
--- a/extensions/index.adoc
+++ b/extensions/index.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 Extensions enable cluster administrators to extend capabilities for users on their {product-title} cluster.
 
-{olm-first} has been included with {product-title} 4 since its initial release. {product-title} 4.17 includes components for a next-generation iteration of {olm} as a Generally Available (GA) feature, known during this phase as _{olmv1}_. This updated framework evolves many of the concepts that have been part of previous versions of {olm} and adds new capabilities.
+{olm-first} has been included with {product-title} 4 since its initial release. {product-title} {product-version} includes components for a next-generation iteration of {olm} as a Generally Available (GA) feature, known during this phase as _{olmv1}_. This updated framework evolves many of the concepts that have been part of previous versions of {olm} and adds new capabilities.
 
 [id="olmv1-highlights_{context}"]
 == Highlights
diff --git a/extensions/of-terms.adoc b/extensions/of-terms.adoc
index fb1fc71e8436..41ffce5391ae 100644
--- a/extensions/of-terms.adoc
+++ b/extensions/of-terms.adoc
@@ -8,4 +8,4 @@ toc::[]
 
 The following terms are related to the Operator Framework, including {olmv1-first}.
 
-include::modules/olm-terms.adoc[leveloffset=+1]
+include::snippets/of-terms-snippet.adoc[leveloffset=+0]
diff --git a/getting_started/openshift-overview.adoc b/getting_started/openshift-overview.adoc
index 944684e536e9..7646eb7a7251 100644
--- a/getting_started/openshift-overview.adoc
+++ b/getting_started/openshift-overview.adoc
@@ -72,7 +72,7 @@ describes an application that can be deployed using the Helm CLI.
 * **xref:../applications/deployments/what-deployments-are.adoc#what-deployments-are[Create deployments]**:  Use `Deployment` and `DeploymentConfig` objects to exert fine-grained management over applications.
  xref:../applications/deployments/managing-deployment-processes.adoc#deployment-operations[Manage deployments] using the *Workloads* page or OpenShift CLI (`oc`). Learn xref:../applications/deployments/deployment-strategies.adoc#deployment-strategies[rolling, recreate, and custom] deployment strategies.
 
-* **xref:../openshift_images/using-templates.adoc#using-templates[Create templates]**: Use existing templates or create your own templates that describe how an application is built or deployed. A template can combine images with descriptions, parameters, replicas, exposed ports and other content that defines how an application can be run or built.
+* **xref:../applications/creating_applications/using-templates.adoc#using-templates[Create templates]**: Use existing templates or create your own templates that describe how an application is built or deployed. A template can combine images with descriptions, parameters, replicas, exposed ports and other content that defines how an application can be run or built.
 
 * **xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Understand Operators]**: Operators are the preferred method for creating on-cluster applications for {product-title} {product-version}. Learn about the Operator Framework and how to deploy applications using installed Operators into your projects.
 
@@ -106,10 +106,10 @@ be reviewed by cluster administrators and xref:../operators/admin/olm-adding-ope
 
 * **xref:../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scale] and xref:../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[tune] clusters**: Set cluster limits, tune nodes, scale cluster monitoring, and optimize networking, storage, and routes for your environment.
 
-* **xref:../disconnected/updating/disconnected-update-osus.adoc#update-service-overview_updating-disconnected-cluster-osus[Using the OpenShift Update Service in a disconnected environement]**: Learn about installing and managing a local OpenShift Update Service for recommending {product-title} updates in disconnected environments.
+* **xref:../disconnected/updating/disconnected-update-osus.adoc#update-service-overview_updating-disconnected-cluster-osus[Using the OpenShift Update Service in a disconnected environment]**: Learn about installing and managing a local OpenShift Update Service for recommending {product-title} updates in disconnected environments.
 
-* **xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitor clusters]**:
-Learn to  xref:../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[configure the monitoring stack].
-After configuring monitoring, use the web console to access xref:../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[monitoring dashboards]. In addition to infrastructure metrics, you can also scrape and view metrics for your own services.
+* **xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[Monitor clusters]**:
+Learn to  xref:../observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc#core-platform-monitoring-first-steps[configure the monitoring stack].
+After configuring monitoring, use the web console to access xref:../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[monitoring dashboards]. In addition to infrastructure metrics, you can also scrape and view metrics for your own services.
 
 * **xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring_about-remote-health-monitoring[Remote health monitoring]**: {product-title} collects anonymized aggregated information about your cluster. Using Telemetry and the Insights Operator, this data is received by Red Hat and used to improve {product-title}. You can view the xref:../support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc#showing-data-collected-by-remote-health-monitoring_showing-data-collected-by-remote-health-monitoring[data collected by remote health monitoring].
diff --git a/hardware_accelerators/nvidia-gpu-architecture.adoc b/hardware_accelerators/nvidia-gpu-architecture.adoc
index a6ec3bcdc228..3ce6e0d0acfc 100644
--- a/hardware_accelerators/nvidia-gpu-architecture.adoc
+++ b/hardware_accelerators/nvidia-gpu-architecture.adoc
@@ -24,7 +24,6 @@ include::modules/nvidia-gpu-prerequisites.adoc[leveloffset=+1]
 // New enablement modules
 ifndef::openshift-dedicated,openshift-rosa[]
 include::modules/nvidia-gpu-enablement.adoc[leveloffset=+1]
-
 include::modules/nvidia-gpu-bare-metal.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
@@ -40,10 +39,8 @@ include::modules/nvidia-gpu-vsphere.adoc[leveloffset=+2]
 .Additional resources
 * link:https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/openshift/nvaie-with-ocp.html#openshift-container-platform-on-vmware-vsphere-with-nvidia-vgpus[OpenShift Container Platform on VMware vSphere with NVIDIA vGPUs]
 
+// OCPBUGS-45422 Removed link.
 include::modules/nvidia-gpu-kvm.adoc[leveloffset=+2]
-[role="_additional-resources"]
-.Additional resources
-* link:https://computingforgeeks.com/how-to-deploy-openshift-container-platform-on-kvm/[How To Deploy OpenShift Container Platform 4.13 on KVM]
 
 include::modules/nvidia-gpu-csps.adoc[leveloffset=+2]
 [role="_additional-resources"]
diff --git a/hardware_enablement/kmm-kernel-module-management.adoc b/hardware_enablement/kmm-kernel-module-management.adoc
index 4caaed881243..c20db1332850 100644
--- a/hardware_enablement/kmm-kernel-module-management.adoc
+++ b/hardware_enablement/kmm-kernel-module-management.adoc
@@ -104,6 +104,13 @@ include::modules/kmm-building-and-signing-a-kmod-image.adoc[leveloffset=+1]
 .Additional resources
 * link:https://docs.openshift.com/container-platform/4.12/authentication/understanding-and-creating-service-accounts.html#service-accounts-managing_understanding-service-accounts[Creating service accounts]
 
+// Added for TELCODOCS-2197
+include::modules/kmm-using-tolerations-for-kernel-module-scheduling.adoc[leveloffset=+1]
+include::modules/kmm-applying-tolerations-to-kernel-module-pods.adoc[leveloffset=+1]
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.openshift.com/container-platform/4.17/nodes/scheduling/nodes-scheduler-taints-tolerations.html#nodes-scheduler-taints-tolerations-about_nodes-scheduler-taints-tolerations[Understanding taints and tolerations]
+
 // Added for TELCODOCS-1109
 include::modules/kmm-hub-hub-and-spoke.adoc[leveloffset=+1]
 [role="_additional-resources"]
diff --git a/hardware_enablement/kmm-release-notes.adoc b/hardware_enablement/kmm-release-notes.adoc
new file mode 100644
index 000000000000..abddb896151b
--- /dev/null
+++ b/hardware_enablement/kmm-release-notes.adoc
@@ -0,0 +1,31 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="kmm-release-notes"]
+= Kernel Module Management Operator release notes
+include::_attributes/common-attributes.adoc[]
+:context: kmm-release-notes
+
+toc::[]
+
+[id="kmm-2-2-RN"]
+== Release notes for Kernel Module Management Operator 2.2
+=== New features
+// TELCODOCS-2022
+* KMM is now using the CRI-O container engine to pull container images in the worker pod instead of using HTTP calls directly from the worker container. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-example-cr_kernel-module-management-operator[Example Module CR].
+
+// TELCODOCS-2028
+* The Kernel Module Management (KMM) Operator images are now based on `rhel-els-minimal` container images instead of the `rhel-els` images. This change results in a greatly reduced image footprint, while still maintaining FIPS compliance.
+
+// TELCODOCS-1994
+* In this release, the firmware search path has been updated to copy the contents of the specified path into the path specified in worker.setFirmwareClassPath (default: /var/lib/firmware). For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-example-cr_kernel-module-management-operator[Example Module CR].
+
+// TELCODOCS-1977
+* For each node running a kernel matching the regular expression, KMM now checks if you have included a tag or a digest. If you have not specified a tag or digest in the container image, then the validation webhook returns an error and does not apply the module. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-example-cr_kernel-module-management-operator[Example Module CR].
+
+[id="kmm-2-3-RN"]
+== Release notes for Kernel Module Management Operator 2.3
+=== New features
+// TELCODOCS-2221
+* In this release, KMM uses version 1.23 of the Golang programming language to ensure test continuity for partners.
+
+// TELCODOCS-2197
+* You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
\ No newline at end of file
diff --git a/scalability_and_performance/telco_ref_design_specs/_attributes b/hardware_enablement/release-notes/_attributes
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/_attributes
rename to hardware_enablement/release-notes/_attributes
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc
index a9e08b3be27b..ec6de219e83a 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc
@@ -16,11 +16,11 @@ include::modules/hcp-aws-prereqs.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
 
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc#hcp-enable-manual_hcp-enable-disable[Manually enabling the {hcp} feature]
 
@@ -68,7 +68,7 @@ include::modules/hcp-create-np-arm64-aws.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest]
 
 include::modules/hcp-create-private-hc-aws.adoc[leveloffset=+1]
 
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc
index b13e38ea5f76..62d1aebbac3a 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc
@@ -26,8 +26,8 @@ include::modules/hcp-bm-prereqs.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
 
 include::modules/hcp-bm-firewall-port-svc-reqs.adoc[leveloffset=+2]
 
@@ -43,7 +43,7 @@ include::modules/hcp-bm-infra-reqs.adoc[leveloffset=+2]
 * xref:../../storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc[Persistent storage using {lvms}]
 * xref:../../hosted_control_planes/hcp-import.adoc#hcp-import-disable_hcp-import[Disabling the automatic import of hosted clusters into {mce-short}]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc[Enabling or disabling the {hcp} feature]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
 
 include::modules/hcp-bm-dns.adoc[leveloffset=+1]
 include::modules/hcp-bm-hc.adoc[leveloffset=+1]
@@ -60,9 +60,9 @@ include::modules/hcp-bm-hc-console.adoc[leveloffset=+2]
 include::modules/hcp-bm-hc-mirror.adoc[leveloffset=+2]
 
 .Next steps
-* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
+* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
 * To access a hosted cluster, see xref:../../hosted_control_planes/hcp-manage/hcp-manage-bm.adoc#hcp-bm-access_hcp-manage-bm[Accessing the hosted cluster].
-* To add hosts to the host inventory by using the Discovery Image, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#add-host-host-inventory[Adding hosts to the host inventory by using the Discovery Image].
-* To extract the {product-title} release image digest, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest].
+* To add hosts to the host inventory by using the Discovery Image, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#add-host-host-inventory[Adding hosts to the host inventory by using the Discovery Image].
+* To extract the {product-title} release image digest, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest].
 
 include::modules/hcp-bm-verify.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc
index 5be9414244b6..070964dc262c 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc
@@ -26,8 +26,8 @@ include::modules/hcp-ibm-power-prereqs.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-cli.adoc#hcp-cli-terminal_hcp-cli[Installing the {hcp} command-line interface]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc#hcp-enable-manual_hcp-enable-disable[Manually enabling the {hcp} feature]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc#hcp-disable_hcp-enable-disable[Disabling the {hcp} feature]
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc
index 23fd8bfe6cd8..8041837ae326 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc
@@ -28,8 +28,8 @@ include::modules/hcp-ibm-z-prereqs.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-cli.adoc#hcp-cli-terminal_hcp-cli[Installing the {hcp} command-line interface]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc[Enabling or disabling the {hcp} feature]
 
@@ -42,6 +42,12 @@ include::modules/hcp-ibm-z-infra-reqs.adoc[leveloffset=+1]
 
 include::modules/hcp-ibm-z-dns.adoc[leveloffset=+1]
 include::modules/hcp-bm-hc.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc#hcp-bm-hc-console_hcp-deploy-bm[Creating a hosted cluster on bare metal by using the console]
+
 include::modules/hcp-ibm-z-infraenv.adoc[leveloffset=+1]
 
 [id="hcp-ibm-z-add-agents"]
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc
index cdd168f9c9dc..abab84b2643a 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc
@@ -30,9 +30,9 @@ include::modules/hcp-non-bm-prereqs.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service]
 
 include::modules/hcp-non-bm-firewall-port-svc-reqs.adoc[leveloffset=+2]
 include::modules/hcp-non-bm-infra-reqs.adoc[leveloffset=+2]
@@ -50,7 +50,7 @@ include::modules/hcp-non-bm-infra-reqs.adoc[leveloffset=+2]
 
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc#hcp-disable_hcp-enable-disable[Disabling the {hcp} feature]
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
 
 include::modules/hcp-non-bm-dns.adoc[leveloffset=+1]
 include::modules/hcp-non-bm-hc.adoc[leveloffset=+1]
@@ -70,12 +70,12 @@ include::modules/hcp-bm-hc-mirror.adoc[leveloffset=+2]
 
 .Next steps
 
-* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
+* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
 
 * To access a hosted cluster, see xref:../../hosted_control_planes/hcp-manage/hcp-manage-bm.adoc#hcp-bm-access_hcp-manage-bm[Accessing the hosted cluster].
 
-* To add hosts to the host inventory by using the Discovery Image, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#add-host-host-inventory[Adding hosts to the host inventory by using the Discovery Image].
+* To add hosts to the host inventory by using the Discovery Image, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#add-host-host-inventory[Adding hosts to the host inventory by using the Discovery Image].
 
-* To extract the {product-title} release image digest, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest].
+* To extract the {product-title} release image digest, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#configure-hosted-disconnected-digest-image[Extracting the {product-title} release image digest].
 
 include::modules/hcp-non-bm-verify.adoc[leveloffset=+1]
diff --git a/hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc b/hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc
index 0ee6c86f626c..fad167592c24 100644
--- a/hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc
+++ b/hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc
@@ -21,7 +21,7 @@ You can use the hosted control plane command line interface, `hcp`, to create an
 .Additional resources
 * xref:../../hosted_control_planes/hcp-import.adoc#hcp-import-disable_hcp-import[Disabling the automatic import of hosted clusters into {mce-short}]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc[Enabling or disabling the {hcp} feature]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
 
 include::modules/hcp-virt-reqs.adoc[leveloffset=+1]
 
@@ -39,7 +39,7 @@ include::modules/hcp-virt-prereqs.adoc[leveloffset=+2]
 * xref:../../post_installation_configuration/post-install-storage-configuration.adoc#post-install-storage-configuration[Postinstallation storage configuration]
 * link:https://console.redhat.com/openshift/install/platform-agnostic/user-provisioned[Install OpenShift on any x86_64 platform with user-provisioned infrastructure]
 * xref:../../hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc#hcp-metallb_hcp-deploy-virt[Configuring MetalLB]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration]
 
 include::modules/hcp-virt-firewall-port.adoc[leveloffset=+2]
 
@@ -57,7 +57,7 @@ include::modules/hcp-virt-create-hc-console.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
+* To create credentials that you can reuse when you create a hosted cluster with the console, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment].
 
 * To access the hosted cluster, see xref:../../hosted_control_planes/hcp-manage/hcp-manage-virt.adoc#hcp-virt-access_hcp-manage-virt[Accessing the hosted cluster].
 
diff --git a/hosted_control_planes/hcp-disconnected/disconnected-install-ibmz-hcp.adoc b/hosted_control_planes/hcp-disconnected/disconnected-install-ibmz-hcp.adoc
index a034bfcd856d..db6b273ade45 100644
--- a/hosted_control_planes/hcp-disconnected/disconnected-install-ibmz-hcp.adoc
+++ b/hosted_control_planes/hcp-disconnected/disconnected-install-ibmz-hcp.adoc
@@ -24,7 +24,7 @@ include::modules/hcp-ibm-z-dc-prereqs.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#mirror-registry-introduction_installing-mirroring-creating-registry[Creating a mirror registry with mirror registry for Red Hat OpenShift]
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]
 
 
 include::modules/hcp-ibm-z-adding-credentials-registry.adoc[leveloffset=+1]
diff --git a/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm.adoc b/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm.adoc
index aedb5a095425..e18c51eb66c5 100644
--- a/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm.adoc
+++ b/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-When you provision {hcp} on bare metal, you use the Agent platform. The Agent platform and {mce} work together to enable disconnected deployments. The Agent platform uses the central infrastructure management service to add worker nodes to a hosted cluster. For an introduction to the central infrastructure management service, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service].
+When you provision {hcp} on bare metal, you use the Agent platform. The Agent platform and {mce} work together to enable disconnected deployments. The Agent platform uses the central infrastructure management service to add worker nodes to a hosted cluster. For an introduction to the central infrastructure management service, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service].
 
 include::modules/hcp-dc-bm-arch.adoc[leveloffset=+1]
 include::modules/hcp-dc-bm-reqs.adoc[leveloffset=+1]
@@ -17,19 +17,25 @@ include::modules/hcp-dc-registry.adoc[leveloffset=+1]
 include::modules/hcp-dc-mgmt-cluster.adoc[leveloffset=+1]
 include::modules/hcp-dc-web-server.adoc[leveloffset=+1]
 include::modules/hcp-dc-image-mirror.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-workflows-partially-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a partially disconnected environment]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-workflows-fully-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a fully disconnected environment]
+
 include::modules/hcp-dc-apply-objects.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2].
 
 [id="hcp-dc-mce-bm"]
 == Deploying {mce-short} for a disconnected installation of {hcp}
 
 The {mce} plays a crucial role in deploying clusters across providers. If you do not have {mce-short} installed, review the following documentation to understand the prerequisites and steps to install it:
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#mce-intro[About cluster lifecycle with multicluster engine operator]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#mce-intro[About cluster lifecycle with multicluster engine operator]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator]
 
 include::modules/hcp-agentserviceconfig.adoc[leveloffset=+2]
 
diff --git a/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc b/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc
index 140bc63dc879..9c3544f20a85 100644
--- a/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc
+++ b/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc
@@ -15,19 +15,25 @@ When you deploy {hcp} in a disconnected environment, some of the steps differ de
 * You have an internal registry to mirror images on. For more information, see xref:../../disconnected/mirroring/index.adoc#installing-mirroring-disconnected-about[About disconnected installation mirroring].
 
 include::modules/hcp-dc-image-mirror.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-workflows-partially-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a partially disconnected environment]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-workflows-fully-disconnected-v2_about-installing-oc-mirror-v2[Mirroring an image set in a fully disconnected environment]
+
 include::modules/hcp-dc-apply-objects.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2].
 
 [id="hcp-dc-mce-virt"]
 == Deploying {mce-short} for a disconnected installation of {hcp}
 
 The {mce} plays a crucial role in deploying clusters across providers. If you do not have {mce-short} installed, review the following documentation to understand the prerequisites and steps to install it:
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#mce-intro[About cluster lifecycle with multicluster engine operator]
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#mce-intro[About cluster lifecycle with multicluster engine operator]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#mce-install-intro[Installing and upgrading multicluster engine operator]
 
 [id="hcp-dc-tls-virt"]
 == Configuring TLS certificates for a disconnected installation of {hcp}
@@ -61,4 +67,4 @@ include::modules/hcp-virt-wildcard-dns.adoc[leveloffset=+3]
 You can monitor the deployment of a hosted cluster from two perspectives: the control plane and the data plane.
 
 include::modules/hcp-monitor-cp.adoc[leveloffset=+2]
-include::modules/hcp-monitor-dp.adoc[leveloffset=+2]
\ No newline at end of file
+include::modules/hcp-monitor-dp.adoc[leveloffset=+2]
diff --git a/hosted_control_planes/hcp-machine-config.adoc b/hosted_control_planes/hcp-machine-config.adoc
index b7b66f1198e2..4434735c58ea 100644
--- a/hosted_control_planes/hcp-machine-config.adoc
+++ b/hosted_control_planes/hcp-machine-config.adoc
@@ -8,6 +8,11 @@ toc::[]
 
 In a standalone {product-title} cluster, a machine config pool manages a set of nodes. You can handle a machine configuration by using the `MachineConfigPool` custom resource (CR).
 
+[TIP]
+====
+You can reference any `machineconfiguration.openshift.io` resources in the `nodepool.spec.config` field of the `NodePool` CR.
+====
+
 In {hcp}, the `MachineConfigPool` CR does not exist. A node pool contains a set of compute nodes. You can handle a machine configuration by using node pools.
 
 [NOTE]
@@ -17,6 +22,8 @@ In {product-title} 4.18 or later, the default container runtime for worker nodes
 
 include::modules/configuring-node-pools-for-hcp.adoc[leveloffset=+1]
 
+include::modules/hcp-kubeconf-nodepool.adoc[leveloffset=+1]
+
 include::modules/node-tuning-hosted-cluster.adoc[leveloffset=+1]
 
 include::modules/sriov-operator-hosted-control-planes.adoc[leveloffset=+1]
diff --git a/hosted_control_planes/hcp-manage/hcp-manage-virt.adoc b/hosted_control_planes/hcp-manage/hcp-manage-virt.adoc
index 42d4a8f8b395..5a6833edaefd 100644
--- a/hosted_control_planes/hcp-manage/hcp-manage-virt.adoc
+++ b/hosted_control_planes/hcp-manage/hcp-manage-virt.adoc
@@ -9,6 +9,7 @@ toc::[]
 After you deploy a hosted cluster on {VirtProductName}, you can manage the cluster by completing the following procedures.
 
 include::modules/hcp-virt-access.adoc[leveloffset=+1]
+include::modules/hcp-bm-autoscale.adoc[leveloffset=+1]
 
 [id="hcp-virt-storage"]
 == Configuring storage for {hcp} on {VirtProductName}
@@ -19,25 +20,28 @@ The following table lists the capabilities that the infrastructure must provide
 
 .Persistent storage modes in a hosted cluster
 |===
-| Infrastructure CSI provider | Hosted cluster CSI provider | Hosted cluster capabilities | Notes
+| Infrastructure CSI provider | Hosted cluster CSI provider | Hosted cluster capabilities
 
 | Any RWX `Block` CSI provider
 | `kubevirt-csi`
-| Basic: RWO `Block` and `File`, RWX `Block` and `Snapshot`
-| Recommended
+a|
 
-| Any RWX `Block` CSI provider
-| {rh-storage-first} external mode
-| {rh-storage-first} feature set
-|
+--
+- Basic RWO `Block` and `File`
+- Basic RWX `Block` and `Snapshot`
+- CSI volume cloning
+--
 
 | Any RWX `Block` CSI provider
-| {rh-storage-first} internal mode
-| {rh-storage-first} feature set
-| Do not use
-
+| {rh-storage-first}
+| {rh-storage-first} feature set. External mode has a smaller footprint and uses a standalone Red{nbsp}Hat Ceph Storage. Internal mode has a larger footprint, but is self-contained and suitable for use cases that require expanded capabilities such as RWX `File`.
 |===
 
+[NOTE]
+====
+{VirtProductName} handles storage on hosted clusters, which especially helps customers whose requirements are limited to block storage.
+====
+
 include::modules/hcp-virt-map-storage.adoc[leveloffset=+2]
 include::modules/hcp-virt-csi-snapshot.adoc[leveloffset=+2]
 include::modules/hcp-virt-multiple-snapshots.adoc[leveloffset=+2]
diff --git a/hosted_control_planes/hcp-networking.adoc b/hosted_control_planes/hcp-networking.adoc
new file mode 100644
index 000000000000..7d56160dc785
--- /dev/null
+++ b/hosted_control_planes/hcp-networking.adoc
@@ -0,0 +1,26 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="hcp-networking"]
+include::_attributes/common-attributes.adoc[]
+= Networking for {hcp}
+:context: hcp-networking
+
+toc::[]
+
+For standalone {product-title}, proxy support is mainly about ensuring that workloads in the cluster are configured to use the HTTP or HTTPS proxy to access external services, honoring the `NO_PROXY` setting if one is configured, and accepting any trust bundle that is configured for the proxy.
+
+For {hcp}, proxy support involves the following additional use cases.
+
+//cp workloads that need to use a proxy to access external services
+include::modules/hcp-proxy-cp-workloads.adoc[leveloffset=+1]
+//workers need a proxy to communicate with ignition endpoint
+include::modules/hcp-proxy-ignition.adoc[leveloffset=+1]
+//workers need proxy to communicate with cp
+include::modules/hcp-proxy-api.adoc[leveloffset=+1]
+//cp workloads that need access to external services and must use the proxy for the management cluster
+include::modules/hcp-proxy-mgmt-cluster.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[Configuring the cluster-wide proxy]
\ No newline at end of file
diff --git a/hosted_control_planes/hcp-prepare/hcp-requirements.adoc b/hosted_control_planes/hcp-prepare/hcp-requirements.adoc
index 5aee386087ce..ddee51822f7b 100644
--- a/hosted_control_planes/hcp-prepare/hcp-requirements.adoc
+++ b/hosted_control_planes/hcp-prepare/hcp-requirements.adoc
@@ -6,16 +6,19 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-In the context of {hcp}, a _management cluster_ is an {product-title} cluster where the HyperShift Operator is deployed and where the control planes for hosted clusters are hosted. 
-
-The management cluster and worker nodes must run on the same type of infrastructure. For example, you can run both the management cluster and the worker nodes on-premise, such as on a bare-metal platform or on {VirtProductName}. In addition, you can run both the management cluster and the worker nodes on cloud infrastructure, such as {aws-first}. However, you cannot run your management cluster on the cloud and your worker nodes on-premise, or the other way around.
+In the context of {hcp}, a _management cluster_ is an {product-title} cluster where the HyperShift Operator is deployed and where the control planes for hosted clusters are hosted.
 
 The control plane is associated with a hosted cluster and runs as pods in a single namespace. When the cluster service consumer creates a hosted cluster, it creates a worker node that is independent of the control plane.
 
+You can run both the management cluster and the worker nodes on-premise, such as on a bare-metal platform or on {VirtProductName}. In addition, you can run both the management cluster and the worker nodes on cloud infrastructure, such as {aws-first}. If you use a mixed infrastructure, such as running the management cluster on {aws-short} and your worker nodes on-premise, or running your worker nodes on {aws-short} and your management cluster on-premise, you must use the `PublicAndPrivate` publishing strategy and follow the latency requirements in the support matrix.
+
+In Bare Metal Host (BMH) deployments, where the Bare Metal Operator starts machines, the hosted control plane must be able to reach baseboard management controllers (BMCs). If your security profile does not permit the Cluster Baremetal Operator to access the network where the BMHs have their BMCs in order to enable Redfish automation, you can use BYO ISO support. However, in BYO mode, {product-title} cannot automate the powering on of BMHs.
+
 include::modules/hcp-support-matrix.adoc[leveloffset=+1]
+include::modules/hcp-fips.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* link:https://access.redhat.com/articles/7086906[The {mce} 2.7 support matrix]
+* link:https://access.redhat.com/articles/7099674[The {mce} 2.8 support matrix]
 * link:https://access.redhat.com/labs/ocpouic/?operator=multicluster-engine&&upgrade_path=4.14%20to%204.16[Red{nbsp}Hat {product-title} Operator Update Information Checker]
 * xref:../../hosted_control_planes/hcp-prepare/hcp-sizing-guidance.adoc#hcp-shared-infra_hcp-sizing-guidance[Shared infrastructure between hosted and standalone control planes]
diff --git a/hosted_control_planes/hcp-troubleshooting.adoc b/hosted_control_planes/hcp-troubleshooting.adoc
index 4a6d405a7370..cddb117a393b 100644
--- a/hosted_control_planes/hcp-troubleshooting.adoc
+++ b/hosted_control_planes/hcp-troubleshooting.adoc
@@ -20,7 +20,7 @@ include::modules/hcp-must-gather-dc.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#install-on-disconnected-networks[Install on disconnected networks]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#install-on-disconnected-networks[Install on disconnected networks]
 
 [id="hcp-ts-ocp-virt"]
 == Troubleshooting hosted clusters on {VirtProductName}
@@ -33,7 +33,7 @@ include::modules/hcp-ts-no-nodes-reg.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#identifying-vm-console-logs[Identifying the problem: Access the VM console logs]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#identifying-vm-console-logs[Identifying the problem: Access the VM console logs]
 
 include::modules/hcp-ts-nodes-stuck.adoc[leveloffset=+2]
 include::modules/hcp-ts-ingress-not-online.adoc[leveloffset=+2]
@@ -46,7 +46,19 @@ include::modules/hcp-ts-non-bm.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#remove-managed-cluster[Removing a cluster from management]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#remove-managed-cluster[Removing a cluster from management]
+
+[id="hcp-ts-bm"]
+== Troubleshooting hosted clusters on bare metal
+
+The following information applies to troubleshooting {hcp} on bare metal.
+
+include::modules/hcp-ts-bm-nodes-not-added.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html-single/clusters/index#on-prem-creating-your-cluster-with-the-cli-pull-secret[Add the pull secret to the namespace]
 
 include::modules/hosted-restart-hcp-components.adoc[leveloffset=+1]
 include::modules/hosted-control-planes-pause-reconciliation.adoc[leveloffset=+1]
@@ -55,4 +67,4 @@ include::modules/scale-down-data-plane.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#trouble-hosted-cluster-backplane[Must-gather for a hosted cluster]
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#trouble-hosted-cluster-backplane[Must-gather for a hosted cluster]
diff --git a/hosted_control_planes/hosted-control-planes-release-notes.adoc b/hosted_control_planes/hosted-control-planes-release-notes.adoc
index 432d4fa5ec6f..ea0514c4ff23 100644
--- a/hosted_control_planes/hosted-control-planes-release-notes.adoc
+++ b/hosted_control_planes/hosted-control-planes-release-notes.adoc
@@ -8,86 +8,57 @@ toc::[]
 
 Release notes contain information about new and deprecated features, changes, and known issues.
 
-[id="hcp-4-17-release-notes_{context}"]
-== {hcp-capital} release notes for {product-title} 4.17
+[id="hcp-4-18-release-notes_{context}"]
+== {hcp-capital} release notes for {product-title} 4.18
 
-With this release, {hcp} for {product-title} 4.17 is available. {hcp-capital} for {product-title} 4.17 supports the {mce} version 2.7.
+With this release, {hcp} for {product-title} 4.18 is available. {hcp-capital} for {product-title} 4.18 supports {mce} version 2.8.
 
-[id="hcp-4-17-new-features-and-enhancements_{context}"]
+[id="hcp-4-18-new-features-and-enhancements_{context}"]
 === New features and enhancements
 
 This release adds improvements related to the following concepts:
 
-[id="hcp-4-17-taints-tolerations_{context}"]
-==== Custom taints and tolerations (Technology Preview)
-For {hcp} on {VirtProductName}, you can now apply tolerations to hosted control plane pods by using the `hcp` CLI `-tolerations` argument or by using the `hc.Spec.Tolerations` API file. This feature is available as a Technology Preview feature. For more information, see xref:../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-virt-taints-tolerations_hcp-distribute-workloads[Custom taints and tolerations].
+[id="hcp-4-18-hcp-ocp_{context}"]
+==== Comparing {hcp} with {product-title}
 
-[id="hcp-4-17-nvidia-gpu_{context}"]
-==== Support for NVIDIA GPU devices on {VirtProductName} (Technology Preview)
-For {hcp} on {VirtProductName}, you can attach one or more NVIDIA graphics processing unit (GPU) devices to node pools. This feature is available as a Technology Preview feature. For more information, see xref:../hosted_control_planes/hcp-manage/hcp-manage-virt.adoc#hcp-virt-attach-nvidia-gpus_hcp-manage-virt[Attaching NVIDIA GPU devices by using the hcp CLI] and xref:../hosted_control_planes/hcp-manage/hcp-manage-virt.adoc#hcp-virt-attach-nvidia-gpus-np-api_hcp-manage-virt[Attaching NVIDIA GPU devices by using the NodePool resource].
+The {product-title} documentation now highlights the differences between {hcp} and standalone {product-title}. For more information, see xref:../hosted_control_planes/index.adoc#hcp-ocp-differences_hcp-overview[Differences between {hcp} and {product-title}].
 
-[id="hcp-4-17-tenancy-aws_{context}"]
-==== Support for tenancy on {aws-short}
-When you create a hosted cluster on {aws-short}, you can indicate whether the EC2 instance should run on shared or single-tenant hardware. For more information, see xref:../hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc#hcp-aws-deploy-hc_hcp-deploy-aws[Creating a hosted cluster on {aws-short}].
+[id="hcp-4-18-proxy_{context}"]
+==== Proxy configuration for {hcp}
 
-[id="hcp-4-17-ocp-version-support_{context}"]
-==== Support for {product-title} versions in hosted clusters
-You can deploy a range of supported {product-title} versions in a hosted cluster. For more information, see xref:../hosted_control_planes/hcp-updating.adoc#hcp-supported-ocp-versions_hcp-updating[Supported {product-title} versions in a hosted cluster].
+Configuring proxy support for {hcp} has a few differences from configuring proxy support for standalone {product-title}. For more information, see xref:../hosted_control_planes/hcp-networking.adoc[Networking for {hcp}].
 
-[id="hcp-4-17-virt-dc_{context}"]
-==== {hcp-capital} on {VirtProductName} in a disconnected environment is Generally Available
-In this release, {hcp} on {VirtProductName} in a disconnected environment is Generally Available. For more information, see xref:../hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc[Deploying {hcp} on {VirtProductName} in a disconnected environment].
+[id="hcp-4-18-runc-crun_{context}"]
+==== Default container runtime for worker nodes is crun
 
-[id="hcp-4-17-multi_{context}"]
-==== {hcp-capital} for an ARM64 {product-title} cluster on {aws-short} is Generally Available
-In this release, {hcp} for an ARM64 {product-title} cluster on {aws-short} is Generally Available. For more information, see xref:../hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc#hcp-enable-arm-amd_hcp-deploy-aws[Running hosted clusters on an ARM64 architecture].
+In {hcp} for {product-title} 4.18 or later, the default container runtime for worker nodes is changed from runC to crun.
 
-[id="hcp-4-17-ibm-z-ga_{context}"]
-==== {hcp-capital} on {ibm-z-title} is Generally Available
-In this release, {hcp} on {ibm-z-title} is Generally Available. For more information, see xref:../hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc[Deploying {hcp} on {ibm-z-title}].
-
-[id="hcp-4-17-ibm-power-ga_{context}"]
-==== {hcp-capital} on {ibm-power-title} is Generally Available
-In this release, {hcp} on {ibm-power-title} is Generally Available. For more information, see xref:../hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc[Deploying {hcp} on {ibm-power-title}].
-
-[id="bug-fixes-hcp-rn-4-17_{context}"]
+[id="bug-fixes-hcp-rn-4-18_{context}"]
 === Bug fixes
 
-* Previously, when a hosted cluster proxy was configured and it used an identity provider (IDP) that had an HTTP or HTTPS endpoint, the hostname of the IDP was unresolved before sending it through the proxy. Consequently, hostnames that could only be resolved by the data plane failed to resolve for IDPs. With this update, a DNS lookup is performed before sending IPD traffic through the `konnectivity` tunnel. As a result, IDPs with hostnames that can only be resolved by the data plane can be verified by the Control Plane Operator. (link:https://issues.redhat.com/browse/OCPBUGS-41371[*OCPBUGS-41371*])
-
-* Previously, when the hosted cluster `controllerAvailabilityPolicy` was set to `SingleReplica`, `podAntiAffinity` on networking components blocked the availability of the components. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39313[*OCPBUGS-39313*])
-
-* Previously, the `AdditionalTrustedCA` that was specified in the hosted cluster image configuration was not reconciled into the `openshift-config` namespace, as expected by the `image-registry-operator`, and the component did not become available. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39225[*OCPBUGS-39225*])
+* Previously, you could not create node pools that use ARM64 architecture on a {hcp} cluster with the platform parameter set to either `agentBareMetal` or `none`. This issue did not exist for a {hcp} cluster that runs on an {aws-short} or an {azure-full} platform. With this release, a fix ensures that you can now create node pools that use ARM64 architecture in a {hcp} cluster that has `platform` set to either `agentBareMetal` or `none`. (link:https://issues.redhat.com/browse/OCPBUGS-48579[*OCPBUGS-48579*])
 
-* Previously, Red{nbsp}Hat HyperShift periodic conformance jobs failed because of changes to the core operating system. These failed jobs caused the OpenShift API deployment to fail. With this release, an update recursively copies individual trusted certificate authority (CA) certificates instead of copying a single file, so that the periodic conformance jobs succeed and the OpenShift API runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-38941[*OCPBUGS-38941*])
+* Previously, when you attempted to use the {hcp} CLI to create a cluster in a disconnected environment, the installation command failed. An issue existed with the registry that hosts the command. With this release, a fix to the command registry means that you can use the {hcp} CLI to create a cluster in a disconnected environment. (link:https://issues.redhat.com/browse/OCPBUGS-48170[*OCPBUGS-48170*])
 
-* Previously, the Konnectivity proxy agent in a hosted cluster always sent all TCP traffic through an HTTP/S proxy. It also ignored host names in the `NO_PROXY` configuration because it only received resolved IP addresses in its traffic. As a consequence, traffic that was not meant to be proxied, such as LDAP traffic, was proxied regardless of configuration. With this release, proxying is completed at the source (control plane) and the Konnectivity agent proxying configuration is removed. As a result, traffic that is not meant to be proxied, such as LDAP traffic, is not proxied anymore. The `NO_PROXY` configuration that includes host names is honored. (link:https://issues.redhat.com/browse/OCPBUGS-38637[*OCPBUGS-38637*])
+* Previously, incorrect addresses were being passed to the Kubernetes EndpointSlice on a cluster, and this issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modifies the address evaluation method. Red{nbsp}Hat Marketplace pods can now successfully connect to the cluster API server, so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (link:https://issues.redhat.com/browse/OCPBUGS-46665[*OCPBUGS-46665*])
 
-* Previously, the `azure-disk-csi-driver-controller` image was not getting appropriate override values when using `registryOverride`. This was intentional so as to avoid propagating the values to the `azure-disk-csi-driver` data plane images. With this update, the issue is resolved by adding a separate image override value. As a result, the `azure-disk-csi-driver-controller` can be used with `registryOverride` and no longer affects `azure-disk-csi-driver` data plane images. (link:https://issues.redhat.com/browse/OCPBUGS-38183[*OCPBUGS-38183*])
+* Previously, in {hcp} on the Agent platform, ARM64 architecture was not allowed in the `NodePool` API. As a consequence, heterogeneous clusters could not be deployed on the Agent platform. In this release, the API now allows ARM64 architecture node pools on the Agent platform. (link:https://issues.redhat.com/browse/OCPBUGS-46373[*OCPBUGS-4673*])
 
-* Previously, the {aws-short} cloud controller manager within a hosted control plane that was running on a proxied management cluster would not use the proxy for cloud API communication. With this release, the issue is fixed. (link:https://issues.redhat.com/browse/OCPBUGS-37832[*OCPBUGS-37832*])
-
-* Previously, proxying for Operators that run in the control plane of a hosted cluster was performed through proxy settings on the Konnectivity agent pod that runs in the data plane. It was not possible to distinguish if proxying was needed based on application protocol.
-+
-For parity with {product-title}, IDP communication via HTTPS or HTTP should be proxied, but LDAP communication should not be proxied. This type of proxying also ignores `NO_PROXY` entries that rely on host names because by the time traffic reaches the Konnectivity agent, only the destination IP address is available.
-+
-With this release, in hosted clusters, proxy is invoked in the control plane through `konnectivity-https-proxy` and `konnectivity-socks5-proxy`, and proxying traffic is stopped from the Konnectivity agent. As a result, traffic that is destined for LDAP servers is no longer proxied. Other HTTPS or HTTPS traffic is proxied correctly. The `NO_PROXY` setting is honored when you specify hostnames. (link:https://issues.redhat.com/browse/OCPBUGS-37052[*OCPBUGS-37052*])
+* Previously, the default `node-monitor-grace-period` value was 50 seconds. As a consequence, nodes did not stay ready for the duration of time that Kubernetes components needed to reconnect, coordinate, and complete their requests. With this release, the default `node-monitor-grace-period` value is 55 seconds. As a result, the issue is resolved and deployments have enough time to be completed. (link:https://issues.redhat.com/browse/OCPBUGS-46008[*OCPBUGS-46008*])
 
-* Previously, proxying for IDP communication occurred in the Konnectivity agent. By the time traffic reached Konnectivity, its protocol and hostname were no longer available. As a consequence, proxying was not done correctly for the OAUTH server pod. It did not distinguish between protocols that require proxying (`http/s`) and protocols that do not (`ldap://`). In addition, it did not honor the `no_proxy` variable that is configured in the `HostedCluster.spec.configuration.proxy` spec.
-+
-With this release, you can configure the proxy on the Konnectivity sidecar of the OAUTH server so that traffic is routed appropriately, honoring your `no_proxy` settings. As a result, the OAUTH server can communicate properly with identity providers when a proxy is configured for the hosted cluster. (link:https://issues.redhat.com/browse/OCPBUGS-36932[*OCPBUGS-36932*])
+* Previously, the provider ID for the `IBMPowerVSMachine` object was not populated properly, due to the improper retrieval of IBM Cloud Workspace ID. As a consequence, any certificate signing requests (CSRs) were pending in hosted clusters. With this release, the provider ID is properly populated for the `IBMPowerVSMachine` object. As a result, no CSRs are pending, and all COs are moved to the available state. (link:https://issues.redhat.com/browse/OCPBUGS-44944[*OCPBUGS-44944*])
 
-* Previously, the Hosted Cluster Config Operator (HCCO) did not delete the `ImageDigestMirrorSet` CR (IDMS) after you removed the `ImageContentSources` field from the `HostedCluster` object. As a consequence, the IDMS persisted in the `HostedCluster` object when it should not. With this release, the HCCO manages the deletion of IDMS resources from the `HostedCluster` object. (link:https://issues.redhat.com/browse/OCPBUGS-34820[*OCPBUGS-34820*])
+* Previously, when you created a hosted cluster by using a shared VPC where the private DNS hosted zones existed in the cluster creator account, the private link controller failed to create the route53 DNS records in the local zone. With this release, the ingress shared role adds records to the private link controller. The VPC endpoint is used to share the role to create the VPC endpoint in the VPC owner account. A hosted cluster is created in a shared VPC configuration, where the private hosted zones exist in the cluster creator account. (link:https://issues.redhat.com/browse/OCPBUGS-44630[*OCPBUGS-44630*])
 
-* Previously, deploying a `hostedCluster` in a disconnected environment required setting the `hypershift.openshift.io/control-plane-operator-image` annotation. With this update, the annotation is no longer needed. Additionally, the metadata inspector works as expected during the hosted Operator reconciliation, and `OverrideImages` is populated as expected. (link:https://issues.redhat.com/browse/OCPBUGS-34734[*OCPBUGS-34734*])
+* Previously, when the hosted cluster `controllerAvailabilityPolicy` parameter was set to `SingleReplica`, the `podAntiAffinity` rules on networking components blocked the availability of the components. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39313[*OCPBUGS-39313*])
 
-* Previously, hosted clusters on {aws-short} leveraged their VPC's primary CIDR range to generate security group rules on the data plane. As a consequence, if you installed a hosted cluster into an AWS VPC with multiple CIDR ranges, the generated security group rules could be insufficient. With this update, security group rules are generated based on the provided machine CIDR range to resolve this issue. (link:https://issues.redhat.com/browse/OCPBUGS-34274[*OCPBUGS-34274*])
+* Previously, periodic conformance jobs in {hcp} failed because of changes to the core operating system. These failed jobs caused the OpenShift API deployment to fail. With this release, an update recursively copies individual trusted certificate authority (CA) certificates instead of copying a single file, so that the periodic conformance jobs succeed and the OpenShift API runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-38943[*OCPBUGS-38943*])
 
-* Previously, the {cluster-manager} container did not have the right TLS certificates. As a consequence, you could not use image streams in disconnected deployments. With this release, the TLS certificates are added as projected volumes to resolve this issue. (link:https://issues.redhat.com/browse/OCPBUGS-31446[*OCPBUGS-31446*])
+* Previously, you could not create `NodePool` resources with ARM64 architecture on non-AWS or {azure-short} platforms. This bug resulted in validation errors that prevented the addition of bare-metal compute nodes and caused CEL validation blocks when creating a `NodePool` resource. The fix modifies the `NodePool` spec validation rules by adding `"self.platform.type == 'None'"`. As a result, you can now create `NodePool` resources with ARM64 architecture specifications on non-AWS or {azure-short} bare-metal platforms, expanding functionality. (link:https://issues.redhat.com/browse/OCPBUGS-46440[*OCPBUGS-46440*])
 
-* Previously, the bulk destroy option in the {mce} console for {VirtProductName} did not destroy a hosted cluster. With this release, this issue is resolved. (link:https://issues.redhat.com/browse/ACM-10165[*ACM-10165*])
+* Previously, when you created a hosted cluster in a shared VPC, the private link controller sometimes failed to assume the shared VPC role to manage the VPC endpoints in the shared VPC. With this release, a client is created for every reconciliation in the private link controller so that you can recover from invalid clients. As a result, the hosted cluster endpoints and the hosted cluster are created successfully. (link:https://issues.redhat.com/browse/OCPBUGS-45184[*OCPBUGS-45184*])
 
-[id="known-issues-hcp-rn-4-17_{context}"]
+[id="known-issues-hcp-rn-4-18_{context}"]
 === Known issues
 
 * If the annotation and the `ManagedCluster` resource name do not match, the {mce} console displays the cluster as `Pending import`. The cluster cannot be used by the {mce-short}. The same issue happens when there is no annotation and the `ManagedCluster` name does not match the `Infra-ID` value of the `HostedCluster` resource.
@@ -97,7 +68,7 @@ With this release, you can configure the proxy on the Konnectivity sidecar of th
 * When a node pool is scaled down to 0 workers, the list of hosts in the console still shows nodes in a `Ready` state. You can verify the number of nodes in two ways:
 
 ** In the console, go to the node pool and verify that it has 0 nodes.
-** On the command-rline interface, run the following commands:
+** On the command-line interface, run the following commands:
 
 *** Verify that 0 nodes are in the node pool by running the following command:
 +
@@ -123,7 +94,7 @@ $ oc get agents -A
 * When you create a hosted cluster in an environment that uses the dual-stack network, you might encounter the following DNS-related issues:
 
 ** `CrashLoopBackOff` state in the `service-ca-operator` pod: When the pod tries to reach the Kubernetes API server through the hosted control plane, the pod cannot reach the server because the data plane proxy in the `kube-system` namespace cannot resolve the request. This issue occurs because in the HAProxy setup, the front end uses an IP address and the back end uses a DNS name that the pod cannot resolve.
-** Pods stuck in `ContainerCreating` state: This issue occurs because the `openshift-service-ca-operator` cannot generate the `metrics-tls` secret that the DNS pods need for DNS resolution. As a result, the pods cannot resolve the Kubernetes API server.
+** Pods stuck in the `ContainerCreating` state: This issue occurs because the `openshift-service-ca-operator` resource cannot generate the `metrics-tls` secret that the DNS pods need for DNS resolution. As a result, the pods cannot resolve the Kubernetes API server.
 To resolve these issues, configure the DNS server settings for a dual stack network.
 
 * On the Agent platform, the {hcp} feature periodically rotates the token that the Agent uses to pull ignition. As a result, if you have an Agent resource that was created some time ago, it might fail to pull ignition. As a workaround, in the Agent specification, delete the secret of the `IgnitionEndpointTokenReference` property then add or modify any label on the Agent resource. The system re-creates the secret with the new token.
@@ -133,27 +104,27 @@ To resolve these issues, configure the DNS server settings for a dual stack netw
 ** You created a hosted cluster on the Agent platform through the {mce} console by using the default hosted cluster cluster namespace.
 ** You created a hosted cluster through the command-line interface or API by specifying the hosted cluster namespace to be the same as the hosted cluster name.
 
+* When you use the console or API to specify an IPv6 address for the `spec.services.servicePublishingStrategy.nodePort.address` field of a hosted cluster, a full IPv6 address with 8 hextets is required. For example, instead of specifying `2620:52:0:1306::30`, you need to specify `2620:52:0:1306:0:0:0:30`.
+
 [id="hcp-tech-preview-features_{context}"]
-=== Generally Available and Technology Preview features
+=== General Availability and Technology Preview features
 
-Features which are Generally Available (GA) are fully supported and are suitable for production use. Technology Preview (TP) features are experimental features and are not intended for production use. For more information about TP features, see the link:https://access.redhat.com/support/offerings/techpreview[Technology Preview scope of support on the Red Hat Customer Portal].
+Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. For more information about the scope of support for these features, see link:https://access.redhat.com/support/offerings/techpreview[Technology Preview Features Support Scope] on the Red{nbsp}Hat Customer Portal.
 
 [IMPORTANT]
 ====
 For {ibm-power-title} and {ibm-z-title}, you must run the control plane on machine types based on 64-bit x86 architecture, and node pools on {ibm-power-title} or {ibm-z-title}.
 ====
 
-See the following table to know about {hcp} GA and TP features:
-
 .{hcp-capital} GA and TP tracker
 [cols="4,1,1,1",options="header"]
 |===
-|Feature |4.15 |4.16 |4.17
+|Feature |4.16 |4.17 |4.18
 
 |{hcp-capital} for {product-title} on {aws-first}
-|Technology Preview
-|Generally Available
-|Generally Available
+|General Availability
+|General Availability
+|General Availability
 
 |{hcp-capital} for {product-title} on bare metal
 |General Availability
@@ -161,9 +132,9 @@ See the following table to know about {hcp} GA and TP features:
 |General Availability
 
 |{hcp-capital} for {product-title} on {VirtProductName}
-|Generally Available
-|Generally Available
-|Generally Available
+|General Availability
+|General Availability
+|General Availability
 
 |{hcp-capital} for {product-title} using non-bare-metal agent machines
 |Technology Preview
@@ -172,21 +143,21 @@ See the following table to know about {hcp} GA and TP features:
 
 |{hcp-capital} for an ARM64 {product-title} cluster on {aws-full}
 |Technology Preview
-|Technology Preview
-|Generally Available
+|General Availability
+|General Availability
 
 |{hcp-capital} for {product-title} on {ibm-power-title}
 |Technology Preview
-|Technology Preview
-|Generally Available
+|General Availability
+|General Availability
 
 |{hcp-capital} for {product-title} on {ibm-z-title}
 |Technology Preview
-|Technology Preview
-|Generally Available
+|General Availability
+|General Availability
 
 |{hcp-capital} for {product-title} on {rh-openstack}
 |Not Available
-|Not Available
+|Developer Preview
 |Developer Preview
 |===
diff --git a/images/525-OpenShift-arch-012025.png b/images/525-OpenShift-arch-012025.png
new file mode 100644
index 000000000000..65f68d47470c
Binary files /dev/null and b/images/525-OpenShift-arch-012025.png differ
diff --git a/images/527-OpenShift-UDN-isolation-012025.png b/images/527-OpenShift-UDN-isolation-012025.png
new file mode 100644
index 000000000000..bad3320943bb
Binary files /dev/null and b/images/527-OpenShift-UDN-isolation-012025.png differ
diff --git a/images/528-OpenShift-multitenant-0225.png b/images/528-OpenShift-multitenant-0225.png
new file mode 100644
index 000000000000..c4585bdc1082
Binary files /dev/null and b/images/528-OpenShift-multitenant-0225.png differ
diff --git a/images/ROSA-HCP-overview-of-nodes-487.png b/images/ROSA-HCP-overview-of-nodes-487.png
new file mode 100644
index 000000000000..f3a26fdd80c4
Binary files /dev/null and b/images/ROSA-HCP-overview-of-nodes-487.png differ
diff --git a/images/coo-incident-alerts-components-expanded.png b/images/coo-incident-alerts-components-expanded.png
new file mode 100644
index 000000000000..03b766dd3740
Binary files /dev/null and b/images/coo-incident-alerts-components-expanded.png differ
diff --git a/images/coo-incident-alerts-components.png b/images/coo-incident-alerts-components.png
new file mode 100644
index 000000000000..5fd9344f7015
Binary files /dev/null and b/images/coo-incident-alerts-components.png differ
diff --git a/images/coo-incident-alerts-timeline.png b/images/coo-incident-alerts-timeline.png
new file mode 100644
index 000000000000..843640434977
Binary files /dev/null and b/images/coo-incident-alerts-timeline.png differ
diff --git a/images/coo-incidents-timeline-daily.png b/images/coo-incidents-timeline-daily.png
new file mode 100644
index 000000000000..dddaf5ac1097
Binary files /dev/null and b/images/coo-incidents-timeline-daily.png differ
diff --git a/images/coo-incidents-timeline-weekly.png b/images/coo-incidents-timeline-weekly.png
new file mode 100644
index 000000000000..9674f48936cb
Binary files /dev/null and b/images/coo-incidents-timeline-weekly.png differ
diff --git a/images/coo-incidents-timeline.png b/images/coo-incidents-timeline.png
new file mode 100644
index 000000000000..0b9d415533cf
Binary files /dev/null and b/images/coo-incidents-timeline.png differ
diff --git a/images/holdover_in_t_gm.png b/images/holdover_in_t_gm.png
new file mode 100644
index 000000000000..b34c703d8004
Binary files /dev/null and b/images/holdover_in_t_gm.png differ
diff --git a/images/monitoring-dashboard-administrator.png b/images/monitoring-dashboard-administrator.png
index 1138a2fc4722..51c618d8589f 100644
Binary files a/images/monitoring-dashboard-administrator.png and b/images/monitoring-dashboard-administrator.png differ
diff --git a/images/observe-dashboard-developer.png b/images/observe-dashboard-developer.png
index e1c840c667d8..ea73ec4b5e24 100644
Binary files a/images/observe-dashboard-developer.png and b/images/observe-dashboard-developer.png differ
diff --git a/images/ocp_arch.png b/images/ocp_arch.png
deleted file mode 100644
index 81fbaa13588f..000000000000
Binary files a/images/ocp_arch.png and /dev/null differ
diff --git a/images/openshift-telco-core-rds-metallb-service-separation.png b/images/openshift-telco-core-rds-metallb-service-separation.png
new file mode 100644
index 000000000000..cc7aa2bc38a8
Binary files /dev/null and b/images/openshift-telco-core-rds-metallb-service-separation.png differ
diff --git a/images/openshift-telco-core-rds-networking.png b/images/openshift-telco-core-rds-networking.png
new file mode 100644
index 000000000000..c01e38f34898
Binary files /dev/null and b/images/openshift-telco-core-rds-networking.png differ
diff --git a/images/telco-ran-du-reference-design-components.png b/images/telco-ran-du-reference-design-components.png
new file mode 100644
index 000000000000..bc0548147f0a
Binary files /dev/null and b/images/telco-ran-du-reference-design-components.png differ
diff --git a/index-commercial.html b/index-commercial.html
index 9e350400ca58..eb426a47ca09 100644
--- a/index-commercial.html
+++ b/index-commercial.html
@@ -138,7 +138,7 @@ <h3>Technology Topics</h3>
 </nav>
 <div id="banner" style="width: 100%; background-color: #fff4cc; padding: 1rem; text-align: center; z-index: 1000;">
   <p>
-    <strong>OpenShift docs are moving and will soon only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>, the home of all Red Hat product documentation. Explore the <a href="https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/index" style="color: #0C5460 !important" class="link-primary">new docs experience</a> today.
+    <strong>Starting on March 12, 2025, OpenShift docs will only be available at <a href="https://docs.redhat.com/en/" style="color: #0C5460 !important" class="link-primary">docs.redhat.com</a>. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
     </strong>
   </p>
 </div>
@@ -179,6 +179,7 @@ <h2>OpenShift Container Platform</h2>
               <div class="btn-group">
                 <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">Select Version<span class="caret"></span></button>
                 <ul class="dropdown-menu" role="menu">
+                  <li><a href="container-platform/4.18/"><i class="fa fa-arrow-circle-o-right"></i> Container Platform 4.18</a></li>
                   <li><a href="container-platform/4.17/"><i class="fa fa-arrow-circle-o-right"></i> Container Platform 4.17</a></li>
                   <li><a href="container-platform/4.16/"><i class="fa fa-arrow-circle-o-right"></i> Container Platform 4.16</a></li>
                   <li><a href="container-platform/4.15/"><i class="fa fa-arrow-circle-o-right"></i> Container Platform 4.15</a></li>
@@ -216,7 +217,6 @@ <h2>OpenShift Dedicated</h2>
             <div class="list-group">
               <p class="list-group-item-text">Red Hat's managed public cloud application deployment and hosting service.</p>
               <p><a role="button" class="btn btn-primary" href="dedicated/4/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> Dedicated 4</a></p>
-              <p><a role="button" class="btn btn-primary" href="dedicated/3/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> Dedicated 3</a></p>
               <p><a role="button" class="btn btn-primary" href="https://access.redhat.com/documentation/ja-jp/openshift_dedicated/4/"><i class="fa fa-arrow-circle-o-right"></i> Dedicated 4 日本語翻訳</a></p>
 
             </div>
@@ -251,6 +251,7 @@ <h2>Red Hat Advanced Cluster Security for Kubernetes</h2>
               <div class="btn-group">
                 <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">Select version<span class="caret"></span></button>
                 <ul class="dropdown-menu" role="menu">
+                  <li><a href="acs/4.7/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> RHACS 4.7</a></li>
                   <li><a href="acs/4.6/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> RHACS 4.6</a></li>
                   <li><a href="acs/4.5/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> RHACS 4.5</a></li>
                   <li><a href="acs/4.4/welcome/index.html"><i class="fa fa-arrow-circle-o-right"></i> RHACS 4.4</a></li>
@@ -276,7 +277,7 @@ <h2>Red Hat Advanced Cluster Security for Kubernetes</h2>
             <h2>OpenShift Kubernetes Engine</h2>
           <div class="list-group">
             <p class="list-group-item-text">The OpenShift Kubernetes Engine is the core of the OpenShift Container Platform. Use OpenShift Container Platform docs links for OpenShift Kubernetes Engine documentation.</p>
-            Read more about <a href="/container-platform/4.17/welcome/oke_about.html">OKE</a>.
+            Read more about <a href="/container-platform/4.18/welcome/oke_about.html">OKE</a>.
           </div>
           </div>
         </div>
@@ -289,6 +290,7 @@ <h2>OpenShift Container Platform <font size="-1">(日本語翻訳)</font></h2>
             <div class="btn-group">
               <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">バージョンを選択する<span class="caret"></span></button>
               <ul class="dropdown-menu" role="menu">
+                <li><a href="https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.18/"><i class="fa fa-arrow-circle-o-right"></i> 4.18</a></li>
                 <li><a href="https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.17/"><i class="fa fa-arrow-circle-o-right"></i> 4.17</a></li>
                 <li><a href="https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.16/"><i class="fa fa-arrow-circle-o-right"></i> 4.16</a></li>
                 <li><a href="https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.15/"><i class="fa fa-arrow-circle-o-right"></i> 4.15</a></li>
@@ -314,6 +316,7 @@ <h2>OpenShift Container Platform <font size="-1">(中文文档)</font></h2>
             <div class="btn-group">
               <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">选择版本<span class="caret"></span></button>
               <ul class="dropdown-menu" role="menu">
+                <li><a href="https://access.redhat.com/documentation/zh-cn/openshift_container_platform/4.18/"><i class="fa fa-arrow-circle-o-right"></i> 4.18</a></li>
                 <li><a href="https://access.redhat.com/documentation/zh-cn/openshift_container_platform/4.17/"><i class="fa fa-arrow-circle-o-right"></i> 4.17</a></li>
                 <li><a href="https://access.redhat.com/documentation/zh-cn/openshift_container_platform/4.16/"><i class="fa fa-arrow-circle-o-right"></i> 4.16</a></li>
                 <li><a href="https://access.redhat.com/documentation/zh-cn/openshift_container_platform/4.15/"><i class="fa fa-arrow-circle-o-right"></i> 4.15</a></li>
@@ -339,6 +342,7 @@ <h2>OpenShift Container Platform <font size="-1">(한국어 문서)</font></h2>
             <div class="btn-group">
               <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">버전 선택<span class="caret"></span></button>
               <ul class="dropdown-menu" role="menu">
+                <li><a href="https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.18/"><i class="fa fa-arrow-circle-o-right"></i> 4.18</a></li>
                 <li><a href="https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.17/"><i class="fa fa-arrow-circle-o-right"></i> 4.17</a></li>
                 <li><a href="https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.16/"><i class="fa fa-arrow-circle-o-right"></i> 4.16</a></li>
                 <li><a href="https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.15/"><i class="fa fa-arrow-circle-o-right"></i> 4.15</a></li>
diff --git a/index-community.html b/index-community.html
index 23952c8f24bd..6d9241be3a3d 100644
--- a/index-community.html
+++ b/index-community.html
@@ -51,6 +51,7 @@ <h1 class="cover-heading">Documentation</h1>
              <button type="button" class="btn btn-primary dropdown-toggle" data-toggle="dropdown" aria-expanded="false">Select Version<span class="caret"></span></button>
              <ul class="dropdown-menu" role="menu">
                <li><a href="latest/"><i class="fa fa-arrow-circle-o-right"></i> OKD Latest</a></li>
+               <li><a href="4.18/"><i class="fa fa-arrow-circle-o-right"></i> OKD 4.18</a></li>
                <li><a href="4.17/"><i class="fa fa-arrow-circle-o-right"></i> OKD 4.17</a></li>
                <li><a href="4.16/"><i class="fa fa-arrow-circle-o-right"></i> OKD 4.16</a></li>
                <li><a href="4.15/"><i class="fa fa-arrow-circle-o-right"></i> OKD 4.15</a></li>
diff --git a/installing/installing_aws/ipi/installing-restricted-networks-aws-installer-provisioned.adoc b/installing/installing_aws/ipi/installing-restricted-networks-aws-installer-provisioned.adoc
index 5b705509c4e7..6f8da5e08b92 100644
--- a/installing/installing_aws/ipi/installing-restricted-networks-aws-installer-provisioned.adoc
+++ b/installing/installing_aws/ipi/installing-restricted-networks-aws-installer-provisioned.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-aws-installer-provisioned"]
-= Installing a cluster on AWS in a restricted network
+= Installing a cluster on AWS in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-aws-installer-provisioned
 
diff --git a/installing/installing_aws/upi/installing-restricted-networks-aws.adoc b/installing/installing_aws/upi/installing-restricted-networks-aws.adoc
index 0245676cfd13..4009d44fe27a 100644
--- a/installing/installing_aws/upi/installing-restricted-networks-aws.adoc
+++ b/installing/installing_aws/upi/installing-restricted-networks-aws.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-aws"]
-= Installing a cluster on AWS in a restricted network with user-provisioned infrastructure
+= Installing a cluster on AWS in a disconnected environment with user-provisioned infrastructure
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-aws
 
diff --git a/installing/installing_azure/ipi/installing-restricted-networks-azure-installer-provisioned.adoc b/installing/installing_azure/ipi/installing-restricted-networks-azure-installer-provisioned.adoc
index 80340b5a3de9..e70cfcea25cc 100644
--- a/installing/installing_azure/ipi/installing-restricted-networks-azure-installer-provisioned.adoc
+++ b/installing/installing_azure/ipi/installing-restricted-networks-azure-installer-provisioned.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-azure-installer-provisioned"]
-= Installing a cluster on Azure in a restricted network
+= Installing a cluster on Azure in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-azure-installer-provisioned
 
diff --git a/installing/installing_azure/upi/installing-restricted-networks-azure-user-provisioned.adoc b/installing/installing_azure/upi/installing-restricted-networks-azure-user-provisioned.adoc
index b66124b73df9..5a19296ea39d 100644
--- a/installing/installing_azure/upi/installing-restricted-networks-azure-user-provisioned.adoc
+++ b/installing/installing_azure/upi/installing-restricted-networks-azure-user-provisioned.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-azure-user-provisioned"]
-= Installing a cluster on Azure in a restricted network with user-provisioned infrastructure
+= Installing a cluster on Azure in a disconnected environment with user-provisioned infrastructure
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-azure-user-provisioned
 
diff --git a/installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc b/installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
index 18d51da9c393..9f10a9f34ab2 100644
--- a/installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+++ b/installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
@@ -42,7 +42,9 @@ include::modules/bmo-about-the-hostfirmwaresettings-resource.adoc[leveloffset=+2
 // Getting the HostFirmwareSettings resource
 include::modules/bmo-getting-the-hostfirmwaresettings-resource.adoc[leveloffset=+2]
 // Editing the HostFirmwareSettings resource
-include::modules/bmo-editing-the-hostfirmwaresettings-resource.adoc[leveloffset=+2]
+include::modules/bmo-editing-the-hostfirmwaresettings-resource-of-a-provisioned-host.adoc[leveloffset=+2]
+// Patching the HostFirmawareSettings resource
+include::modules/bmo-performing-a-live-update-to-the-hostfirmwaresettings-resource.adoc[leveloffset=+2]
 // Verifying the HostFirmware Settings resource is valid
 include::modules/bmo-verifying-the-hostfirmware-settings-resource-is-valid.adoc[leveloffset=+2]
 // About the FirmwareSchema resource
@@ -54,4 +56,10 @@ include::modules/bmo-about-the-hostfirmwarecomponents-resource.adoc[leveloffset=
 // Getting the HostFirmwareComponents resource
 include::modules/bmo-getting-the-hostfirmwarecomponents-resource.adoc[leveloffset=+2]
 // Editing the HostFirmwareComponents resource
-include::modules/bmo-editing-the-hostfirmwarecomponents-resource.adoc[leveloffset=+2]
+include::modules/bmo-editing-the-hostfirmwarecomponents-resource-of-a-provisioned-host.adoc[leveloffset=+2]
+// Patching the HostFirmawareComponents resource
+include::modules/bmo-performing-a-live-update-to-the-hostfirmwarecomponents-resource.adoc[leveloffset=+2]
+// About the HostUpdatePolicy resource
+include::modules/bmo-about-the-hostupdatepolicy-resource.adoc[leveloffset=+2]
+// Setting the HostUpdatePolicy resource
+include::modules/bmo-setting-the-hostupdatepolicy-resource.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc b/installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
index 3d8a63eb3a0a..f02b62dbab59 100644
--- a/installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
+++ b/installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-bare-metal"]
-= Installing a user-provisioned bare metal cluster on a restricted network
+= Installing a user-provisioned bare metal cluster on a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-bare-metal
 
diff --git a/installing/installing_gcp/installing-gcp-shared-vpc.adoc b/installing/installing_gcp/installing-gcp-shared-vpc.adoc
index 50df232a42a7..6c5cd68e7b82 100644
--- a/installing/installing_gcp/installing-gcp-shared-vpc.adoc
+++ b/installing/installing_gcp/installing-gcp-shared-vpc.adoc
@@ -20,6 +20,7 @@ The installation program provisions the rest of the required infrastructure, whi
 * You have a GCP host project which contains a shared VPC network.
 * You xref:../../installing/installing_gcp/installing-gcp-account.adoc#installing-gcp-account[configured a GCP project] to host the cluster. This project, known as the service project, must be attached to the host project. For more information, see link:https://cloud.google.com/vpc/docs/provisioning-shared-vpc#create-shared[Attaching service projects in the GCP documentation].
 * You have a GCP service account that has the xref:../../installing/installing_gcp/installing-gcp-account.adoc#minimum-required-permissions-ipi-gcp-xpn_installing-gcp-account[required GCP permissions] in both the host and service projects.
+* If you want to provide your own private hosted zone, you must have created one in the service project with the DNS pattern `cluster-name.baseDomain.`, for example `testCluster.example.com.`. The private hosted zone must be bound to the VPC in the host project. For more information about cross-project binding, see link:https://cloud.google.com/dns/docs/zones/cross-project-binding[Create a zone with cross-project binding] (Google documentation). If you do not provide a private hosted zone, the installation program will provision one automatically.
 
 include::modules/cluster-entitlements.adoc[leveloffset=+1]
 
diff --git a/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc b/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc
index 21bb586f48d4..3f60e6d99ace 100644
--- a/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc
+++ b/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc
@@ -26,6 +26,7 @@ The steps for performing a user-provisioned infrastructure installation are prov
 * You read the documentation on xref:../../installing/overview/installing-preparing.adoc#installing-preparing[selecting a cluster installation method and preparing it for users].
 * If you use a firewall and plan to use the Telemetry service, you xref:../../installing/install_config/configuring-firewall.adoc#configuring-firewall[configured the firewall to allow the sites] that your cluster requires access to.
 * If the cloud identity and access management (IAM) APIs are not accessible in your environment, or if you do not want to store an administrator-level credential secret in the `kube-system` namespace, you can xref:../../installing/installing_gcp/installing-gcp-customizations.adoc#manually-create-iam_installing-gcp-customizations[manually create and maintain long-term credentials].
+* If you want to provide your own private hosted zone, you must have created one in the service project with the DNS pattern `cluster-name.baseDomain.`, for example `testCluster.example.com.`. The private hosted zone must be bound to the VPC in the host project. For more information about cross-project binding, see link:https://cloud.google.com/dns/docs/zones/cross-project-binding[Create a zone with cross-project binding] (Google documentation). If you do not provide a private hosted zone, the installation program will provision one automatically.
 +
 [NOTE]
 ====
diff --git a/installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc b/installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc
index cbe43df5c824..6db2f93cfa43 100644
--- a/installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc
+++ b/installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-gcp-installer-provisioned"]
-= Installing a cluster on GCP in a restricted network
+= Installing a cluster on GCP in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-gcp-installer-provisioned
 
diff --git a/installing/installing_gcp/installing-restricted-networks-gcp.adoc b/installing/installing_gcp/installing-restricted-networks-gcp.adoc
index 4bb4fab92349..8a5af09e146f 100644
--- a/installing/installing_gcp/installing-restricted-networks-gcp.adoc
+++ b/installing/installing_gcp/installing-restricted-networks-gcp.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-gcp"]
-= Installing a cluster on GCP in a restricted network with user-provisioned infrastructure
+= Installing a cluster on GCP in a disconnected environment with user-provisioned infrastructure
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-gcp
 
diff --git a/installing/installing_ibm_cloud/installing-ibm-cloud-restricted.adoc b/installing/installing_ibm_cloud/installing-ibm-cloud-restricted.adoc
index b541c163c67e..9e1b07f47ef4 100644
--- a/installing/installing_ibm_cloud/installing-ibm-cloud-restricted.adoc
+++ b/installing/installing_ibm_cloud/installing-ibm-cloud-restricted.adoc
@@ -1,7 +1,7 @@
 :_mod-docs-content-type: ASSEMBLY
 include::_attributes/common-attributes.adoc[]
 [id="installing-ibm-cloud-restricted"]
-= Installing a cluster on {ibm-cloud-title} in a restricted network
+= Installing a cluster on {ibm-cloud-title} in a disconnected environment
 :context: installing-ibm-cloud-restricted
 
 toc::[]
@@ -13,7 +13,7 @@ In {product-title} {product-version}, you can install a cluster in a restricted
 
 * You reviewed details about the xref:../../architecture/architecture-installation.adoc#architecture-installation[{product-title} installation and update] processes.
 * You xref:../../installing/installing_ibm_cloud/installing-ibm-cloud-account.adoc#installing-ibm-cloud-account[configured an {ibm-cloud-title} account] to host the cluster.
-* You have a container image registry that is accessible to the internet and your restricted network. The container image registry should mirror the contents of the {product-registry} and contain the installation media. For more information, see xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
+* You have a container image registry that is accessible to the internet and your restricted network. The container image registry should mirror the contents of the {product-registry} and contain the installation media. For more information, see xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2].
 * You have an existing VPC on {ibm-cloud-name} that meets the following requirements:
 ** The VPC contains the mirror registry or has firewall rules or a peering connection to access the mirror registry that is hosted elsewhere.
 ** The VPC can access {ibm-cloud-name} service endpoints using a public endpoint. If network restrictions limit access to public service endpoints, evaluate those services for alternate endpoints that might be available. For more information see xref:../../installing/installing_ibm_cloud/installing-ibm-cloud-restricted.adoc#access-to-ibm-service-endpoints_installing-ibm-cloud-restricted[Access to IBM service endpoints].
@@ -30,7 +30,7 @@ include::modules/installation-about-restricted-network.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]
 * xref:../../installing/installing_ibm_cloud/installation-config-parameters-ibm-cloud-vpc.adoc#installation-configuration-parameters-additional-ibm-cloud_installation-config-parameters-ibm-cloud-vpc[Additional {ibm-cloud-title} configuration parameters]
 
 include::modules/installation-custom-ibm-cloud-vpc.adoc[leveloffset=+1]
diff --git a/installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc b/installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc
index 30a89cc0ccd6..34ea5c60433a 100644
--- a/installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc
+++ b/installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc
@@ -1,7 +1,7 @@
 :_mod-docs-content-type: ASSEMBLY
 include::_attributes/common-attributes.adoc[]
 [id="installing-restricted-networks-ibm-power"]
-= Installing a cluster on {ibm-power-title} in a restricted network
+= Installing a cluster on {ibm-power-title} in a disconnected environment
 :context: installing-restricted-networks-ibm-power
 
 toc::[]
diff --git a/installing/installing_ibm_powervs/installing-restricted-networks-ibm-power-vs.adoc b/installing/installing_ibm_powervs/installing-restricted-networks-ibm-power-vs.adoc
index 33b55dd404fc..0bfaf222f10d 100644
--- a/installing/installing_ibm_powervs/installing-restricted-networks-ibm-power-vs.adoc
+++ b/installing/installing_ibm_powervs/installing-restricted-networks-ibm-power-vs.adoc
@@ -1,7 +1,7 @@
 :_mod-docs-content-type: ASSEMBLY
 include::_attributes/common-attributes.adoc[]
 [id="installing-restricted-networks-ibm-power-vs"]
-= Installing a cluster on {ibm-power-server-title} in a restricted network
+= Installing a cluster on {ibm-power-server-title} in a disconnected environment
 :context: installing-restricted-networks-ibm-power-vs
 
 toc::[]
diff --git a/installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc b/installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc
index 813ef5d88cef..b16c9f44ffaf 100644
--- a/installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc
+++ b/installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc
@@ -11,7 +11,7 @@ In {product-title} version {product-version}, you can choose one of the followin
 
 **Using installer-provisioned infrastructure**: Use the procedures in the following sections to use installer-provisioned infrastructure. Installer-provisioned infrastructure is ideal for installing in connected or disconnected network environments. The installer-provisioned infrastructure includes an installation program that provisions the underlying infrastructure for the cluster.
 
-**Using the Assisted Installer**: The link:https://access.redhat.com/documentation/en-us/assisted_installer_for_openshift_container_platform[{ai-full}] hosted at link:http://console.redhat.com[console.redhat.com]. The {ai-full} cannot be used in disconnected environments. The {ai-full} does not provision the underlying infrastructure for the cluster, so you must provision the infrastructure before the running the {ai-full}. Installing with the {ai-full} also provides integration with Nutanix, enabling autoscaling. See xref:../../installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc#installing-on-prem-assisted[Installing an on-premise cluster using the {ai-full}] for additional details.
+**Using the Assisted Installer**: The link:https://access.redhat.com/documentation/en-us/assisted_installer_for_openshift_container_platform[{ai-full}] hosted at link:http://console.redhat.com[console.redhat.com]. The {ai-full} cannot be used in disconnected environments. The {ai-full} does not provision the underlying infrastructure for the cluster, so you must provision the infrastructure before you run the {ai-full}. Installing with the {ai-full} also provides integration with Nutanix, enabling autoscaling. See xref:../../installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc#installing-on-prem-assisted[Installing an on-premise cluster using the {ai-full}] for additional details.
 
 **Using user-provisioned infrastructure**: Complete the relevant steps outlined in the xref:../../installing/installing_platform_agnostic/installing-platform-agnostic.adoc#installing-platform-agnostic[Installing a cluster on any platform] documentation.
 
diff --git a/installing/installing_nutanix/installing-restricted-networks-nutanix-installer-provisioned.adoc b/installing/installing_nutanix/installing-restricted-networks-nutanix-installer-provisioned.adoc
index fbbbdcc44215..f191ef388a3f 100644
--- a/installing/installing_nutanix/installing-restricted-networks-nutanix-installer-provisioned.adoc
+++ b/installing/installing_nutanix/installing-restricted-networks-nutanix-installer-provisioned.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-nutanix-installer-provisioned"]
-= Installing a cluster on Nutanix in a restricted network
+= Installing a cluster on Nutanix in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-nutanix-installer-provisioned
 
@@ -24,7 +24,7 @@ If your Nutanix environment uses an internal CA to issue certificates, you must
 Use 2048-bit certificates. The installation fails if you use 4096-bit certificates with Prism Central 2022.x.
 ====
 * You have a container image registry, such as Red Hat Quay. If you do not already have a registry, you can create a mirror registry using  xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#installing-mirroring-creating-registry[_mirror registry for Red Hat OpenShift_].
-* You have used the xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[oc-mirror OpenShift CLI (oc) plugin] to mirror all of the required {product-title} content and other images, including the Nutanix CSI Operator, to your mirror registry.
+* You have used the xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[oc-mirror OpenShift CLI (oc) plugin] to mirror all of the required {product-title} content and other images, including the Nutanix CSI Operator, to your mirror registry.
 +
 [IMPORTANT]
 ====
@@ -60,6 +60,12 @@ Complete the following steps to complete the configuration of your cluster.
 
 include::modules/olm-restricted-networks-configuring-operatorhub.adoc[leveloffset=+2]
 include::modules/oc-mirror-updating-restricted-cluster-manifests.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../extensions/catalogs/managing-catalogs.adoc#olmv1-adding-a-catalog-to-a-cluster_managing-catalogs[Adding a catalog to a cluster] in "Extensions"
+
 include::modules/registry-configuring-storage-nutanix.adoc[leveloffset=+2]
 
 include::modules/cluster-telemetry.adoc[leveloffset=+1]
diff --git a/installing/installing_oci/installing-c3-agent-based-installer.adoc b/installing/installing_oci/installing-c3-agent-based-installer.adoc
new file mode 100644
index 000000000000..efb3c423a6bf
--- /dev/null
+++ b/installing/installing_oci/installing-c3-agent-based-installer.adoc
@@ -0,0 +1,64 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="installing-c3-agent-based-installer"]
+= Installing a cluster on {oci-c3-no-rt} by using the Agent-based Installer
+:context: installing-c3-agent-based-installer
+
+toc::[]
+
+You can use the Agent-based Installer to install a cluster on {oci-c3}, so that you can run cluster workloads on on-premise infrastructure while still using {oci-first} services.
+
+[id="abi-oci-c3-process-checklist_{context}"]
+== Installation process workflow
+
+The following workflow describes a high-level outline for the process of installing an {product-title} cluster on {oci-c3-short} using the Agent-based Installer:
+
+. Create {oci-c3-short} resources and services (Oracle).
+. Prepare configuration files for the Agent-based Installer (Red{nbsp}Hat).
+. Generate the agent ISO image (Red{nbsp}Hat).
+. Convert the ISO image to an {oci-first-no-rt} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-c3-short} system (Oracle).
+. Disconnected environments: Prepare a web server that is accessible by {oci} instances (Red{nbsp}Hat).
+. Disconnected environments: Upload the rootfs image to the web server (Red{nbsp}Hat).
+. Configure your firewall for {product-title} (Red{nbsp}Hat).
+. Create control plane nodes and configure load balancers (Oracle).
+. Create compute nodes and configure load balancers (Oracle).
+. Verify that your cluster runs on {oci} (Oracle).
+
+// Creating Compute Cloud@Customer infrastructure resources and services
+include::modules/abi-c3-resources-services.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.oracle.com/en-us/iaas/Content/GSG/Concepts/concepts.htm[Learn About Oracle Cloud Basics (Oracle documentation)]
+
+// Creating configuration files for installing a cluster on Compute Cloud@Customer
+include::modules/creating-config-files-cluster-install-oci.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../architecture/architecture-installation.adoc#installation-overview_architecture-installation[About {product-title} installation]
+* xref:../../installing/overview/installing-preparing.adoc#installing-preparing-selecting-cluster-type[Selecting a cluster installation type]
+* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#preparing-to-install-with-agent-based-installer[Preparing to install with the Agent-based Installer]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-retrieve_installing-with-agent-based-installer[Downloading the Agent-based Installer]
+* xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#installing-mirroring-creating-registry[Creating a mirror registry with mirror registry for Red{nbsp}Hat OpenShift]
+* xref:../../disconnected/mirroring/installing-mirroring-installation-images.adoc#installation-mirror-repository_installing-mirroring-installation-images[Mirroring the {product-title} image repository]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-ztp_installing-with-agent-based-installer[Optional: Using ZTP manifests]
+
+// Configuring your firewall
+include::modules/configuring-firewall.adoc[leveloffset=+1]
+
+// Running your cluster on Compute Cloud@Customer
+include::modules/running-cluster-oci-c3-agent-based.adoc[leveloffset=+1]
+
+// Verifying that your Agent-based cluster installation runs on {oci}
+include::modules/verifying-cluster-install-oci-agent-based.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-gather-log_installing-with-agent-based-installer[Gathering log data from a failed Agent-based installation]
+
+* xref:../../nodes/nodes/nodes-nodes-adding-node-iso.adoc#adding-node-iso[Adding worker nodes to an on-premise cluster]
\ No newline at end of file
diff --git a/installing/installing_oci/installing-c3-assisted-installer.adoc b/installing/installing_oci/installing-c3-assisted-installer.adoc
new file mode 100644
index 000000000000..bb07983faef8
--- /dev/null
+++ b/installing/installing_oci/installing-c3-assisted-installer.adoc
@@ -0,0 +1,49 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="installing-c3-assisted-installer"]
+= Installing a cluster on {oci-c3-no-rt} by using the {ai-full}
+:context: installing-c3-assisted-installer
+
+toc::[]
+
+With {oci-c3} (C3), you can run applications and middleware by using {oci-first} services on high performance cloud infrastructure in your data center. 
+
+// Overview
+include::modules/c3-assisted-installer-overview.adoc[leveloffset=+1]
+
+// Preparing the Bastian server
+include::modules/c3-assisted-installer-preparing-bastion-server.adoc[leveloffset=+1]
+
+// Terraform script execution - part 1
+include::modules/c3-assisted-installer-running-script-via-home.adoc[leveloffset=+1]
+
+// Preparing the OpenShift image
+[id="c3-assisted-installer-preparing-image_{context}"]
+== Preparing the {oci} image 
+
+Generate the {product-title} ISO image in the {ai-full} on the Red{nbsp}Hat portal. Then, convert the image to an {oci-first-no-rt} compatible image and upload it to the *Custom Images* page of your {oci-c3-no-rt} environment. 
+
+You can generate, convert and upload the image on your laptop and not on the bastion server or within environments such as Oracle Solution Center. 
+
+include::modules/c3-assisted-installer-preparing-image-generating.adoc[leveloffset=+2]
+
+include::modules/c3-assisted-installer-preparing-image-converting.adoc[leveloffset=+2]
+
+// Terraform script execution - part 2
+include::modules/c3-assisted-installer-running-script-via-region.adoc[leveloffset=+1]
+
+// Completing the installation
+
+[id="c3-ai-completing-installation_{context}"]
+== Completing the installation by using the {ai-full} web console
+
+After you configure the infrastructure, the instances are now running and are ready to be registered with{nbsp}Red Hat. 
+
+include::modules/c3-assisted-installer-completing-installation-nodes.adoc[leveloffset=+2]
+
+include::modules/c3-assisted-installer-completing-installation-networking.adoc[leveloffset=+2]
+
+include::modules/c3-assisted-installer-completing-installation-manifests.adoc[leveloffset=+2]
+
+// Opening the cluster
+include::modules/c3-assisted-installer-opening-cluster.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/installing/installing_oci/installing-oci-agent-based-installer.adoc b/installing/installing_oci/installing-oci-agent-based-installer.adoc
index 357de9808d70..fa0a6bf8b0b8 100644
--- a/installing/installing_oci/installing-oci-agent-based-installer.adoc
+++ b/installing/installing_oci/installing-oci-agent-based-installer.adoc
@@ -10,6 +10,11 @@ In {product-title} {product-version}, you can use the Agent-based Installer to i
 
 Installing a cluster on {oci} is supported for virtual machines (VMs) and bare-metal machines.
 
+[NOTE]
+====
+You can deploy {product-title} on a link:https://www.oracle.com/uk/cloud/cloud-at-customer/dedicated-region/[Dedicated Region] (Oracle documentation) the same as any region from {oci-first-no-rt}.
+====
+
 // The Agent-based Installer and OCI overview
 include::modules/installing-oci-about-agent-based-installer.adoc[leveloffset=+1]
 
diff --git a/installing/installing_oci/installing-oci-assisted-installer.adoc b/installing/installing_oci/installing-oci-assisted-installer.adoc
index 0a20edd02542..d9747fea4d52 100644
--- a/installing/installing_oci/installing-oci-assisted-installer.adoc
+++ b/installing/installing_oci/installing-oci-assisted-installer.adoc
@@ -10,6 +10,11 @@ You can use the {ai-full} to install a cluster on {oci-first}. This method is re
 
 If you want to set up the cluster manually or using other automation tools, or if you are working in a disconnected environment, you can use the Red Hat Agent-based Installer for the installation. For details, see xref:../../installing/installing_oci/installing-oci-agent-based-installer.adoc#installing-oci-agent-based-installer[Installing a cluster on {oci-first-no-rt} by using the Agent-based Installer].
 
+[NOTE]
+====
+You can deploy {product-title} on a link:https://www.oracle.com/uk/cloud/cloud-at-customer/dedicated-region/[Dedicated Region] (Oracle documentation) the same as any region from {oci-first-no-rt}.
+====
+
 // The Assisted Installer and OCI overview
 include::modules/installing-oci-about-assisted-installer.adoc[leveloffset=+1]
 
@@ -27,12 +32,12 @@ include::modules/creating-oci-resources-services.adoc[leveloffset=+1]
 [id="using-assisted-installer-oci-agent-iso_{context}"]
 == Using the {ai-full} to generate an {oci}-compatible discovery ISO image
 
-Create the cluster configuration and generate the discovery ISO image in the {ai-full} web console. 
+Create the cluster configuration and generate the discovery ISO image in the {ai-full} web console.
 
 .Prerequisites
 
-* You created a child compartment and an object storage bucket on {oci}. For details, see _Preparing the {oci} environment_. 
-* You reviewed details about the {product-title} installation and update processes. 
+* You created a child compartment and an object storage bucket on {oci}. For details, see _Preparing the {oci} environment_.
+* You reviewed details about the {product-title} installation and update processes.
 
 include::modules/using-assisted-installer-oci-create-cluster.adoc[leveloffset=+2]
 
@@ -66,6 +71,10 @@ include::modules/complete-assisted-installer-oci-custom-manifests.adoc[leveloffs
 // Verifying a successful cluster installation on OCI
 include::modules/verifying-cluster-install-ai-oci.adoc[leveloffset=+1]
 
+// Adding hosts to the cluster following the installation
+include::modules/installing-oci-adding-hosts-day-two.adoc[leveloffset=+1]
+
+
 // Troubleshooting the installation of a cluster on OCI
 include::modules/installing-troubleshooting-assisted-installer-oci.adoc[leveloffset=+1]
 
diff --git a/installing/installing_oci/installing-pca-agent-based-installer.adoc b/installing/installing_oci/installing-pca-agent-based-installer.adoc
new file mode 100644
index 000000000000..88c12afe8c3b
--- /dev/null
+++ b/installing/installing_oci/installing-pca-agent-based-installer.adoc
@@ -0,0 +1,64 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="installing-pca-agent-based-installer"]
+= Installing a cluster on {oci-pca-no-rt} by using the Agent-based Installer
+:context: installing-pca-agent-based-installer
+
+toc::[]
+
+You can use the Agent-based Installer to install a cluster on {oci-pca}, so that you can run cluster workloads on on-premise infrastructure while still using {oci-first} services.
+
+[id="abi-oci-pca-process-checklist_{context}"]
+== Installation process workflow
+
+The following workflow describes a high-level outline for the process of installing an {product-title} cluster on {oci-pca-short} using the Agent-based Installer:
+
+. Create {oci-pca-short} resources and services (Oracle).
+. Prepare configuration files for the Agent-based Installer (Red{nbsp}Hat).
+. Generate the agent ISO image (Red{nbsp}Hat).
+. Convert the ISO image to an {oci-first-no-rt} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-pca-short} system (Oracle).
+. Disconnected environments: Prepare a web server that is accessible by {oci} instances (Red{nbsp}Hat).
+. Disconnected environments: Upload the rootfs image to the web server (Red{nbsp}Hat).
+. Configure your firewall for {product-title} (Red{nbsp}Hat).
+. Create control plane nodes and configure load balancers (Oracle).
+. Create compute nodes and configure load balancers (Oracle).
+. Verify that your cluster runs on {oci} (Oracle).
+
+// Creating Private Cloud Appliance infrastructure resources and services
+include::modules/abi-pca-resources-services.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.oracle.com/en-us/iaas/Content/GSG/Concepts/concepts.htm[Learn About Oracle Cloud Basics (Oracle documentation)]
+
+// Creating configuration files for installing a cluster on OCI
+include::modules/creating-config-files-cluster-install-oci.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../architecture/architecture-installation.adoc#installation-overview_architecture-installation[About {product-title} installation]
+* xref:../../installing/overview/installing-preparing.adoc#installing-preparing-selecting-cluster-type[Selecting a cluster installation type]
+* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#preparing-to-install-with-agent-based-installer[Preparing to install with the Agent-based Installer]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-retrieve_installing-with-agent-based-installer[Downloading the Agent-based Installer]
+* xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#installing-mirroring-creating-registry[Creating a mirror registry with mirror registry for Red{nbsp}Hat OpenShift]
+* xref:../../disconnected/mirroring/installing-mirroring-installation-images.adoc#installation-mirror-repository_installing-mirroring-installation-images[Mirroring the {product-title} image repository]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-ztp_installing-with-agent-based-installer[Optional: Using ZTP manifests]
+
+// Configuring your firewall
+include::modules/configuring-firewall.adoc[leveloffset=+1]
+
+// Running your cluster on Private Cloud Appliance
+include::modules/running-cluster-oci-pca-agent-based.adoc[leveloffset=+1]
+
+// Verifying that your Agent-based cluster installation runs on {oci}
+include::modules/verifying-cluster-install-oci-agent-based.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-gather-log_installing-with-agent-based-installer[Gathering log data from a failed Agent-based installation]
+
+* xref:../../nodes/nodes/nodes-nodes-adding-node-iso.adoc#adding-node-iso[Adding worker nodes to an on-premise cluster]
\ No newline at end of file
diff --git a/installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc b/installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc
index 62be05689c76..a81051b078c8 100644
--- a/installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc
+++ b/installing/installing_on_prem_assisted/installing-on-prem-assisted.adoc
@@ -1,8 +1,8 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="installing-on-prem-assisted"]
-= Installing an on-premise cluster using the {ai-full}
 include::_attributes/common-attributes.adoc[]
 :context: installing-on-prem-assisted
+[id="installing-on-prem-assisted"]
+= Installing an on-premise cluster using the {ai-full}
 
 toc::[]
 
diff --git a/installing/installing_openstack/installing-openstack-installer-custom.adoc b/installing/installing_openstack/installing-openstack-installer-custom.adoc
index de78454f63b7..e3f0948fa9da 100644
--- a/installing/installing_openstack/installing-openstack-installer-custom.adoc
+++ b/installing/installing_openstack/installing-openstack-installer-custom.adoc
@@ -55,6 +55,11 @@ include::modules/installation-osp-config-yaml.adoc[leveloffset=+2]
 //Dual-stack networking
 include::modules/install-osp-dualstack.adoc[leveloffset=+2]
 include::modules/install-osp-deploy-dualstack.adoc[leveloffset=+3]
+include::modules/installation-configuring-shiftstack-single-ipv6.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* See xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#installing-mirroring-creating-registry[Creating a mirror registry with mirror registry for Red Hat OpenShift]
 
 include::modules/installation-osp-external-lb-config.adoc[leveloffset=+2]
 // include::modules/installation-osp-setting-worker-affinity.adoc[leveloffset=+1]
diff --git a/installing/installing_openstack/installing-openstack-installer-restricted.adoc b/installing/installing_openstack/installing-openstack-installer-restricted.adoc
index 1dcb97f6f37d..c1f4cc9e3d68 100644
--- a/installing/installing_openstack/installing-openstack-installer-restricted.adoc
+++ b/installing/installing_openstack/installing-openstack-installer-restricted.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-openstack-installer-restricted"]
-= Installing a cluster on OpenStack in a restricted network
+= Installing a cluster on OpenStack in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-openstack-installer-restricted
 
diff --git a/installing/installing_openstack/installing-openstack-nfv-preparing.adoc b/installing/installing_openstack/installing-openstack-nfv-preparing.adoc
index a30dd5ae1878..4a8c27aed55b 100644
--- a/installing/installing_openstack/installing-openstack-nfv-preparing.adoc
+++ b/installing/installing_openstack/installing-openstack-nfv-preparing.adoc
@@ -44,6 +44,5 @@ After you perform preinstallation tasks, install your cluster by following the m
 ** xref:../../machine_management/creating_machinesets/creating-machineset-osp.adoc#machineset-yaml-osp-sr-iov_creating-machineset-osp[Create SR-IOV compute machines].
 * Consult the following references after you deploy your cluster to improve its performance:
 ** xref:../../networking/hardware_networks/using-dpdk-and-rdma.adoc#nw-openstack-ovs-dpdk-testpmd-pod_using-dpdk-and-rdma[A test pod template for clusters that use OVS-DPDK on OpenStack].
-** xref:../../networking/hardware_networks/add-pod.adoc#nw-openstack-sr-iov-testpmd-pod_add-pod[A test pod template for clusters that use SR-IOV on OpenStack].
-** xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#installation-openstack-ovs-dpdk-performance-profile_cnf-low-latency-perf-profile[A performance profile template for clusters that use OVS-DPDK on OpenStack]
-.
+** xref:../../networking/hardware_networks/configuring-sriov-device.adoc#nw-openstack-sr-iov-testpmd-pod_configuring-sriov-device[A test pod template for clusters that use SR-IOV on OpenStack].
+** xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#installation-openstack-ovs-dpdk-performance-profile_cnf-low-latency-perf-profile[A performance profile template for clusters that use OVS-DPDK on OpenStack]
diff --git a/installing/installing_vmc/installing-restricted-networks-vmc-user-infra.adoc b/installing/installing_vmc/installing-restricted-networks-vmc-user-infra.adoc
index 3ece0db425bd..e3690d826280 100644
--- a/installing/installing_vmc/installing-restricted-networks-vmc-user-infra.adoc
+++ b/installing/installing_vmc/installing-restricted-networks-vmc-user-infra.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-vmc-user-infra"]
-= Installing a cluster on VMC in a restricted network with user-provisioned infrastructure
+= Installing a cluster on VMC in a disconnected environment with user-provisioned infrastructure
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-vmc-user-infra
 
diff --git a/installing/installing_vsphere/installing-vsphere-agent-based-installer.adoc b/installing/installing_vsphere/installing-vsphere-agent-based-installer.adoc
index aa94e533e5c6..04ca9ac9d45e 100644
--- a/installing/installing_vsphere/installing-vsphere-agent-based-installer.adoc
+++ b/installing/installing_vsphere/installing-vsphere-agent-based-installer.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The Agent-based installation method provides the flexibility to boot your on-premises servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
+The Agent-based installation method provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
 
 Agent-based installation is a subcommand of the {product-title} installer. It generates a bootable ISO image containing all of the information required to deploy an {product-title} cluster with an available release image.
 
diff --git a/installing/installing_vsphere/ipi/installing-restricted-networks-installer-provisioned-vsphere.adoc b/installing/installing_vsphere/ipi/installing-restricted-networks-installer-provisioned-vsphere.adoc
index 92f3eb677de7..b44e913841c1 100644
--- a/installing/installing_vsphere/ipi/installing-restricted-networks-installer-provisioned-vsphere.adoc
+++ b/installing/installing_vsphere/ipi/installing-restricted-networks-installer-provisioned-vsphere.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-installer-provisioned-vsphere"]
-= Installing a cluster on vSphere in a restricted network
+= Installing a cluster on vSphere in a disconnected environment
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-installer-provisioned-vsphere
 
@@ -8,9 +8,6 @@ toc::[]
 
 In {product-title} {product-version}, you can install a cluster on VMware vSphere infrastructure in a restricted network by creating an internal mirror of the installation release content.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [id="prerequisites_installing-restricted-networks-installer-provisioned-vsphere"]
 == Prerequisites
 
diff --git a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-customizations.adoc b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-customizations.adoc
index 775b65c9420a..ae8e030400b8 100644
--- a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-customizations.adoc
+++ b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-customizations.adoc
@@ -10,9 +10,6 @@ toc::[]
 In {product-title} version {product-version}, you can install a cluster on your
 VMware vSphere instance by using installer-provisioned infrastructure. To customize the installation, you modify parameters in the `install-config.yaml` file before you install the cluster.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [id="prerequisites_installing-vsphere-installer-provisioned-customizations"]
 == Prerequisites
 
diff --git a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc
index baecaa816b18..e403cc378a8b 100644
--- a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc
+++ b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc
@@ -11,9 +11,6 @@ VMware vSphere instance by using installer-provisioned infrastructure with custo
 
 You must set most of the network configuration parameters during installation, and you can modify only `kubeProxy` configuration parameters in a running cluster.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [id="prerequisites_installing-vsphere-installer-provisioned-network-customizations"]
 == Prerequisites
 
@@ -61,6 +58,14 @@ include::modules/ipi-install-modifying-install-config-for-dual-stack-network.ado
 
 include::modules/configuring-vsphere-regions-zones.adoc[leveloffset=+2]
 
+// Specifying multiple NICS
+include::modules/installation-vsphere-multiple-nics.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../installing/installing_vsphere/installation-config-parameters-vsphere.adoc#installation-configuration-parameters-network_installation-config-parameters-vsphere[Network configuration parameters]
+
 // Network configuration phases
 include::modules/nw-network-config.adoc[leveloffset=+1]
 
diff --git a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned.adoc b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned.adoc
index 435cecd6a356..756bdc9c3855 100644
--- a/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned.adoc
+++ b/installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned.adoc
@@ -9,9 +9,6 @@ toc::[]
 In {product-title} version {product-version}, you can install a cluster on your
 VMware vSphere instance by using installer-provisioned infrastructure.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [id="prerequisites_installing-vsphere-installer-provisioned_{context}"]
 == Prerequisites
 
diff --git a/installing/installing_vsphere/preparing-to-install-on-vsphere.adoc b/installing/installing_vsphere/preparing-to-install-on-vsphere.adoc
index eb9b521c0c24..246bba9dfea3 100644
--- a/installing/installing_vsphere/preparing-to-install-on-vsphere.adoc
+++ b/installing/installing_vsphere/preparing-to-install-on-vsphere.adoc
@@ -16,7 +16,7 @@ You can install {product-title} with the link:https://access.redhat.com/document
 == Agent-based Installer
 
 You can install an {product-title} cluster on vSphere using the Agent-based Installer.
-The Agent-based Installer can be used to boot an on-premises server in a disconnected environment by using a bootable image.
+The Agent-based Installer can be used to boot an on-premise server in a disconnected environment by using a bootable image.
 With the Agent-based Installer, users also have the flexibility to provision infrastructure, customize network configurations, and customize installations within a disconnected environment.
 See xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#preparing-to-install-with-agent-based-installer[Preparing to install with the Agent-based Installer] for additional details.
 
diff --git a/installing/installing_vsphere/upi/installing-restricted-networks-vsphere.adoc b/installing/installing_vsphere/upi/installing-restricted-networks-vsphere.adoc
index 4d82cb156909..3dbfac17203b 100644
--- a/installing/installing_vsphere/upi/installing-restricted-networks-vsphere.adoc
+++ b/installing/installing_vsphere/upi/installing-restricted-networks-vsphere.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-restricted-networks-vsphere"]
-= Installing a cluster on vSphere in a restricted network with user-provisioned infrastructure
+= Installing a cluster on vSphere in a disconnected environment with user-provisioned infrastructure
 include::_attributes/common-attributes.adoc[]
 :context: installing-restricted-networks-vsphere
 
@@ -9,9 +9,6 @@ toc::[]
 In {product-title} version {product-version}, you can install a cluster on
 VMware vSphere infrastructure that you provision in a restricted network.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [IMPORTANT]
 ====
 The steps for performing a user-provisioned infrastructure installation are provided as an example only. Installing a cluster with infrastructure you provide requires knowledge of the vSphere platform and the installation process of {product-title}. Use the user-provisioned infrastructure installation instructions as a guide; you are free to create the required resources through other methods.
diff --git a/installing/installing_vsphere/upi/installing-vsphere-network-customizations.adoc b/installing/installing_vsphere/upi/installing-vsphere-network-customizations.adoc
index cc9517615d2b..27eda9d0dc60 100644
--- a/installing/installing_vsphere/upi/installing-vsphere-network-customizations.adoc
+++ b/installing/installing_vsphere/upi/installing-vsphere-network-customizations.adoc
@@ -12,9 +12,6 @@ configuration options. By customizing your network configuration, your cluster
 can coexist with existing IP address allocations in your environment and
 integrate with existing MTU and VXLAN configurations.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 You must set most of the network configuration parameters during installation,
 and you can modify only `kubeProxy` configuration parameters in a running
 cluster.
diff --git a/installing/installing_vsphere/upi/installing-vsphere.adoc b/installing/installing_vsphere/upi/installing-vsphere.adoc
index 725c1538321a..4b970468672f 100644
--- a/installing/installing_vsphere/upi/installing-vsphere.adoc
+++ b/installing/installing_vsphere/upi/installing-vsphere.adoc
@@ -10,9 +10,6 @@ toc::[]
 In {product-title} version {product-version}, you can install a cluster on
 VMware vSphere infrastructure that you provision.
 
-:FeatureName: Support for multiple vCenters
-include::snippets/technology-preview.adoc[]
-
 [IMPORTANT]
 ====
 The steps for performing a user-provisioned infrastructure installation are provided as an example only. Installing a cluster with infrastructure you provide requires knowledge of the vSphere platform and the installation process of {product-title}. Use the user-provisioned infrastructure installation instructions as a guide; you are free to create the required resources through other methods.
diff --git a/installing/installing_vsphere/using-vsphere-problem-detector-operator.adoc b/installing/installing_vsphere/using-vsphere-problem-detector-operator.adoc
index 0fe7525dfc97..5dd7ccc8fdfa 100644
--- a/installing/installing_vsphere/using-vsphere-problem-detector-operator.adoc
+++ b/installing/installing_vsphere/using-vsphere-problem-detector-operator.adoc
@@ -30,4 +30,4 @@ include::modules/vsphere-problem-detector-metrics.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+* xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
diff --git a/installing/installing_with_agent_based_installer/installing-using-iscsi.adoc b/installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
new file mode 100644
index 000000000000..988a90daa62a
--- /dev/null
+++ b/installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
@@ -0,0 +1,47 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="installing-using-iscsi"]
+= Preparing installation assets for iSCSI booting
+include::_attributes/common-attributes.adoc[]
+:context: installing-using-iscsi
+
+toc::[]
+
+You can boot an {product-title} cluster through Internet Small Computer System Interface (iSCSI) by using an ISO image generated by the Agent-based Installer.
+The following procedures describe how to prepare the necessary installation resources to boot from an iSCSI target.
+
+The assets you create in these procedures deploy a single-node {product-title} installation.
+You can use these procedures as a basis and modify configurations according to your requirements.
+
+// Downloading the Agent-based Installer
+include::modules/installing-ocp-agent-iscsi-requirements.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#agent-install-networking-DHCP_preparing-to-install-with-agent-based-installer[DHCP]
+* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#root-device-hints_preparing-to-install-with-agent-based-installer[About root device hints]
+
+[id="prerequisites_{context}"]
+== Prerequisites
+
+* You reviewed details about the xref:../../architecture/architecture-installation.adoc#architecture-installation[{product-title} installation and update] processes.
+* You read the documentation on xref:../../installing/overview/installing-preparing.adoc#installing-preparing[selecting a cluster installation method and preparing it for users].
+* If you use a firewall or proxy, you xref:../../installing/install_config/configuring-firewall.adoc#configuring-firewall[configured it to allow the sites] that your cluster requires access to.
+
+// Downloading the Agent-based Installer
+include::modules/installing-ocp-agent-download.adoc[leveloffset=+1]
+
+// Creating the preferred configuration inputs
+include::modules/installing-ocp-agent-inputs.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#modifying-install-config-for-dual-stack-network_ipi-install-installation-workflow[Deploying with dual-stack networking]
+* xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-the-install-config-file_ipi-install-installation-workflow[Configuring the install-config yaml file]
+* xref:../../installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc#installation-three-node-cluster_installing-restricted-networks-bare-metal[Configuring a three-node cluster]
+* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#root-device-hints_preparing-to-install-with-agent-based-installer[About root device hints]
+* link:https://nmstate.io/examples.html[NMState state examples] (NMState documentation)
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-ocp-agent-opt-manifests_installing-with-agent-based-installer[Optional: Creating additional manifest files]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#agent-install-verifying-architectures_installing-with-agent-based-installer[Verifying the supported architecture for an Agent-based installation]
+
+// Creating the installation files
+include::modules/installing-ocp-agent-iscsi-files.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc b/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
index c509670af643..09e137f152d9 100644
--- a/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
+++ b/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
@@ -1,23 +1,21 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-with-agent-based-installer"]
-= Installing an {product-title} cluster with the Agent-based Installer
+= Installing a cluster with customizations
 include::_attributes/common-attributes.adoc[]
 :context: installing-with-agent-based-installer
 
 toc::[]
 
-Use the following procedures to install an {product-title} cluster using the Agent-based Installer.
+Use the following procedures to install an {product-title} cluster with customizations using the Agent-based Installer.
 
-[id="prerequisites_installing-with-agent-based-installer_{context}"]
+[id="prerequisites_{context}"]
 == Prerequisites
 
 * You reviewed details about the xref:../../architecture/architecture-installation.adoc#architecture-installation[{product-title} installation and update] processes.
 * You read the documentation on xref:../../installing/overview/installing-preparing.adoc#installing-preparing[selecting a cluster installation method and preparing it for users].
 * If you use a firewall or proxy, you xref:../../installing/install_config/configuring-firewall.adoc#configuring-firewall[configured it to allow the sites] that your cluster requires access to.
 
-
-// This anchor ID is extracted/replicated from the former installing-ocp-agent.adoc module to preserve links.
-[id="installing-ocp-agent_installing-with-agent-based-installer_{context}"]
+[id="installing-ocp-agent_{context}"]
 == Installing {product-title} with the Agent-based Installer
 
 The following procedures deploy a single-node {product-title} in a disconnected environment. You can use these procedures as a basis and modify according to your requirements.
@@ -42,6 +40,11 @@ include::modules/installing-ocp-agent-inputs.adoc[leveloffset=+2]
 
 As an optional task, you can create additional manifests to further configure your cluster beyond the configurations available in the `install-config.yaml` and `agent-config.yaml` files.
 
+[IMPORTANT]
+====
+Customizations to the cluster made by additional manifests are not validated, are not guaranteed to work, and might result in a nonfunctional cluster.
+====
+
 // Creating a directory to contain additional manifests
 include::modules/installing-ocp-agent-manifest-folder.adoc[leveloffset=+3]
 
@@ -85,7 +88,7 @@ include::modules/installing-ocp-agent-verify.adoc[leveloffset=+2]
 .Additional resources
 * See xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#modifying-install-config-for-dual-stack-network_ipi-install-installation-workflow[Deploying with dual-stack networking].
 * See xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-the-install-config-file_ipi-install-installation-workflow[Configuring the install-config yaml file].
-* See xref:../../installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc#installation-three-node-cluster_installing-restricted-networks-bare-metal[Configuring a three-node cluster] to deploy three-node clusters in bare metal environments.
+* See xref:../../installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc#installation-three-node-cluster_installing-restricted-networks-bare-metal[Configuring a three-node cluster] to deploy three-node clusters in bare-metal environments.
 * See xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#root-device-hints_preparing-to-install-with-agent-based-installer[About root device hints].
 * See link:https://nmstate.io/examples.html[NMState state examples].
 
diff --git a/installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc b/installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
new file mode 100644
index 000000000000..492acf2144e0
--- /dev/null
+++ b/installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
@@ -0,0 +1,41 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="installing-with-agent-basic"]
+= Installing a cluster
+include::_attributes/common-attributes.adoc[]
+:context: installing-with-agent-basic
+
+toc::[]
+
+You can install a basic {product-title} cluster using the Agent-based Installer.
+
+For procedures that include optional customizations you can make while using the Agent-based Installer, see xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing a cluster with customizations].
+
+[id="prerequisites_{context}"]
+== Prerequisites
+
+* You reviewed details about the xref:../../architecture/architecture-installation.adoc#architecture-installation[{product-title} installation and update] processes.
+* You read the documentation on xref:../../installing/overview/installing-preparing.adoc#installing-preparing[selecting a cluster installation method and preparing it for users].
+* If you use a firewall or proxy, you xref:../../installing/install_config/configuring-firewall.adoc#configuring-firewall[configured it to allow the sites] that your cluster requires access to.
+
+[id="installing-ocp-agent_{context}"]
+== Installing {product-title} with the Agent-based Installer
+
+The following procedures deploy a single-node {product-title} in a disconnected environment. You can use these procedures as a basis and modify according to your requirements.
+
+// Downloading the Agent-based Installer
+include::modules/installing-ocp-agent-download.adoc[leveloffset=+2]
+
+// Creating the configuration inputs
+include::modules/installing-ocp-agent-basic-inputs.adoc[leveloffset=+2]
+
+// Creating and booting the agent image
+include::modules/installing-ocp-agent-boot.adoc[leveloffset=+2]
+
+// Verifying that the current installation host can pull release images
+include::modules/installing-ocp-agent-tui.adoc[leveloffset=+2]
+
+// Tracking and verifying installation progress
+include::modules/installing-ocp-agent-verify.adoc[leveloffset=+2]
+
+// Gathering log data from a failed Agent-based installation
+include::modules/installing-ocp-agent-gather-log.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/installing/installing_with_agent_based_installer/prepare-pxe-assets-agent.adoc b/installing/installing_with_agent_based_installer/prepare-pxe-assets-agent.adoc
index 5d3d28d01006..035266315aa8 100644
--- a/installing/installing_with_agent_based_installer/prepare-pxe-assets-agent.adoc
+++ b/installing/installing_with_agent_based_installer/prepare-pxe-assets-agent.adoc
@@ -12,7 +12,7 @@ The assets you create in these procedures will deploy a single-node {product-tit
 
 See xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing an {product-title} cluster with the Agent-based Installer] to learn about more configurations available with the Agent-based Installer.
 
-[id="prerequisites_prepare-pxe-assets-agent_{context}"]
+[id="prerequisites_{context}"]
 == Prerequisites
 
 * You reviewed details about the xref:../../architecture/architecture-installation.adoc#architecture-installation[{product-title} installation and update] processes.
@@ -52,12 +52,19 @@ include::modules/installing-ocp-agent-ibm-z-zvm.adoc[leveloffset=+2]
 // Adding {ibm-z-name} agents with {op-system-base} KVM
 include::modules/installing-ocp-agent-ibm-z-kvm.adoc[leveloffset=+2]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../installing/installing_ibm_z/upi/installing-ibm-z-kvm.adoc#installing-ibm-z-kvm[Installing a cluster with {op-system-base} KVM on {ibm-z-title} and {ibm-linuxone-title}]
+
 // Adding {ibm-z-title} Logical Partition (LPAR) as agents
 include::modules/adding-ibm-z-lpar-agent.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../installing/installing_ibm_z/upi/installing-ibm-z.adoc#installing-ibm-z[Installing a cluster with z/VM on {ibm-z-title} and {ibm-linuxone-title}]
+* xref:../../installing/installing_ibm_z/upi/installing-ibm-z-lpar.adoc#installing-ibm-z-lpar[Installing a cluster in an LPAR on {ibm-z-title} and {ibm-linuxone-title}]
 
+// Adding {ibm-z-title} agents in a Logical Partition (LPAR) as a day 2 operation
+include::modules/adding-ibm-z-lpar-agent-day-2.adoc[leveloffset=+2]
 
diff --git a/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc b/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc
index 95cc23ac4464..f836caa5e8b7 100644
--- a/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc
+++ b/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc
@@ -9,7 +9,7 @@ toc::[]
 [id="about-the-agent-based-installer_{context}"]
 == About the Agent-based Installer
 
-The Agent-based installation method provides the flexibility to boot your on-premises servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
+The Agent-based installation method provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
 Agent-based installation is a subcommand of the {product-title} installer.
 It generates a bootable ISO image containing all of the information required to deploy an {product-title} cluster, with an available release image.
 
@@ -111,4 +111,6 @@ include::modules/validations-before-agent-iso-creation.adoc[leveloffset=+1]
 [id="agent-based-installation-next-steps_{context}"]
 == Next steps
 
-* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing a cluster with the Agent-based Installer]
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc#installing-with-agent-basic[Installing a cluster]
+
+* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing a cluster with customizations]
\ No newline at end of file
diff --git a/installing/installing_with_agent_based_installer/understanding-disconnected-installation-mirroring.adoc b/installing/installing_with_agent_based_installer/understanding-disconnected-installation-mirroring.adoc
index eaaf0eede7e1..907df1a39b7d 100644
--- a/installing/installing_with_agent_based_installer/understanding-disconnected-installation-mirroring.adoc
+++ b/installing/installing_with_agent_based_installer/understanding-disconnected-installation-mirroring.adoc
@@ -15,7 +15,7 @@ You can use a mirror registry for disconnected installations and to ensure that
 You can use one of the following procedures to mirror your {product-title} image repository to your mirror registry:
 
 * xref:../../disconnected/mirroring/installing-mirroring-installation-images.adoc#installing-mirroring-installation-images[Mirroring images for a disconnected installation]
-* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
+* xref:../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]
 
 include::modules/agent-install-about-mirroring-for-disconnected-registry.adoc[leveloffset=+1]
 
diff --git a/installing/overview/cluster-capabilities.adoc b/installing/overview/cluster-capabilities.adoc
index 31a09366f2b7..39894c67b390 100644
--- a/installing/overview/cluster-capabilities.adoc
+++ b/installing/overview/cluster-capabilities.adoc
@@ -125,6 +125,13 @@ include::modules/olm-overview.adoc[leveloffset=+2]
 .Additional resources
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Operator Lifecycle Manager concepts and resources]
 
+// Operator Lifecycle Manager v1 capability
+include::modules/olmv1-clusteroperator.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../extensions/index.adoc#olmv1-about[Extensions overview]
+
 include::modules/viewing-cluster-capabilities.adoc[leveloffset=+1]
 
 include::modules/enabling-baseline-capability-set.adoc[leveloffset=+1]
diff --git a/installing/overview/installing-preparing.adoc b/installing/overview/installing-preparing.adoc
index 46aa5551e198..e2f89ec81f7a 100644
--- a/installing/overview/installing-preparing.adoc
+++ b/installing/overview/installing-preparing.adoc
@@ -110,12 +110,12 @@ For a production cluster, you must configure the following integrations:
 
 * xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Persistent storage]
 * xref:../../authentication/understanding-identity-provider.adoc#understanding-identity-provider[An identity provider]
-* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[Monitoring core OpenShift Container Platform components]
+* xref:../../observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc#core-platform-monitoring-first-steps[Monitoring core {product-title} components]
 
 [id="installing-preparing-cluster-for-workloads"]
 == Preparing your cluster for workloads
 
-Depending on your workload needs, you might need to take extra steps before you begin deploying applications. For example, after you prepare infrastructure to support your application xref:../../cicd/builds/build-strategies.adoc#build-strategies[build strategy], you might need to make provisions for xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-low-latency-perf-profile[low-latency] workloads or to xref:../../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[protect sensitive workloads]. You can also configure xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[monitoring] for application workloads.
+Depending on your workload needs, you might need to take extra steps before you begin deploying applications. For example, after you prepare infrastructure to support your application xref:../../cicd/builds/build-strategies.adoc#build-strategies[build strategy], you might need to make provisions for xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-low-latency-perf-profile[low-latency] workloads or to xref:../../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[protect sensitive workloads]. You can also configure xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[monitoring] for application workloads.
 If you plan to run xref:../../windows_containers/enabling-windows-container-workloads.adoc#enabling-windows-container-workloads[Windows workloads], you must enable xref:../../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-networking[hybrid networking with OVN-Kubernetes] during the installation process; hybrid networking cannot be enabled after your cluster is installed.
 
 [id="supported-installation-methods-for-different-platforms"]
@@ -181,8 +181,8 @@ ifndef::openshift-origin[]
 |xref:../../installing/installing_gcp/installing-gcp-network-customizations.adoc#installing-gcp-network-customizations[&#10003;]
 |
 |
-|
-|
+|xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-host-network-interfaces-in-the-install-config-yaml-file_ipi-install-installation-workflow[&#10003;]
+|xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-host-network-interfaces-in-the-install-config-yaml-file_ipi-install-installation-workflow[&#10003;]
 |xref:../../installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc#installing-vsphere-installer-provisioned-network-customizations[&#10003;]
 |xref:../../installing/installing_ibm_cloud/installing-ibm-cloud-network-customizations.adoc#installing-ibm-cloud-network-customizations[&#10003;]
 |
diff --git a/installing/validation_and_troubleshooting/validating-an-installation.adoc b/installing/validation_and_troubleshooting/validating-an-installation.adoc
index 82b541feee7a..a172aacc763f 100644
--- a/installing/validation_and_troubleshooting/validating-an-installation.adoc
+++ b/installing/validation_and_troubleshooting/validating-an-installation.adoc
@@ -6,7 +6,10 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can check the status of an {product-title} cluster after an installation by following the procedures in this document.
+You can check the status of an {product-title} cluster after an installation or validate boot artifacts before an installation by following the procedures in this document.
+
+//Validating RHCOS live media
+include::modules/rhcos-validate-live-media.adoc[leveloffset=+1]
 
 //Reviewing the installation log
 include::modules/reviewing-the-installation-log.adoc[leveloffset=+1]
@@ -56,7 +59,7 @@ include::modules/checking-cluster-resource-availability-and-utilization.adoc[lev
 [role="_additional-resources"]
 .Additional resources
 
-* See xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview] for more information about the {product-title} monitoring stack.
+* See xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring] for more information about the {product-title} monitoring stack.
 
 //Listing alerts that are firing
 include::modules/listing-alerts-that-are-firing.adoc[leveloffset=+1]
@@ -64,7 +67,7 @@ include::modules/listing-alerts-that-are-firing.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* See xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[Managing alerts] for further details about alerting in {product-title}.
+* See xref:../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[Managing alerts as an Administrator] for further details about alerting in {product-title}.
 
 [id="validating-an-installation-next-steps"]
 == Next steps
diff --git a/machine_configuration/index.adoc b/machine_configuration/index.adoc
index d5dbe20df25b..f763b752d1dd 100644
--- a/machine_configuration/index.adoc
+++ b/machine_configuration/index.adoc
@@ -44,6 +44,7 @@ include::modules/machine-config-drift-detection.adoc[leveloffset=+1]
 
 include::modules/checking-mco-status.adoc[leveloffset=+1]
 include::modules/checking-mco-node-status.adoc[leveloffset=+1]
+include::modules/checking-mco-node-status-configuring.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/machine_configuration/machine-config-daemon-metrics.adoc b/machine_configuration/machine-config-daemon-metrics.adoc
index f2e2c9d42397..adf0316e86fc 100644
--- a/machine_configuration/machine-config-daemon-metrics.adoc
+++ b/machine_configuration/machine-config-daemon-metrics.adoc
@@ -13,7 +13,7 @@ include::modules/machine-config-daemon-metrics-understanding.adoc[leveloffset=+1
 [role="_additional-resources"]
 .Additional resources
 ifndef::openshift-rosa,openshift-dedicated[]
-* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+* xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
 * xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gathering data about your cluster]
 endif::openshift-rosa,openshift-dedicated[]
 ifdef::openshift-rosa,openshift-dedicated[]
diff --git a/machine_configuration/machine-configs-configure.adoc b/machine_configuration/machine-configs-configure.adoc
index 38ef76948cb3..173b709942c5 100644
--- a/machine_configuration/machine-configs-configure.adoc
+++ b/machine_configuration/machine-configs-configure.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 You can use the tasks in this section to create `MachineConfig` objects that modify files, systemd unit files, and other operating system features running on {product-title} nodes. For more ideas on working with machine configs, see content related to link:https://access.redhat.com/solutions/3868301[updating] SSH authorized keys, xref:../security/container_security/security-container-signature.adoc#security-container-signature[verifying image signatures], link:https://access.redhat.com/solutions/4727321[enabling SCTP], and link:https://access.redhat.com/solutions/5170251[configuring iSCSI initiatornames] for {product-title}.
 
-{product-title} supports link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition specification version 3.2]. All new machine configs you create going forward should be based on Ignition specification version 3.2. If you are upgrading your {product-title} cluster, any existing Ignition specification version 2.x machine configs will be translated automatically to specification version 3.2.
+{product-title} supports link:https://coreos.github.io/ignition/configuration-v3_4/[Ignition specification version 3.4]. You should base all new machine configs you create going forward on Ignition specification version 3.4. If you are upgrading your {product-title} cluster, any existing machine configs with a previous Ignition specification will be translated automatically to specification version 3.4.
 
 There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see xref:../machine_configuration/index.adoc#machine-config-drift-detection_machine-config-overview[Understanding configuration drift detection].
 
diff --git a/machine_configuration/machine-configs-custom.adoc b/machine_configuration/machine-configs-custom.adoc
index 35f8165510b5..f8d7bfb3a4c7 100644
--- a/machine_configuration/machine-configs-custom.adoc
+++ b/machine_configuration/machine-configs-custom.adoc
@@ -12,5 +12,6 @@ Besides managing `MachineConfig` objects, the MCO manages two custom resources (
 include::modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc[leveloffset=+1]
 include::modules/create-a-containerruntimeconfig-crd.adoc[leveloffset=+1]
 include::modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc[leveloffset=+1]
+include::modules/create-crio-default-capabilities.adoc[leveloffset=+1]
 
 
diff --git a/machine_configuration/mco-coreos-layering.adoc b/machine_configuration/mco-coreos-layering.adoc
index ad4626f21fd0..0d10765607c2 100644
--- a/machine_configuration/mco-coreos-layering.adoc
+++ b/machine_configuration/mco-coreos-layering.adoc
@@ -12,7 +12,7 @@ toc::[]
 [id="coreos-layering-about_{context}"]
 == About {op-system} image layering
 
-Image layering allows you to customize the underlying node operating system on any of your cluster worker nodes. This helps keep everything up-to-date, including the node operating system and any added customizations such as specialized software.
+Image layering allows you to customize the underlying node operating system on any of your cluster nodes. This helps keep everything up-to-date, including the node operating system and any added customizations such as specialized software.
 
 You create a custom layered image by using a Containerfile and applying it to nodes by using a custom object. At any time, you can remove the custom layered image by deleting that custom object.
 
@@ -101,7 +101,7 @@ RUN dnf install -y libreswan && \
     ostree container commit
 ----
 +
-Because libreswan requires additional {op-system-base} packages, the image must be built on an entitled {op-system-base} host. For RHEL entitlements to work, you must copy the `etc-pki-entitlement` secret into the `openshift-machine-api` namespace. 
+Because libreswan requires additional {op-system-base} packages, the image must be built on an entitled {op-system-base} host. For RHEL entitlements to work, you must copy the `etc-pki-entitlement` secret into the `openshift-machine-config-operator` namespace. 
 
 * *Third-party packages*. You can download and install RPMs from third-party organizations, such as the following types of packages:
 +
@@ -184,13 +184,33 @@ include::modules/coreos-layering-configuring-on.adoc[leveloffset=+1]
 
 .Additional resources
 * xref:../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
+* xref:../updating/updating_a_cluster/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-pause_update-using-custom-machine-config-pools[Pausing the machine config pools]
+
+include::modules/coreos-layering-configuring-on-modifying.adoc[leveloffset=+2]
+
+.Additional resources
+* xref:../updating/updating_a_cluster/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-pause_update-using-custom-machine-config-pools[Pausing the machine config pools]
+
+////
+Hiding extensions, not in 4.18. Maybe 4.19?
+include::modules/coreos-layering-configuring-on-extensions.adoc[leveloffset=+2]
+
+.Additional resources
+* xref:../machine_configuration/machine-configs-configure.html#rhcos-add-extensions_machine-configs-configure[Adding extensions to RHCOS]
+* xref:../updating/updating_a_cluster/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-pause_update-using-custom-machine-config-pools[Pausing the machine config pools]
+////
+
+// Not in 4.18; maybe 4.19
+// include::modules/coreos-layering-configuring-on-rebuild.adoc[leveloffset=+2] 
+
+include::modules/coreos-layering-configuring-on-revert.adoc[leveloffset=+2]
 
 include::modules/coreos-layering-configuring.adoc[leveloffset=+1]
 
 .Additional resources
 xref:../machine_configuration/mco-coreos-layering.adoc#coreos-layering-updating_mco-coreos-layering[Updating with a {op-system} custom layered image]
 
-include::modules/coreos-layering-removing.adoc[leveloffset=+1]
+include::modules/coreos-layering-removing.adoc[leveloffset=+2]
 include::modules/coreos-layering-updating.adoc[leveloffset=+1]
 
 ////
diff --git a/machine_management/cluster_api_machine_management/cluster-api-about.adoc b/machine_management/cluster_api_machine_management/cluster-api-about.adoc
index 6fa385b29864..270cafa5de2e 100644
--- a/machine_management/cluster_api_machine_management/cluster-api-about.adoc
+++ b/machine_management/cluster_api_machine_management/cluster-api-about.adoc
@@ -9,7 +9,7 @@ toc::[]
 :FeatureName: Managing machines with the Cluster API
 include::snippets/technology-preview.adoc[]
 
-The link:https://cluster-api.sigs.k8s.io/[Cluster API] is an upstream project that is integrated into {product-title} as a Technology Preview for {aws-first}, {gcp-first}, and {vmw-first}.
+The link:https://cluster-api.sigs.k8s.io/[Cluster API] is an upstream project that is integrated into {product-title} as a Technology Preview for {aws-first}, {gcp-first}, {azure-first}, {rh-openstack-first}, and {vmw-first}.
 
 //Cluster API overview
 include::modules/capi-overview.adoc[leveloffset=+1]
diff --git a/machine_management/cluster_api_machine_management/cluster-api-configuration.adoc b/machine_management/cluster_api_machine_management/cluster-api-configuration.adoc
index 088719c6fc9b..3250fc855288 100644
--- a/machine_management/cluster_api_machine_management/cluster-api-configuration.adoc
+++ b/machine_management/cluster_api_machine_management/cluster-api-configuration.adoc
@@ -24,4 +24,8 @@ For provider-specific configuration options for your cluster, see the following
 
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#cluster-api-config-options-gcp[Cluster API configuration options for {gcp-full}]
 
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc#cluster-api-config-options-azure[Cluster API configuration options for {azure-full}]
+
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc#cluster-api-config-options-rhosp[Cluster API configuration options for {rh-openstack}]
+
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#cluster-api-config-options-vsphere[Cluster API configuration options for {vmw-full}]
\ No newline at end of file
diff --git a/machine_management/cluster_api_machine_management/cluster-api-getting-started.adoc b/machine_management/cluster_api_machine_management/cluster-api-getting-started.adoc
index d1a4748f996f..203e9fc20bfe 100644
--- a/machine_management/cluster_api_machine_management/cluster-api-getting-started.adoc
+++ b/machine_management/cluster_api_machine_management/cluster-api-getting-started.adoc
@@ -9,7 +9,7 @@ toc::[]
 :FeatureName: Managing machines with the Cluster API
 include::snippets/technology-preview.adoc[]
 
-For the Cluster API Technology Preview, you must create the primary resources that the Cluster API requires manually.
+For the Cluster API Technology Preview, you must manually create some of the primary resources that the Cluster API requires.
 
 [id="creating-primary-resources_{context}"]
 == Creating the Cluster API primary resources
@@ -27,20 +27,14 @@ include::modules/capi-creating-cluster-resource.adoc[leveloffset=+2]
 .Additional resources
 * xref:../../machine_management/cluster_api_machine_management/cluster-api-configuration.adoc#cluster-api-configuration[Cluster API configuration]
 
-//Creating a Cluster API infrastructure resource
-include::modules/capi-creating-infrastructure-resource.adoc[leveloffset=+2]
-[role="_additional-resources"]
-.Additional resources
-* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#capi-yaml-infrastructure-aws_cluster-api-config-options-aws[Sample YAML for a Cluster API infrastructure resource on {aws-full}]
-* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#capi-yaml-infrastructure-gcp_cluster-api-config-options-gcp[Sample YAML for a Cluster API infrastructure resource on {gcp-full}]
-* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#capi-yaml-infrastructure-vsphere_cluster-api-config-options-vsphere[Sample YAML for a Cluster API infrastructure resource on {vmw-full}]
-
 //Creating a Cluster API machine template
 include::modules/capi-creating-machine-template.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#capi-yaml-machine-template-aws_cluster-api-config-options-aws[Sample YAML for a Cluster API machine template resource on {aws-full}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#capi-yaml-machine-template-gcp_cluster-api-config-options-gcp[Sample YAML for a Cluster API machine template resource on {gcp-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc#capi-yaml-machine-template-azure_cluster-api-config-options-azure[Sample YAML for a Cluster API machine template resource on {azure-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc#capi-yaml-machine-template-rhosp_cluster-api-config-options-rhosp[Sample YAML for a Cluster API machine template resource on {rh-openstack}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#capi-yaml-machine-template-vsphere_cluster-api-config-options-vsphere[Sample YAML for a Cluster API machine template resource on {vmw-full}]
 
 //Creating a Cluster API compute machine set
@@ -49,4 +43,6 @@ include::modules/capi-creating-machine-set.adoc[leveloffset=+2]
 .Additional resources
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#capi-yaml-machine-set-aws_cluster-api-config-options-aws[Sample YAML for a Cluster API compute machine set resource on {aws-full}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#capi-yaml-machine-set-gcp_cluster-api-config-options-gcp[Sample YAML for a Cluster API compute machine set resource on {gcp-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc#capi-yaml-machine-set-azure_cluster-api-config-options-azure[Sample YAML for a Cluster API compute machine set resource on {azure-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc#capi-yaml-machine-set-rhosp_cluster-api-config-options-rhosp[Sample YAML for a Cluster API compute machine set resource on {rh-openstack}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#capi-yaml-machine-set-vsphere_cluster-api-config-options-vsphere[Sample YAML for a Cluster API compute machine set resource on {vmw-full}]
\ No newline at end of file
diff --git a/machine_management/cluster_api_machine_management/cluster-api-managing-machines.adoc b/machine_management/cluster_api_machine_management/cluster-api-managing-machines.adoc
index 606fcad55482..d4534548120f 100644
--- a/machine_management/cluster_api_machine_management/cluster-api-managing-machines.adoc
+++ b/machine_management/cluster_api_machine_management/cluster-api-managing-machines.adoc
@@ -15,6 +15,8 @@ include::modules/capi-modifying-machine-template.adoc[leveloffset=+1]
 .Additional resources
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#capi-yaml-machine-template-aws_cluster-api-config-options-aws[Sample YAML for a Cluster API machine template resource on {aws-full}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#capi-yaml-machine-template-gcp_cluster-api-config-options-gcp[Sample YAML for a Cluster API machine template resource on {gcp-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc#capi-yaml-machine-template-azure_cluster-api-config-options-azure[Sample YAML for a Cluster API machine template resource on {azure-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc#capi-yaml-machine-template-rhosp_cluster-api-config-options-rhosp[Sample YAML for a Cluster API machine template resource on {rh-openstack}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#capi-yaml-machine-template-vsphere_cluster-api-config-options-vsphere[Sample YAML for a Cluster API machine template resource on {vmw-full}]
 * xref:../../machine_management/cluster_api_machine_management/cluster-api-managing-machines.adoc#machineset-modifying_cluster-api-managing-machines[Modifying a compute machine set by using the CLI]
 
@@ -25,4 +27,6 @@ include::modules/machineset-modifying.adoc[leveloffset=+1,tag=!MAPI]
 .Additional resources
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#capi-yaml-machine-set-aws_cluster-api-config-options-aws[Sample YAML for a Cluster API compute machine set resource on {aws-full}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc#capi-yaml-machine-set-gcp_cluster-api-config-options-gcp[Sample YAML for a Cluster API compute machine set resource on {gcp-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc#capi-yaml-machine-set-azure_cluster-api-config-options-azure[Sample YAML for a Cluster API compute machine set resource on {azure-full}]
+* xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc#capi-yaml-machine-set-rhosp_cluster-api-config-options-rhosp[Sample YAML for a Cluster API compute machine set resource on {rh-openstack}]
 * xref:../../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc#capi-yaml-machine-set-vsphere_cluster-api-config-options-vsphere[Sample YAML for a Cluster API compute machine set resource on {vmw-full}]
\ No newline at end of file
diff --git a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc
index b2da6c6ca4eb..df66bd621976 100644
--- a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc
+++ b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc
@@ -16,9 +16,6 @@ You can change the configuration of your {aws-first} Cluster API machines by upd
 
 The following example YAML files show configurations for an {aws-full} cluster.
 
-//Sample YAML for a CAPI AWS infrastructure resource
-include::modules/capi-yaml-infrastructure-aws.adoc[leveloffset=+2]
-
 //Sample YAML for CAPI AWS machine template resource
 include::modules/capi-yaml-machine-template-aws.adoc[leveloffset=+2]
 
diff --git a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc
new file mode 100644
index 000000000000..ffe0cd25028b
--- /dev/null
+++ b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc
@@ -0,0 +1,30 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="cluster-api-config-options-azure"]
+= Cluster API configuration options for {azure-full}
+include::_attributes/common-attributes.adoc[]
+:context: cluster-api-config-options-azure
+
+toc::[]
+
+:FeatureName: Managing machines with the Cluster API
+include::snippets/technology-preview.adoc[]
+
+You can change the configuration of your {azure-first} Cluster API machines by updating values in the Cluster API custom resource manifests.
+
+[id="cluster-api-sample-yaml-azure_{context}"]
+== Sample YAML for configuring {azure-full} clusters
+
+The following example YAML files show configurations for an {azure-short} cluster.
+
+//Sample YAML for CAPI Azure machine template resource
+include::modules/capi-yaml-machine-template-azure.adoc[leveloffset=+2]
+
+//Sample YAML for a CAPI Azure compute machine set resource
+include::modules/capi-yaml-machine-set-azure.adoc[leveloffset=+2]
+
+// [id="cluster-api-supported-features-azure_{context}"]
+// == Enabling {azure-full} features with the Cluster API
+
+// You can enable the following features by updating values in the Cluster API custom resource manifests.
+
+//Not sure what, if anything, we can add here at this time.
\ No newline at end of file
diff --git a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc
index b9e5c23ecb0c..7b3ea376a30a 100644
--- a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc
+++ b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc
@@ -16,9 +16,6 @@ You can change the configuration of your {gcp-first} Cluster API machines by upd
 
 The following example YAML files show configurations for a {gcp-full} cluster.
 
-//Sample YAML for a CAPI GCP infrastructure resource
-include::modules/capi-yaml-infrastructure-gcp.adoc[leveloffset=+2]
-
 //Sample YAML for CAPI GCP machine template resource
 include::modules/capi-yaml-machine-template-gcp.adoc[leveloffset=+2]
 
diff --git a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc
new file mode 100644
index 000000000000..70a289999497
--- /dev/null
+++ b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc
@@ -0,0 +1,30 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="cluster-api-config-options-rhosp"]
+= Cluster API configuration options for Red{nbsp}Hat OpenStack Platform
+include::_attributes/common-attributes.adoc[]
+:context: cluster-api-config-options-rhosp
+
+toc::[]
+
+:FeatureName: Managing machines with the Cluster API
+include::snippets/technology-preview.adoc[]
+
+You can change the configuration of your {rh-openstack-first} Cluster API machines by updating values in the Cluster API custom resource manifests.
+
+[id="cluster-api-sample-yaml-rhosp_{context}"]
+== Sample YAML for configuring {rh-openstack} clusters
+
+The following example YAML files show configurations for a {rh-openstack} cluster.
+
+//Sample YAML for CAPI RHOSP machine template resource
+include::modules/capi-yaml-machine-template-rhosp.adoc[leveloffset=+2]
+
+//Sample YAML for a CAPI RHOSP compute machine set resource
+include::modules/capi-yaml-machine-set-rhosp.adoc[leveloffset=+2]
+
+// [id="cluster-api-supported-features-rhosp_{context}"]
+// == Enabling {rh-openstack} features with the Cluster API
+
+// You can enable the following features by updating values in the Cluster API custom resource manifests.
+
+//Not sure what, if anything, we can add here at this time.
\ No newline at end of file
diff --git a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc
index 98fa4cfcb6a5..43fe1ed67e9c 100644
--- a/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc
+++ b/machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-vsphere.adoc
@@ -16,9 +16,6 @@ You can change the configuration of your {vmw-first} Cluster API machines by upd
 
 The following example YAML files show configurations for a {vmw-full} cluster.
 
-//Sample YAML for a CAPI vSphere infrastructure resource
-include::modules/capi-yaml-infrastructure-vsphere.adoc[leveloffset=+2]
-
 //Sample YAML for CAPI vSphere machine template resource
 include::modules/capi-yaml-machine-template-vsphere.adoc[leveloffset=+2]
 
diff --git a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc
index 6e328f27bcb4..a0d1ea532f25 100644
--- a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc
+++ b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc
@@ -41,6 +41,10 @@ include::modules/machineset-aws-existing-placement-group.adoc[leveloffset=+2]
 //Machine sets that enable the Amazon EC2 Instance Metadata Service
 include::modules/machineset-imds-options.adoc[leveloffset=+2]
 
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images[Updated boot images]
+
 //Creating machines that use the Amazon EC2 Instance Metadata Service
 include::modules/machineset-creating-imds-options.adoc[leveloffset=+3]
 
diff --git a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-azure.adoc b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-azure.adoc
index 4969c25ee9c0..a50e6b607815 100644
--- a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-azure.adoc
+++ b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-azure.adoc
@@ -30,7 +30,7 @@ include::modules/private-clusters-setting-api-private.adoc[leveloffset=+2]
 .Additional resources
 * xref:../../../networking/configuring_ingress_cluster_traffic/nw-configuring-ingress-controller-endpoint-publishing-strategy.adoc#nw-ingresscontroller-change-internal_nw-configuring-ingress-controller-endpoint-publishing-strategy[Configuring the Ingress Controller endpoint publishing scope to Internal]
 
-//Selecting an Azure Marketplace image
+//Using the Azure Marketplace offering
 include::modules/installation-azure-marketplace-subscribe.adoc[leveloffset=+2]
 
 //Enabling Azure boot diagnostics
diff --git a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc
index 18711ea6a0f1..ac825a4d9160 100644
--- a/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc
+++ b/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc
@@ -31,3 +31,7 @@ You can enable features by updating values in the control plane machine set.
 
 //Adding tags to machines by using machine sets
 include::modules/machine-api-vmw-add-tags.adoc[leveloffset=+2,tag=!compute]
+
+//Configuring multiple NICs by using machine sets
+//pulled from 4.18 GA
+//include::modules/machineset-vsphere-multiple-nics.adoc[leveloffset=+1,tag=!compute]
\ No newline at end of file
diff --git a/machine_management/creating-infrastructure-machinesets.adoc b/machine_management/creating-infrastructure-machinesets.adoc
index 15360cdeffb5..6cc3fdf5423c 100644
--- a/machine_management/creating-infrastructure-machinesets.adoc
+++ b/machine_management/creating-infrastructure-machinesets.adoc
@@ -39,7 +39,7 @@ Machine sets running on Azure support non-guaranteed xref:../machine_management/
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../machine_management/creating_machinesets/creating-machineset-azure.adoc#installation-azure-marketplace-subscribe_creating-machineset-azure[Selecting an Azure Marketplace image]
+* xref:../machine_management/creating_machinesets/creating-machineset-azure.adoc#installation-azure-marketplace-subscribe_creating-machineset-azure[Using the Azure Marketplace offering]
 
 include::modules/machineset-yaml-azure-stack-hub.adoc[leveloffset=+3]
 
@@ -100,6 +100,11 @@ Some of the infrastructure resources are deployed in your cluster by default. Yo
 
 [source,yaml]
 ----
+apiVersion: imageregistry.operator.openshift.io/v1
+kind: Config
+metadata:
+  name: cluster
+# ...
 spec:
   nodePlacement: <1>
     nodeSelector:
@@ -129,6 +134,4 @@ include::modules/nodes-cluster-resource-override-move-infra.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../observability/monitoring/configuring-the-monitoring-stack.adoc#moving-monitoring-components-to-different-nodes_configuring-the-monitoring-stack[Moving monitoring components to different nodes]
-* xref:../observability/logging/scheduling_resources/logging-node-selectors.adoc#logging-node-selectors[Using node selectors to move logging resources]
-* xref:../observability/logging/scheduling_resources/logging-taints-tolerations.adoc#cluster-logging-logstore-tolerations_logging-taints-tolerations[Using taints and tolerations to control logging pod placement]
+* xref:../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#moving-monitoring-components-to-different-nodes-cpm_configuring-performance-and-scalability[Moving monitoring components to different nodes]
diff --git a/machine_management/creating_machinesets/creating-machineset-aws.adoc b/machine_management/creating_machinesets/creating-machineset-aws.adoc
index 54bf7ce179d1..5b5d9483fbd7 100644
--- a/machine_management/creating_machinesets/creating-machineset-aws.adoc
+++ b/machine_management/creating_machinesets/creating-machineset-aws.adoc
@@ -30,6 +30,10 @@ include::modules/machineset-aws-existing-placement-group.adoc[leveloffset=+1]
 //Machine sets that enable the Amazon EC2 Instance Metadata Service
 include::modules/machineset-imds-options.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+* xref:../../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images[Updated boot images]
+
 //Creating machines that use the Amazon EC2 Instance Metadata Service
 include::modules/machineset-creating-imds-options.adoc[leveloffset=+2]
 
diff --git a/machine_management/creating_machinesets/creating-machineset-azure.adoc b/machine_management/creating_machinesets/creating-machineset-azure.adoc
index 2dd18bf973dd..2c02cba4d562 100644
--- a/machine_management/creating_machinesets/creating-machineset-azure.adoc
+++ b/machine_management/creating_machinesets/creating-machineset-azure.adoc
@@ -24,7 +24,7 @@ include::modules/machineset-label-gpu-autoscaler.adoc[leveloffset=+1]
 .Additional resources
 * xref:../../machine_management/applying-autoscaling.adoc#cluster-autoscaler-cr_applying-autoscaling[Cluster autoscaler resource definition]
 
-//Selecting an Azure Marketplace image
+//Using the Azure Marketplace offering
 include::modules/installation-azure-marketplace-subscribe.adoc[leveloffset=+1]
 
 //Enabling Azure boot diagnostics
diff --git a/machine_management/creating_machinesets/creating-machineset-vsphere.adoc b/machine_management/creating_machinesets/creating-machineset-vsphere.adoc
index 12424858cf1d..9b9971c0d76e 100644
--- a/machine_management/creating_machinesets/creating-machineset-vsphere.adoc
+++ b/machine_management/creating_machinesets/creating-machineset-vsphere.adoc
@@ -46,4 +46,7 @@ include::modules/machineset-label-gpu-autoscaler.adoc[leveloffset=+1]
 * xref:../../machine_management/applying-autoscaling.adoc#cluster-autoscaler-cr_applying-autoscaling[Cluster autoscaler resource definition]
 
 //Adding tags to machines by using machine sets
-include::modules/machine-api-vmw-add-tags.adoc[leveloffset=+1,tag=!controlplane]
\ No newline at end of file
+include::modules/machine-api-vmw-add-tags.adoc[leveloffset=+1,tag=!controlplane]
+
+//Configuring multiple NICs by using machine sets
+include::modules/machineset-vsphere-multiple-nics.adoc[leveloffset=+1,tag=!controlplane]
\ No newline at end of file
diff --git a/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc b/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
index e2aab42ce764..87048afbbe0a 100644
--- a/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
+++ b/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
@@ -6,25 +6,16 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-You can automatically restore data from manual backups when {microshift-short} fails to start by using the `auto-recovery` feature.
+You can automatically restore data from manual backups when {microshift-short} fails to start by configuring automatic recovery.
 
-You can use the following options with the existing `backup` and `restore` commands in this feature:
+include::modules/microshift-auto-recovery-manual-backups.adoc[leveloffset=+1]
 
-* `--auto-recovery`: Selects the most recent version of the backup, and then restores it. This option treats the `PATH` argument as a path to a directory that holds all the backups for automated recovery, and not just as a path to a particular backup file.
-* `--dont-save-failed`: Disables the backup of failed {microshift-short} data.
+include::modules/microshift-creating-backups-auto-recovery.adoc[leveloffset=+1]
 
-[NOTE]
-====
-* You can use the `--auto-recovery` option with both the `backup` and `restore` commands.
-* You can use the `--dont-save-failed` option only with the `restore` command.
-====
+include::modules/microshift-restoring-backups-auto-recovery.adoc[leveloffset=+1]
 
-include::modules/microshift-creating-backups.adoc[leveloffset=+1]
+include::modules/microshift-auto-recovery-example-rpm-systems.adoc[leveloffset=+2]
 
-include::modules/microshift-restoring-backups.adoc[leveloffset=+1]
+include::modules/microshift-auto-recovery-example-ostree-systems.adoc[leveloffset=+2]
 
-include::modules/microshift-automation-example-rpm-systems.adoc[leveloffset=+1]
-
-include::modules/microshift-automation-example-ostree-systems.adoc[leveloffset=+1]
-
-include::modules/microshift-automation-example-bootc-systems.adoc[leveloffset=+1]
+include::modules/microshift-auto-recovery-example-bootc-systems.adoc[leveloffset=+2]
diff --git a/microshift_cli_ref/microshift-oc-cli-install.adoc b/microshift_cli_ref/microshift-oc-cli-install.adoc
index 2e6994e3e119..808d1c315964 100644
--- a/microshift_cli_ref/microshift-oc-cli-install.adoc
+++ b/microshift_cli_ref/microshift-oc-cli-install.adoc
@@ -2,7 +2,7 @@
 [id="microshift-oc-cli-install"]
 = Getting started with the OpenShift CLI
 include::_attributes/attributes-microshift.adoc[]
-:context: cli-oc-installing
+:context: microshift-oc-cli-install
 
 toc::[]
 
diff --git a/microshift_cli_ref/microshift-usage-oc-kubectl.adoc b/microshift_cli_ref/microshift-usage-oc-kubectl.adoc
index 9c118464a46b..073a305e9b82 100644
--- a/microshift_cli_ref/microshift-usage-oc-kubectl.adoc
+++ b/microshift_cli_ref/microshift-usage-oc-kubectl.adoc
@@ -35,7 +35,7 @@ The additional command `oc new-app`, for example, makes it easier to get new app
 If you installed an earlier version of `oc`, you might not be able use it to complete all of the commands in {microshift-short} {product-version}. If you want the latest features, you must download and install the latest version of `oc` that corresponds with your {microshift-short} version.
 ====
 
-Using new capabilities often requires the latest `oc` binary. A 4.18 server might have additional capabilities that a 4.16 `oc` binary cannot use and a 4.18 `oc` binary might have additional capabilities that are unsupported by a 4.15 server.
+Using new capabilities often requires the latest `oc` binary. A 4.19 server might have additional capabilities that a 4.16 `oc` binary cannot use and a 4.19 `oc` binary might have additional capabilities that are unsupported by a 4.15 server.
 
 .Compatibility Matrix
 
diff --git a/microshift_configuring/microshift_auth_security/_attributes b/microshift_configuring/microshift_auth_security/_attributes
new file mode 120000
index 000000000000..f27fd275ea6b
--- /dev/null
+++ b/microshift_configuring/microshift_auth_security/_attributes
@@ -0,0 +1 @@
+../_attributes/
\ No newline at end of file
diff --git a/scalability_and_performance/telco_ref_design_specs/images b/microshift_configuring/microshift_auth_security/images
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/images
rename to microshift_configuring/microshift_auth_security/images
diff --git a/microshift_configuring/microshift-audit-logs-config.adoc b/microshift_configuring/microshift_auth_security/microshift-audit-logs-config.adoc
similarity index 100%
rename from microshift_configuring/microshift-audit-logs-config.adoc
rename to microshift_configuring/microshift_auth_security/microshift-audit-logs-config.adoc
diff --git a/microshift_configuring/microshift-custom-ca.adoc b/microshift_configuring/microshift_auth_security/microshift-custom-ca.adoc
similarity index 100%
rename from microshift_configuring/microshift-custom-ca.adoc
rename to microshift_configuring/microshift_auth_security/microshift-custom-ca.adoc
diff --git a/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc b/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc
new file mode 100644
index 000000000000..65d483931b43
--- /dev/null
+++ b/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc
@@ -0,0 +1,27 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-tls-config"]
+= Configuring TLS security profiles
+include::_attributes/attributes-microshift.adoc[]
+:context: microshift-tls-config
+
+toc::[]
+
+Use transport layer security (TLS) protocols to help prevent known insecure protocols, ciphers, or algorithms from accessing the applications you run on {microshift-short}.
+
+include::modules/microshift-tls-config-con.adoc[leveloffset=+1]
+
+include::modules/microshift-tls-config-proc.adoc[leveloffset=+1]
+
+include::modules/microshift-tls-default-cipher-suites.adoc[leveloffset=+2]
+
+[id="additional-resources_microshift-tls-config_{context}"]
+[role="_additional-resources"]
+== Additional resources
+
+* xref:../../microshift_configuring/microshift-using-config-yaml.adoc#microshift-config-snippets_microshift-configuring[Using configuration snippets].
+
+* To secure pods using security content constraints (SCC), see xref:../../microshift_running_apps/microshift-authentication.adoc#authentication-microshift[Pod security authentication and authorization].
+
+* xref:../../microshift_configuring/microshift-cluster-access-kubeconfig.adoc#microshift-kubeconfig[Cluster access with kubeconfig].
+
+* xref:../microshift_auth_security/microshift-custom-ca.adoc#microshift-custom-ca[Configuring custom certificate authorities].
\ No newline at end of file
diff --git a/scalability_and_performance/telco_ref_design_specs/modules b/microshift_configuring/microshift_auth_security/modules
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/modules
rename to microshift_configuring/microshift_auth_security/modules
diff --git a/scalability_and_performance/telco_ref_design_specs/snippets b/microshift_configuring/microshift_auth_security/snippets
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/snippets
rename to microshift_configuring/microshift_auth_security/snippets
diff --git a/microshift_configuring/microshift_low_latency/microshift-low-latency.adoc b/microshift_configuring/microshift_low_latency/microshift-low-latency.adoc
index 3de8b7ace28e..afc622b34530 100644
--- a/microshift_configuring/microshift_low_latency/microshift-low-latency.adoc
+++ b/microshift_configuring/microshift_low_latency/microshift-low-latency.adoc
@@ -73,9 +73,6 @@ Complete the build process by starting with the following procedure to embed {mi
 * link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/9/html/installing_rhel_9_for_real_time/assembly_installing-rhel-for-real-time_installing-rhel-9-for-real-time#post-installation-instructions_assembly_installing-rhel-for-real-time[Post installation instructions] (RHEL for Real Time documentation)
 * xref:../../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-embed-in-rpm-ostree[Embedding in a {op-system-ostree} image]
 
-* link:https://access.redhat.com/solutions/4096521[FAQ about {op-system-base} for Real Time (kernel-rt)]
-//Can likely remove KCS after 2024 as it may go out of date
-
 include::modules/microshift-low-latency-prepare-workload.adoc[leveloffset=+1]
 
 //additional resources for preparing the workload
diff --git a/microshift_install_bootc/microshift-install-rhel-image-mode.adoc b/microshift_install_bootc/microshift-about-rhel-image-mode.adoc
similarity index 51%
rename from microshift_install_bootc/microshift-install-rhel-image-mode.adoc
rename to microshift_install_bootc/microshift-about-rhel-image-mode.adoc
index f7ce06151768..f8349bdb0979 100644
--- a/microshift_install_bootc/microshift-install-rhel-image-mode.adoc
+++ b/microshift_install_bootc/microshift-about-rhel-image-mode.adoc
@@ -1,8 +1,8 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="microshift-install-rhel-image-mode"]
+[id="microshift-about-rhel-image-mode"]
 include::_attributes/attributes-microshift.adoc[]
-= Using image mode for RHEL with {microshift-short}
-:context: microshift-install-rhel-image-mode
+= Understanding image mode for RHEL with {microshift-short}
+:context: microshift-about-rhel-image-mode
 
 toc::[]
 
@@ -12,14 +12,10 @@ You can embed {microshift-short} into an operating system image using image mode
 
 include::snippets/technology-preview.adoc[]
 
-include::modules/microshift-install-rhel-image-mode-conc.adoc[leveloffset=+1]
-
-include::modules/microshift-install-rhel-image-mode-build-image.adoc[leveloffset=+1]
-
-include::modules/microshift-install-rhel-image-mode-publish-image.adoc[leveloffset=+1]
+include::modules/microshift-install-bootc-conc.adoc[leveloffset=+1]
 
 [id="_additional-resources_microshift-install-rhel-image-mode_{context}"]
 == Additional resources
 * link:https://developers.redhat.com/products/rhel-image-mode/getting-started[Image mode for Red Hat Enterprise Linux learning exercises]
 
-* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/index[Using image mode for RHEL to build, deploy, and manage operating systems]
\ No newline at end of file
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/{op-system-version-major}/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/index[Using image mode for RHEL to build, deploy, and manage operating systems]
\ No newline at end of file
diff --git a/microshift_install_bootc/microshift-install-bootc-image.adoc b/microshift_install_bootc/microshift-install-bootc-image.adoc
new file mode 100644
index 000000000000..f9956983e62e
--- /dev/null
+++ b/microshift_install_bootc/microshift-install-bootc-image.adoc
@@ -0,0 +1,26 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-install-publish-bootc-image"]
+include::_attributes/attributes-microshift.adoc[]
+= Installing and publishing a bootc image to a registry
+:context: microshift-install-rhel-bootc-image
+
+toc::[]
+
+{microshift-short} is built and published as image mode containers. When installing a {op-system-base-full} bootable container image with {microshift-short}, use either a prebuilt bootable container image or build your own custom bootable container image.
+
+:FeatureName: Image mode for {op-system-base}
+
+include::snippets/technology-preview.adoc[]
+
+include::modules/microshift-install-bootc-workflow.adoc[leveloffset=+1]
+
+[id="microshift-get-build-bootc-image_{context}"]
+== Get or build your bootc image
+
+Either get an existing bootc image or create one, then you can publish that image to a remote registry for use.
+
+include::modules/microshift-install-bootc-get-published-image.adoc[leveloffset=+2]
+
+include::modules/microshift-install-bootc-build-image.adoc[leveloffset=+2]
+
+include::modules/microshift-install-bootc-publish-image.adoc[leveloffset=+1]
diff --git a/microshift_install_bootc/microshift-install-running-bootc-image-vm.adoc b/microshift_install_bootc/microshift-install-running-bootc-image-vm.adoc
new file mode 100644
index 000000000000..fa27c090e1cb
--- /dev/null
+++ b/microshift_install_bootc/microshift-install-running-bootc-image-vm.adoc
@@ -0,0 +1,17 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-install-running-bootc-image-in-vm"]
+include::_attributes/attributes-microshift.adoc[]
+= Running the bootc image in a virtual machine
+:context: microshift-install-running-bootc-image-in-vm
+
+toc::[]
+
+Use the bootable container image as an installation source to set up a {op-system-base-full} virtual machine.
+
+:FeatureName: Image mode for {op-system-base}
+
+include::snippets/technology-preview.adoc[]
+
+include::modules/microshift-install-bootc-prepare-kickstart.adoc[leveloffset=+1]
+
+include::modules/microshift-install-bootc-creating-vm.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/microshift_install_get_ready/microshift-install-get-ready.adoc b/microshift_install_get_ready/microshift-install-get-ready.adoc
index bfc7eb0136ee..373444be8255 100644
--- a/microshift_install_get_ready/microshift-install-get-ready.adoc
+++ b/microshift_install_get_ready/microshift-install-get-ready.adoc
@@ -6,13 +6,91 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-Plan for your {microshift-short} installation and complete host configuration steps as needed.
+Plan for your {op-system-bundle} by planning your {op-system-base-full} installation type and your {microshift-short} configuration.
 
 include::modules/microshift-install-system-requirements.adoc[leveloffset=+1]
 
 [id="get-ready-install-rhde-compatibility-table_{context}"]
 == Compatibility table
 
-Plan to pair a supported version of {op-system-ostree} with the {microshift-short} version you are using as described in the following compatibility table:
+Plan to pair a supported version of {op-system-ostree} with the {microshift-short} version you are using as described in the following compatibility table.
 
 include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+1]
+
+[id="microshift-get-ready-install-tools-intro_{context}"]
+== {microshift-short} installation tools
+
+To use {microshift-short}, you must already have or plan to install a {op-system-base} type, such as on bare metal, or as a virtual machine (VM) that you provision. Although each use case has different details, each installation of {op-system-bundle} uses {op-system-base} tools and the {oc-first}.
+
+You can use RPMs to install {microshift-short} on an existing {op-system-base} machine. See xref:../microshift_install_rpm/microshift-install-rpm.adoc#microshift-install-rpm[Installing from an RPM package] for more information. No other tools are required unless you are also installing an image-based {op-system-base} system or VM at the same time.
+
+[id="microshift-get-ready-install-rhel-types_{context}"]
+== {op-system-base} installation types
+
+Where you want to run your cluster and what your application needs to do determine the {op-system-base} installation type that you choose. For every installation target, you must configure both the operating system and {microshift-short}. Consider your application storage needs, networking for cluster or application access, and your authentication and security requirements.
+
+Understand the differences between the {op-system-base} installation types, including the support scope of each, and the tools used.
+
+[id="microshift-get-ready-install-rpm_{context}"]
+=== Using RPMs, or package-based installation
+
+This simple installation type uses a basic command to install {microshift-short} on an existing {op-system-base} machine. See xref:../microshift_install_rpm/microshift-install-rpm.adoc#microshift-install-rpm[Installing from an RPM package] for more information. No other tools are required unless you are also installing a {op-system-base} system or virtual machine (VM) at the same time.
+
+[id="microshift-get-ready-install-rhel-image-based_{context}"]
+=== {op-system-base} image-based installations
+
+Image-based installation types involve creating an `rpm-ostree`-based, immutable version of {op-system-base} that is optimized for edge deployment.
+
+* {op-system-ostree} can be deployed to the edge in production environments. This installation type can be used where network connections are present or completely offline, depending on the local environment.
+
+* Image mode for {op-system-base} is available with the Technology Preview support scope. This image-based installation type is based on OCI container images and bootable containers. See link:https://developers.redhat.com/articles/2024/09/24/bootc-getting-started-bootable-containers[bootc: Getting started with bootable containers] for an introduction to bootc technology.
+
+When choosing an image-based installation, consider whether the installation target is intended to be in an offline or networked state, where you plan to build system images, and how you plan to load your {op-system-bundle}. Use the following scenarios as general guidance:
+
+** If you build either a fully self-contained {op-system-ostree} or an image mode for {op-system-base} ISO outside a disconnected environment, and then install the ISO locally on your edge devices, you likely do not need an RPM repository or a mirror registry.
+** If you build an ISO outside a disconnected environment that does not include the container images, but consists of only the RPMs, you need a mirror registry inside your disconnected environment. You use your mirror registry to pull container images.
+** If you build images inside a disconnected environment, or use package mode for installations, you need both a mirror registry and a local RPM mirror repository. You can use either the {op-system-base} reposync utility or Red{nbsp}Hat Satellite for advanced use cases. See link:https://access.redhat.com/solutions/7019225[How to create a local mirror of the latest update for Red{nbsp}Hat Enterprise Linux 8 and 9 without using Satellite Server] and link:https://www.redhat.com/en/technologies/management/satellite[Red{nbsp}Hat Satellite] for more information.
+
+[id="microshift-get-ready-install-rhel-tools-concepts_{context}"]
+== {op-system-base} installation tools and concepts
+
+Familiarize yourself with the following {op-system-base} tools and concepts:
+
+* A Kickstart file, which contains the configuration and instructions used during the installation of your specific operating system. For more information, see xref:../microshift_install_kickstarts/microshift-rhel-kickstarts.adoc#microshift-rhel-kickstarts[Using Kickstart files for installting {microshift-short} in {op-system-base}].
+
+* {op-system-base} image builder is a tool for creating deployment-ready customized system images. {op-system-base} image builder uses a blueprint that you create to make the ISO. {op-system-base} image builder is best installed on a {op-system-base} VM and is built with the `composer-cli` tool. To set up these tools and review the workflow, see the following {op-system-base} documentation links:
+** link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#composer-command-line-interface_creating-system-images-with-composer-command-line-interface[Introducing the RHEL image builder command-line interface]
+** link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/installing-composer_composing-a-customized-rhel-system-image[Installing image builder]
+** link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#creating-a-system-image-with-composer-in-the-command-line-interface_creating-system-images-with-composer-command-line-interface[Creating a system image with RHEL image builder in the command-line interface]
+
+* A blueprint file directs {op-system-base} image builder to the items to include in the ISO. An image blueprint provides a persistent definition of image customizations. You can create multiple builds from a single blueprint. You can also edit an existing blueprint to build a new ISO as requirements change. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-system-images-with-composer-command-line-interface_composing-a-customized-rhel-system-image#creating-a-composer-blueprint-with-command-line-interface_creating-system-images-with-composer-command-line-interface[Creating a blueprint by using the command-line interface] in the {op-system-base} documentation.
+
+* An ISO, which is the bootable operating system on which {microshift-short} runs.
+** See link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-a-boot-iso-installer-image-with-image-builder_composing-a-customized-rhel-system-image#creating-a-boot-iso-installer-image-with-image-builder-in-the-command-line-interface_creating-a-boot-iso-installer-image-with-image-builder[Creating a boot ISO installer image using the RHEL image builder CLI], link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/creating-a-boot-iso-installer-image-with-image-builder_composing-a-customized-rhel-system-image#installing-the-iso-to-a-bare-metal-system_creating-a-boot-iso-installer-image-with-image-builder[Installing a bootable ISO to a media and booting it], and xref:../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-embed-in-rpm-ostree[Embedding in a {op-system-ostree} image using image builder].
+
+[id="microshift-get-ready-install-rhde-steps_{context}"]
+== {op-system-bundle} installation steps
+
+For most installation types, you must also take the following steps:
+
+* Download the link:https://console.redhat.com/openshift/install/pull-secret[pull secret] from the Red{nbsp}Hat Hybrid Cloud Console.
+
+* Be ready to configure {microshift-short} by adding parameters and values to the {microshift-short} YAML configuration file. See xref:../microshift_configuring/microshift-using-config-yaml.adoc#microshift-configuring[Using the {microshift-short} configuration file] for more information.
+
+* Decide whether you need to configure storage for the application and tasks you are using in your {microshift-short} cluster, or disable the {microshift-short} storage plug-in completely.
+** For more information about creating volume groups and persistent volumes on {op-system-base}, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management].
+** For more information about the {microshift-short} plug-in, see xref:../microshift_storage/microshift-storage-plugin-overview.adoc#microshift-storage-plugin-overview[Dynamic storage using the LVMS plugin].
+
+* Configure networking settings according to the access needs you plan for your {microshift-short} cluster and applications. Consider whether you want to use single or dual-stack networks, configure a firewall, or configure routes.
+** For more information about {microshift-short} networking options, see xref:../microshift_networking/microshift-networking-settings.adoc#microshift-networking[Understanding networking settings].
+
+* Install the {oc-first} to access your cluster, see xref:../microshift_cli_ref/microshift-oc-cli-install.adoc#microshift-oc-cli-install[Getting started with the OpenShift CLI].
+
+[NOTE]
+====
+{op-system-rt-kernel} can be used where predictable latency is critical. Workload partitioning is also required for low-latency applications. For more information about low latency and the {op-system-rtk}, see xref:../microshift_configuring/microshift_low_latency/microshift-low-latency.adoc#microshift-low-latency[Configuring low latency].
+====
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc#microshift-deployment-mirror[Mirroring container images for disconnected installations].
diff --git a/microshift_install_kickstarts/_attributes b/microshift_install_kickstarts/_attributes
new file mode 120000
index 000000000000..f27fd275ea6b
--- /dev/null
+++ b/microshift_install_kickstarts/_attributes
@@ -0,0 +1 @@
+../_attributes/
\ No newline at end of file
diff --git a/microshift_install_kickstarts/images b/microshift_install_kickstarts/images
new file mode 120000
index 000000000000..e4c5bd02a10a
--- /dev/null
+++ b/microshift_install_kickstarts/images
@@ -0,0 +1 @@
+../images/
\ No newline at end of file
diff --git a/microshift_install_kickstarts/microshift-rhel-kickstarts.adoc b/microshift_install_kickstarts/microshift-rhel-kickstarts.adoc
new file mode 100644
index 000000000000..936f60212ab6
--- /dev/null
+++ b/microshift_install_kickstarts/microshift-rhel-kickstarts.adoc
@@ -0,0 +1,19 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/attributes-microshift.adoc[]
+[id="microshift-rhel-kickstarts"]
+= Using Kickstart files for installing {microshift-short} in {op-system-base}
+:context: microshift-rhel-kickstarts
+
+toc::[]
+
+Use a Kickstart file that automates the installation of an {op-system-base} image with {microshift-short}.
+
+include::modules/microshift-rhel-kickstarts-con.adoc[leveloffset=+1]
+
+include::modules/microshift-kickstart-prep.adoc[leveloffset=+2]
+
+include::modules/microshift-kickstart-rpm-install.adoc[leveloffset=+2]
+
+include::modules/microshift-kickstart-ostree-install.adoc[leveloffset=+2]
+
+include::modules/microshift-kickstart-bootc-install.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/microshift_install_kickstarts/modules b/microshift_install_kickstarts/modules
new file mode 120000
index 000000000000..43aab75b53c9
--- /dev/null
+++ b/microshift_install_kickstarts/modules
@@ -0,0 +1 @@
+../modules/
\ No newline at end of file
diff --git a/microshift_install_kickstarts/snippets b/microshift_install_kickstarts/snippets
new file mode 120000
index 000000000000..9d58b92e5058
--- /dev/null
+++ b/microshift_install_kickstarts/snippets
@@ -0,0 +1 @@
+../snippets/
\ No newline at end of file
diff --git a/microshift_install_rpm/microshift-install-rpm.adoc b/microshift_install_rpm/microshift-install-rpm.adoc
index 628522cb02d5..4ad0495574aa 100644
--- a/microshift_install_rpm/microshift-install-rpm.adoc
+++ b/microshift_install_rpm/microshift-install-rpm.adoc
@@ -23,8 +23,8 @@ include::modules/microshift-install-rpm-preparing.adoc[leveloffset=+1]
 * Download the link:https://console.redhat.com/openshift/install/pull-secret[pull secret] from the Red Hat Hybrid Cloud Console.
 * xref:../microshift_configuring/microshift-using-config-yaml.adoc#microshift-using-config-yaml[Configuring MicroShift].
 * For more options on partition configuration, read link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/performing_a_standard_rhel_9_installation/index#manual-partitioning_graphical-installation[Configuring Manual Partitioning].
-* For more information about resizing your existing LVs to free up capacity in your VGs, read link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#managing-lvm-volume-groups_configuring-and-managing-logical-volumes[Managing LVM Volume Groups].
-* For more information about creating VGs and PVs, read link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management].
+* For more information about resizing your existing LVs to free up capacity in your VGs, read link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#managing-lvm-volume-groups_configuring-and-managing-logical-volumes[Managing LVM Volume Groups].
+* For more information about creating VGs and PVs, read link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management].
 
 include::modules/microshift-install-rpms.adoc[leveloffset=+1]
 
diff --git a/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc b/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc
index d9b085736ffb..0d81396ea801 100644
--- a/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc
+++ b/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc
@@ -13,13 +13,6 @@ You can install optional RPM packages with {microshift-short} to provide additio
 
 When you install {microshift-short}, optional RPM packages can be added. Examples of optional RPMs include those designed to expand your network, add and manage operators, and manage applications. Use the following procedures to add the packages that you need.
 
-include::modules/microshift-install-rpms-olm.adoc[leveloffset=+2]
-
-//additional resources for installing OLM
-[role="_additional-resources"]
-.Additional resources
-* xref:../microshift_running_apps/microshift_operators/microshift-operators-olm.adoc#microshift-operators-olm[Using Operator Lifecycle Manager with {microshift-short}]
-
 include::modules/microshift-install-rpms-gitops.adoc[leveloffset=+2]
 
 //additional resources for installing GitOps
@@ -34,3 +27,18 @@ include::modules/microshift-install-multus-rpm.adoc[leveloffset=+2]
 .Additional resources
 * xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks]
 
+include::modules/microshift-install-rpms-olm.adoc[leveloffset=+2]
+
+//additional resources for installing OLM
+[role="_additional-resources"]
+.Additional resources
+* xref:../microshift_running_apps/microshift_operators/microshift-operators-olm.adoc#microshift-operators-olm[Using Operator Lifecycle Manager with {microshift-short}]
+
+
+//include::modules/microshift-install-rhoai.adoc[leveloffset=+2]
+
+//additional resources for installing RHOAI
+//[role="_additional-resources"]
+//.Additional resources
+//* xref:../microshift_ai/microshift-ai.adoc#microshift-ai[Using Red{nbsp}Hat OpenShift AI with {microshift-short}]
+//should be an attribute for rhoai by the time this merges
\ No newline at end of file
diff --git a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc
index c037663f5542..8a58e266e221 100644
--- a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc
+++ b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc
@@ -10,7 +10,7 @@ Embedding {microshift-short} containers in an `rpm-ostree` commit means that you
 
 include::modules/microshift-embed-microshift-image-offline-deploy.adoc[leveloffset=+1]
 
-include::modules/microshift-embed-microshift-update-osbuilder-worker.adoc[leveloffset=+1]
+include::modules/microshift-embed-registry-auth-image-building.adoc[leveloffset=+1]
 
 include::modules/microshift-embed-microshift-build-image.adoc[leveloffset=+1]
 
diff --git a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc
index 51103b7237a1..e7587586417b 100644
--- a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc
+++ b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc
@@ -6,10 +6,12 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-You can embed {microshift-short} into a {op-system-ostree-first} image. Use this guide to build a {op-system-base} image containing {microshift-short}.
+Use this guide to build a {op-system-base} image containing {microshift-short}.
 
 include::modules/microshift-preparing-for-image-building.adoc[leveloffset=+1]
 
+include::modules/microshift-embed-ostree-enable-eus-repos.adoc[leveloffset=+1]
+
 include::modules/microshift-adding-repos-to-image-builder.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -47,18 +49,22 @@ include::modules/microshift-add-blueprint-build-iso.adoc[leveloffset=+1]
 
 include::modules/microshift-download-iso-prep-for-use.adoc[leveloffset=+1]
 
-include::modules/microshift-provisioning-ostree.adoc[leveloffset=+1]
+include::modules/microshift-embed-kickstart-in-iso.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/composing_installing_and_managing_rhel_for_edge_images/index[{op-system-ostree} documentation]
-* xref:../microshift_install_rpm/microshift-install-rpm.adoc#microshift-install-system-requirements_microshift-install-rpm[System requirements for installing MicroShift]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/composing_installing_and_managing_rhel_for_edge_images/index[Composing, installing, and managing RHEL for Edge images]
+* xref:../microshift_install_rpm/microshift-install-rpm.adoc#microshift-install-system-requirements_microshift-install-rpm[System requirements for installing {microshift-short}]
 * link:https://console.redhat.com/openshift/install/pull-secret[Red Hat Hybrid Cloud Console pull secret]
 * xref:../microshift_networking/microshift-firewall.adoc#microshift-firewall-req-settings_microshift-firewall[Required firewall settings]
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_an_advanced_rhel_9_installation/creating-kickstart-files_installing-rhel-as-an-experienced-user[Creating a Kickstart file]
+* xref:../microshift_install_kickstarts/microshift-rhel-kickstarts.adoc#microshift-rhel-kickstarts[Using Kickstart files for embedding {microshift-short} in {op-system-base} installation]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/creating-kickstart-files_rhel-installer[Creating Kickstart files]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-script-file-format-reference_rhel-installer#kickstart-file-format_kickstart-script-file-format-reference[A.1. Kickstart file format]
 * link:https://access.redhat.com/solutions/60959[How to embed a Kickstart file into an ISO image]
 
+//Add modules about using the VM and getting the ISO up and running, then starting MicroShift...
+
 include::modules/microshift-accessing.adoc[leveloffset=+1]
 
 include::modules/microshift-accessing-cluster-locally.adoc[leveloffset=+2]
diff --git a/microshift_networking/microshift_multiple_networks/microshift-cni-multus-using.adoc b/microshift_networking/microshift_multiple_networks/microshift-cni-multus-using.adoc
index 4dfed648358b..e8a966ffcec5 100644
--- a/microshift_networking/microshift_multiple_networks/microshift-cni-multus-using.adoc
+++ b/microshift_networking/microshift_multiple_networks/microshift-cni-multus-using.adoc
@@ -26,4 +26,4 @@ include::modules/microshift-cni-multus-troubleshoot.adoc[leveloffset=+1]
 == Additional resources
 * xref:../../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks]
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html/networking/multiple-networks#nw-multus-ipam-object_configuring-additional-network[Configuration of IP address assignment for an additional network]
\ No newline at end of file
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/networking/multiple-networks#nw-multus-ipam-object_configuring-additional-network[Configuration of IP address assignment for an additional network]
\ No newline at end of file
diff --git a/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc b/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc
index 80c480a4ff15..f53c003064d9 100644
--- a/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc
+++ b/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc
@@ -3,6 +3,7 @@
 = About network policies
 include::_attributes/attributes-microshift.adoc[]
 :context: microshift-network-policies
+
 toc::[]
 
 Learn how network policies work for {microshift-short} to restrict or allow network traffic to pods in your cluster.
diff --git a/microshift_release_notes/microshift-4-19-release-notes.adoc b/microshift_release_notes/microshift-4-19-release-notes.adoc
new file mode 100644
index 000000000000..f65b4fc2a590
--- /dev/null
+++ b/microshift_release_notes/microshift-4-19-release-notes.adoc
@@ -0,0 +1,11 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-4-19-release-notes"]
+= {product-title} {product-version} release notes
+include::_attributes/attributes-microshift.adoc[]
+:context: release-notes
+
+Do not add or edit release notes here. Edit release notes directly in the branch that they are relevant for.
+
+Release note changes should be added/edited in their own PR.
+
+This file is here to allow builds to work.
\ No newline at end of file
diff --git a/microshift_running_apps/microshift-embed-apps-offline-use.adoc b/microshift_running_apps/microshift-embed-apps-offline-use.adoc
index b51af75bec50..fb799ded1ee3 100644
--- a/microshift_running_apps/microshift-embed-apps-offline-use.adoc
+++ b/microshift_running_apps/microshift-embed-apps-offline-use.adoc
@@ -19,7 +19,7 @@ include::modules/microshift-embed-images-offline-use.adoc[leveloffset=+1]
 
 * xref:../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-creating-ostree-iso_microshift-embed-in-rpm-ostree[Creating the {op-system-ostree} image]
 
-* xref:../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-add-blueprint-build-iso_microshift-embed-in-rpm-ostree[Add the blueprint to Image Builder and build the ISO]
+* xref:../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-add-blueprint-build-iso_microshift-embed-in-rpm-ostree[Add the blueprint to image builder and build the ISO]
 
 * xref:../microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc#microshift-download-iso-prep-for-use_microshift-embed-in-rpm-ostree[Download the ISO and prepare it for use]
 
diff --git a/microshift_running_apps/microshift-embedding-apps-tutorial.adoc b/microshift_running_apps/microshift-embedding-apps-tutorial.adoc
index 0fd364bc9b32..c25990d6994c 100644
--- a/microshift_running_apps/microshift-embedding-apps-tutorial.adoc
+++ b/microshift_running_apps/microshift-embedding-apps-tutorial.adoc
@@ -19,7 +19,7 @@ include::modules/microshift-adding-app-rpms-to-blueprint.adoc[leveloffset=+2]
 //additional resources for adding app rpms to blueprint
 [role="_additional-resources"]
 .Additional resources
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/composing-a-rhel-for-edge-image-using-image-builder-command-line_composing-installing-managing-rhel-for-edge-images#doc-wrapper[Composing a {op-system-ostree} image using the Image Builder CLI]
+* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/composing-a-rhel-for-edge-image-using-image-builder-command-line_composing-installing-managing-rhel-for-edge-images#doc-wrapper[Composing a {op-system-ostree} image using the image builder CLI]
 
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/composing-a-rhel-for-edge-image-using-image-builder-command-line_composing-installing-managing-rhel-for-edge-images#network_based_deployments_workflow[Network-based deployments workflow]
 
@@ -41,4 +41,4 @@ include::modules/microshift-adding-app-rpms-to-blueprint.adoc[leveloffset=+2]
 
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html-single/composing_installing_and_managing_rhel_for_edge_images/index#composing-a-rhel-for-edge-image-using-image-builder-command-line_composing-installing-managing-rhel-for-edge-images[Composing a {op-system-ostree} image using image builder command-line]
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html-single/composing_installing_and_managing_rhel_for_edge_images/index#edge-image-builder-system-requirements_setting-up-image-builder[Image Builder system requirements]
+* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html-single/composing_installing_and_managing_rhel_for_edge_images/index#edge-image-builder-system-requirements_setting-up-image-builder[Image builder system requirements]
diff --git a/microshift_storage/volume-snapshots-microshift.adoc b/microshift_storage/volume-snapshots-microshift.adoc
index 1af7b634d502..43e2c063daf7 100644
--- a/microshift_storage/volume-snapshots-microshift.adoc
+++ b/microshift_storage/volume-snapshots-microshift.adoc
@@ -28,11 +28,11 @@ Only the logical volume manager storage (LVMS) plugin CSI driver is supported by
 
 * xref:../microshift_storage/understanding-persistent-storage-microshift.adoc#persistent-volumes_understanding-persistent-storage-microshift[Understanding persistent volumes]
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes[Configuring and managing logical volumes]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/managing-lvm-volume-groups_configuring-and-managing-logical-volumes[Managing LVM volume groups] ({op-system-base} documentation)
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-snapshots[CSI snapshots: `VolumeSnapshot` APIs]
+* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-snapshots[CSI snapshots: `VolumeSnapshot` APIs] ({OCP} documentation)
 
-* link:https://docs.openshift.com/container-platform/{ocp-version}/rest_api/storage_apis/volumesnapshot-snapshot-storage-k8s-io-v1.html[VolumeSnapshot API specification]
+* link:https://docs.openshift.com/container-platform/{ocp-version}/rest_api/storage_apis/volumesnapshot-snapshot-storage-k8s-io-v1.html[VolumeSnapshot API specification] ({OCP} documentation)
 
 include::modules/microshift-lvm-thin-volumes.adoc[leveloffset=+1]
 
@@ -40,11 +40,9 @@ include::modules/microshift-lvm-thin-volumes.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* To create a thin pool on the host, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes[Creating and managing thin provisioned volumes]
+* To create a thin pool on the host, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/basic-logical-volume-management_configuring-and-managing-logical-volumes#creating-thin-logical-volume_creating-logical-volumes[Creating a thin logical volume] ({op-system-base} documentation)
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes#creating-thinly-provisioned-logical-volumes_creating-and-managing-thin-provisioned-volumes[Creating thinly provisioned logical volumes]
-
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes[Configuring and managing thin provisioned volumes]
+* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes[Configuring and managing thin provisioned volumes]
 
 * xref:../microshift_storage/volume-snapshots-microshift.adoc#microshift-storage-classes_volume-snapshots-microshift[Storage classes]
 
@@ -56,7 +54,7 @@ include::modules/microshift-storage-classes.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/dynamic-provisioning#defining-storage-classes_dynamic-provisioning[Defining storage classes]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/storage/dynamic-provisioning#defining-storage-classes_dynamic-provisioning[Defining storage classes]
 
 * xref:../microshift_storage/microshift-storage-plugin-overview.adoc#microshift-storage-device-classes_microshift-storage-plugin-overview[Storage device classes]
 
@@ -66,7 +64,7 @@ include::modules/microshift-storage-vol-snapshot-class.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/{ocp-version}/storage/container_storage_interface/persistent-storage-csi-snapshots.html#volume-snapshot-crds[OpenShift CSI volume snapshots]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-snapshots-overview_persistent-storage-csi-snapshots[OpenShift CSI volume snapshots]
 
 include::modules/microshift-storage-about-vol-snapshots.adoc[leveloffset=+1]
 
@@ -80,7 +78,7 @@ include::modules/microshift-storage-vol-snapshot-restore.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-snapshots-provision_persistent-storage-csi-snapshots[Restoring a volume snapshot]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-snapshots-restore_persistent-storage-csi-snapshots[Restoring a volume snapshot]
 
 //this module is reused from OCP; take care in editing for MicroShift
 include::modules/persistent-storage-csi-snapshots-delete.adoc[leveloffset=+2]
@@ -91,8 +89,9 @@ include::modules/microshift-storage-volume-cloning.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/{ocp-version}/storage/container_storage_interface/persistent-storage-csi-cloning.html[CSI volume cloning]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/storage/using-container-storage-interface-csi#persistent-storage-csi-cloning[CSI volume cloning]
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/configuring-persistent-storage#lvms-creating-volume-clones-in-single-node-openshift_logical-volume-manager-storage[LVMS volume cloning for Single-Node OpenShift]
+//* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/configuring-persistent-storage#lvms-creating-volume-clones-in-single-node-openshift_logical-volume-manager-storage[LVMS volume cloning for Single-Node OpenShift]
+//cannot find new link
 
 * To configure the host to enable cloning, see xref:../microshift_storage/volume-snapshots-microshift.adoc#microshift-lvm-thin-volumes_volume-snapshots-microshift[About LVM thin volumes]
diff --git a/microshift_support/microshift-remote-cluster-monitoring.adoc b/microshift_support/microshift-remote-cluster-monitoring.adoc
new file mode 100644
index 000000000000..d2105142c92e
--- /dev/null
+++ b/microshift_support/microshift-remote-cluster-monitoring.adoc
@@ -0,0 +1,20 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-remote-cluster-monitoring"]
+= Remote health monitoring with a connected cluster
+include::_attributes/attributes-microshift.adoc[]
+:context: microshift-remote-cluster-monitoring
+
+toc::[]
+
+Telemetry and configuration data about your cluster can be collected and reported to Red{nbsp}Hat.
+
+include::modules/microshift-about-remote-health-monitoring.adoc[leveloffset=+1]
+
+include::modules/microshift-info-collected-telemetry.adoc[leveloffset=+1]
+
+include::modules/microshift-opt-out-telemetry.adoc[leveloffset=+1]
+
+[id="additional-resources_microshift-remote-cluster-monitoring_{context}"]
+== Additional resources
+
+* xref:../microshift_configuring/microshift-using-config-yaml.adoc#microshift-config-snippets_microshift-configuring[Using configuration snippets].
\ No newline at end of file
diff --git a/microshift_troubleshooting/microshift-audit-logs.adoc b/microshift_troubleshooting/microshift-audit-logs.adoc
index 10900f385ca9..e393a1085488 100644
--- a/microshift_troubleshooting/microshift-audit-logs.adoc
+++ b/microshift_troubleshooting/microshift-audit-logs.adoc
@@ -1,5 +1,5 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="audit-logs-with-microshift"]
+[id="microshift-audit-logs"]
 = Checking audit logs
 include::_attributes/attributes-microshift.adoc[]
 :context: microshift-audit-logs
diff --git a/microshift_troubleshooting/microshift-things-to-know.adoc b/microshift_troubleshooting/microshift-things-to-know.adoc
index e52483cedb1f..b9a45ce00b58 100644
--- a/microshift_troubleshooting/microshift-things-to-know.adoc
+++ b/microshift_troubleshooting/microshift-things-to-know.adoc
@@ -2,11 +2,11 @@
 [id="microshift-things-to-know"]
 = Responsive restarts and security certificates
 include::_attributes/attributes-microshift.adoc[]
-:context: microshift-configuring
+:context: microshift-things-to-know
 
 toc::[]
 
-{product-title} responds to system configuration changes and restarts after alterations are detected, including IP address changes, clock adjustments, and security certificate age.
+{microshift-short} responds to system configuration changes and restarts after alterations are detected, including IP address changes, clock adjustments, and security certificate age.
 
 [id="microshift-ip-address-clock-changes_{context}"]
 == IP address changes or clock adjustments
diff --git a/microshift_troubleshooting/microshift-troubleshoot-backup-restore.adoc b/microshift_troubleshooting/microshift-troubleshoot-backup-restore.adoc
index 40c1f72ee396..a15b4e19feb3 100644
--- a/microshift_troubleshooting/microshift-troubleshoot-backup-restore.adoc
+++ b/microshift_troubleshooting/microshift-troubleshoot-backup-restore.adoc
@@ -2,7 +2,7 @@
 [id="microshift-troubleshoot-backup-restore"]
 = Troubleshooting data backup and restore
 include::_attributes/attributes-microshift.adoc[]
-:context: microshift-troubleshoot-data-backup-and-restore
+:context: microshift-troubleshoot-backup-and-restore
 
 toc::[]
 
diff --git a/microshift_updating/microshift-update-options.adoc b/microshift_updating/microshift-update-options.adoc
index 8777820e5897..64d460e6ed2b 100644
--- a/microshift_updating/microshift-update-options.adoc
+++ b/microshift_updating/microshift-update-options.adoc
@@ -14,6 +14,8 @@ You can update {op-system-ostree-first} images or {op-system-base-full} with or
 
 include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+1]
 
+include::snippets/microshift-unsupported-config-warn.adoc[leveloffset=+1]
+
 [id="microshift-update-options-standalone-updates_{context}"]
 == Standalone {microshift-short} updates
 Consider the following when planning to update {microshift-short}:
@@ -46,9 +48,9 @@ To begin a {microshift-short} update by embedding in a {op-system-ostree} image,
 
 * xref:../microshift_updating/microshift-update-rpms-ostree.adoc#microshift-update-rpms-ostree[Applying updates on an OSTree system]
 
-To understand more about Greenboot, see the following documentation:
+To understand more about greenboot, see the following documentation:
 
-* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The Greenboot health check]
+* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The greenboot health check]
 * xref:../microshift_running_apps/microshift-greenboot-workload-scripts.adoc#microshift-greenboot-workload-scripts[Greenboot workload health check scripts]
 
 [id="microshift-update-options-manual-rpm-updates_{context}"]
@@ -61,10 +63,7 @@ You can update {microshift-short} manually on a non-OSTree system such as {op-sy
 
 * xref:../microshift_updating/microshift-update-rpms-manually.adoc#microshift-update-rpms-manually[About updating MicroShift RPMs manually]
 
-[WARNING]
-====
-Keeping versions in a supported configuration of {op-system-bundle} can require updating {microshift-short} and {op-system-base} at the same time. Ensure that your version of {op-system-base} is compatible with the version of {microshift-short} you are updating to, especially if you are updating {microshift-short} across two minor versions. Otherwise, you can create an unsupported configuration, break your cluster, or both.
-====
+include::modules/microshift-updates-rhde-config-rhel-repos.adoc[leveloffset=+3]
 
 [id="microshift-update-options-standalone-rhel-updates_{context}"]
 == Standalone {op-system-ostree} updates
@@ -73,7 +72,7 @@ You can update {op-system-ostree} or {op-system-base} without updating {microshi
 //additional resources for updating RHEL alone
 [role="_additional-resources"]
 .Additional resources
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/index[Managing RHEL for Edge images]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/index[Composing, installing, and managing RHEL for Edge images]
 
 [id="microshift-update-options-simultaneous-microshift-rhel-updates_{context}"]
 == Simultaneous {microshift-short} and operating system updates
@@ -87,9 +86,9 @@ You can update {op-system-ostree} or {op-system-base} and update {microshift-sho
 //additional resources for updating RHEL and MicroShift
 [role="_additional-resources"]
 .Additional resources
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/index[Managing RHEL for Edge images]
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/index[Composing a customized RHEL system image]
+* link:https://access.redhat.com/articles/rhel-eus#c5[How to Access EUS]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/index[Composing a customized RHEL system image]
 * xref:../microshift_updating/microshift-update-rpms-ostree.adoc#microshift-update-rpms-ostree[Applying updates on an OSTree system]
 * xref:../microshift_updating/microshift-update-rpms-manually.adoc#microshift-update-rpms-manually[Applying updates manually with RPMs]
-* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The Greenboot system health check]
+* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The greenboot system health check]
 * xref:../microshift_running_apps/microshift-greenboot-workload-scripts.adoc#microshift-greenboot-workload-scripts[Greenboot workload scripts]
diff --git a/microshift_updating/microshift-update-rpms-manually.adoc b/microshift_updating/microshift-update-rpms-manually.adoc
index 005bbc559682..5750f118b1f7 100644
--- a/microshift_updating/microshift-update-rpms-manually.adoc
+++ b/microshift_updating/microshift-update-rpms-manually.adoc
@@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-Updating {product-title} for non-OSTree systems such as {op-system-base-full} requires updating the RPMs. For patch releases, such as 4.18.1 to 4.18.2, simply update the RPMs. For minor-version release updates, add the step of enabling the update repository using your subscription manager.
+Updating {product-title} for non-OSTree systems such as {op-system-base-full} requires updating the RPMs. For patch releases, such as 4.19.1 to 4.19.2, simply update the RPMs. For minor-version release updates, add the step of enabling the update repository using your subscription manager.
 
 [NOTE]
 ====
diff --git a/microshift_updating/microshift-update-rpms-ostree.adoc b/microshift_updating/microshift-update-rpms-ostree.adoc
index 06eee0f3dc9e..438e355186d4 100644
--- a/microshift_updating/microshift-update-rpms-ostree.adoc
+++ b/microshift_updating/microshift-update-rpms-ostree.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 Updating {microshift-short} on an `rpm-ostree` system such as {op-system-ostree-first} requires building a new {op-system-ostree} image containing the new version of {microshift-short} and any associated optional RPMs. After you have the `rpm-ostree` image with {microshift-short} embedded, direct your system to boot into that operating system image.
 
-The procedures are the same for minor-version and patch updates. For example, use the same steps to upgrade from 4.17 to 4.18 or from 4.18.2 to 4.18.3.
+The procedures are the same for minor-version and patch updates. For example, use the same steps to upgrade from 4.18 to 4.19 or from 4.19.2 to 4.19.3.
 
 [NOTE]
 ====
diff --git a/microshift_welcome/index.adoc b/microshift_welcome/index.adoc
index 3fe3870cecc6..b8bf81bfe768 100644
--- a/microshift_welcome/index.adoc
+++ b/microshift_welcome/index.adoc
@@ -21,7 +21,7 @@ To browse the {microshift-short} {product-version} documentation, use one of the
 To get started with {microshift-short}, use the following links:
 
 //text is in main assembly for the sake of cross references
-* xref:../microshift_release_notes/microshift-4-18-release-notes.adoc#microshift-4-18-release-notes[{product-title} release notes]
+* xref:../microshift_release_notes/microshift-4-19-release-notes.adoc#microshift-4-19-release-notes[{product-title} release notes]
 * xref:../microshift_install_rpm/microshift-install-rpm.adoc#microshift-install-rpm[Installing {product-title}]
 
 For related information, use the following links:
diff --git a/migrating_from_ocp_3_to_4/index.adoc b/migrating_from_ocp_3_to_4/index.adoc
index cbf073deaa74..7537fd22ef17 100644
--- a/migrating_from_ocp_3_to_4/index.adoc
+++ b/migrating_from_ocp_3_to_4/index.adoc
@@ -14,7 +14,7 @@ Before migrating from {product-title} 3 to 4, you can check xref:../migrating_fr
 
 * xref:../architecture/architecture.adoc#architecture[Architecture]
 * xref:../architecture/architecture-installation.adoc#architecture-installation[Installation and update]
-* xref:../storage/index.adoc#index[Storage], xref:../networking/understanding-networking.adoc#understanding-networking[network], xref:../observability/logging/cluster-logging.adoc#cluster-logging[logging], xref:../security/index.adoc#index[security], and xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[monitoring considerations]
+* xref:../storage/index.adoc#index[Storage], xref:../networking/understanding-networking.adoc#understanding-networking[network], xref:../security/index.adoc#index[security], and xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[monitoring considerations]
 
 [id="mtc-3-to-4-overview-planning-network-considerations-mtc"]
 == Planning network considerations
diff --git a/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc b/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc
index 7b9c7a5a62f9..89f20c08386d 100644
--- a/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc
+++ b/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc
@@ -180,7 +180,7 @@ For information on OVN-Kubernetes features that are similar to features in the O
 
 [WARNING]
 ====
-You should install {product-title} 4 with the OVN-Kubernetes network plugin because it is not possible to upgrade a cluster to {product-title} 4.17 if it is using the OpenShift SDN network plugin.
+You should install {product-title} 4 with the OVN-Kubernetes network plugin because it is not possible to upgrade a cluster to {product-title} 4.17 or later if it is using the OpenShift SDN network plugin.
 ====
 
 [id="migration-preparing-logging"]
@@ -193,22 +193,16 @@ Review the following logging changes to consider when transitioning from {produc
 
 {product-title} 4 provides a simple deployment mechanism for OpenShift Logging, by using a Cluster Logging custom resource.
 
-For more information, see xref:../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying_cluster-logging-deploying[Installing OpenShift Logging].
-
 [discrete]
 ==== Aggregated logging data
 
 You cannot transition your aggregate logging data from {product-title} 3.11 into your new {product-title} 4 cluster.
 
-For more information, see xref:../observability/logging/cluster-logging.adoc#cluster-logging-about_cluster-logging[About OpenShift Logging].
-
 [discrete]
 ==== Unsupported logging configurations
 
 Some logging configurations that were available in {product-title} 3.11 are no longer supported in {product-title} {product-version}.
 
-For more information on the explicitly unsupported logging cases, see the xref:../observability/logging/cluster-logging-support.adoc#cluster-logging-support[logging support documentation].
-
 [id="migration-preparing-security"]
 === Security considerations
 
@@ -253,4 +247,4 @@ Review the following monitoring changes when transitioning from {product-title}
 
 The default alert that triggers to ensure the availability of the monitoring structure was called `DeadMansSwitch` in {product-title} 3.11. This was renamed to `Watchdog` in {product-title} 4. If you had PagerDuty integration set up with this alert in {product-title} 3.11, you must set up the PagerDuty integration for the `Watchdog` alert in {product-title} 4.
 
-For more information, see xref:../observability/monitoring/managing-alerts.adoc#applying-custom-alertmanager-configuration_managing-alerts[Applying custom Alertmanager configuration].
+For more information, see xref:../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alert-routing-default-platform-alerts_configuring-alerts-and-notifications[Configuring alert routing for default platform alerts].
diff --git a/migration_toolkit_for_containers/about-mtc.adoc b/migration_toolkit_for_containers/about-mtc.adoc
index 384ca9fc9d83..e1a9e6a9921c 100644
--- a/migration_toolkit_for_containers/about-mtc.adoc
+++ b/migration_toolkit_for_containers/about-mtc.adoc
@@ -26,6 +26,7 @@ See xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc
 * Configuring your migration plan to exclude resources, support large-scale migrations, and enable automatic PV resizing for direct volume migration.
 
 include::modules/migration-mtc-support.adoc[leveloffset=+1]
+include::modules/mtc-operator-supported.adoc[leveloffset=+2]
 include::modules/migration-terminology.adoc[leveloffset=+1]
 include::modules/migration-mtc-workflow.adoc[leveloffset=+1]
 include::modules/migration-understanding-data-copy-methods.adoc[leveloffset=+1]
diff --git a/modules/abi-c3-resources-services.adoc b/modules/abi-c3-resources-services.adoc
new file mode 100644
index 000000000000..d076f648faf7
--- /dev/null
+++ b/modules/abi-c3-resources-services.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-agent-based-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="abi-c3-resources-services_{context}"]
+= Creating {oci-c3-no-rt} infrastructure resources and services
+
+You must create an {oci-c3-short} environment on your virtual machine (VM) shape. By creating this environment, you can install {product-title} and deploy a cluster on an infrastructure that supports a wide range of cloud options and strong security policies. Having prior knowledge of {oci} components can help you with understanding the concept of {oci} resources and how you can configure them to meet your organizational needs.
+
+[IMPORTANT]
+====
+To ensure compatibility with {product-title}, you must set `A` as the record type for each DNS record and name records as follows:
+
+* `api.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `api-int.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `*.apps.<cluster_name>.<base_domain>`, which targets the `ingressVIP` parameter of the Ingress load balancer
+
+The `api.{asterisk}` and `api-int.{asterisk}` DNS records relate to control plane machines, so you must ensure that all nodes in your installed {product-title} cluster can access these DNS records.
+====
+
+.Prerequisites
+
+* You configured an {oci} account to host the {product-title} cluster.
+See "Access and Considerations" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer] (Oracle documentation).
+
+.Procedure
+
+* Create the required {oci-c3-short} resources and services.
++
+For more information, see "Terraform Script Execution" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer] (Oracle documentation).
\ No newline at end of file
diff --git a/modules/abi-oci-resources-services.adoc b/modules/abi-oci-resources-services.adoc
index f9556baf5f6b..6f6d9ee3c954 100644
--- a/modules/abi-oci-resources-services.adoc
+++ b/modules/abi-oci-resources-services.adoc
@@ -14,11 +14,11 @@ The Agent-based Installer method for installing an {product-title} cluster on {o
 ====
 To ensure compatibility with {product-title}, you must set `A` as the record type for each DNS record and name records as follows:
 
-* `api.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer.
-* `api-int.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer.
-* `*.apps.<cluster_name>.<base_domain>`, which targets the `ingressVIP` parameter of the Ingress load balancer.
+* `api.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `api-int.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `*.apps.<cluster_name>.<base_domain>`, which targets the `ingressVIP` parameter of the Ingress load balancer
 
-The `api.+*+` and `api-int.+*+` DNS records relate to control plane machines, so you must ensure that all nodes in your installed {product-title} cluster can access these DNS records.
+The `api.{asterisk}` and `api-int.{asterisk}` DNS records relate to control plane machines, so you must ensure that all nodes in your installed {product-title} cluster can access these DNS records.
 ====
 
 .Prerequisites
@@ -27,4 +27,8 @@ The `api.+*+` and `api-int.+*+` DNS records relate to control plane machines, so
 
 .Procedure
 
-* Create the required {oci} resources and services. See link:https://docs.oracle.com/iaas/Content/openshift-on-oci/agent-prereq.htm[{oci} Resources Needed for Using the Agent-based Installer (Oracle documentation)].
+* Create the required {oci} resources and services.
++
+For installations in a connected environment, see link:https://docs.oracle.com/en-us/iaas/Content/openshift-on-oci/agent-installer-using-stack.htm[Provisioning Cluster Infrastructure Using Terraform (Oracle documentation)].
++
+For installations in a disconnected environment, see link:https://docs.oracle.com/iaas/Content/openshift-on-oci/agent-prereq.htm[Provisioning OCI Resources for the Agent-based Installer in Disconnected Environments (Oracle documentation)].
diff --git a/modules/abi-pca-resources-services.adoc b/modules/abi-pca-resources-services.adoc
new file mode 100644
index 000000000000..a93ec6dc14d1
--- /dev/null
+++ b/modules/abi-pca-resources-services.adoc
@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-pca-agent-based-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="abi-pca-resources-services_{context}"]
+= Creating {oci-pca-no-rt} infrastructure resources and services
+
+You must create an {oci-pca-short} environment on your virtual machine (VM) shape. By creating this environment, you can install {product-title} and deploy a cluster on an infrastructure that supports a wide range of cloud options and strong security policies. Having prior knowledge of {oci} components can help you with understanding the concept of {oci} resources and how you can configure them to meet your organizational needs.
+
+[IMPORTANT]
+====
+To ensure compatibility with {product-title}, you must set `A` as the record type for each DNS record and name records as follows:
+
+* `api.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `api-int.<cluster_name>.<base_domain>`, which targets the `apiVIP` parameter of the API load balancer
+* `*.apps.<cluster_name>.<base_domain>`, which targets the `ingressVIP` parameter of the Ingress load balancer
+
+The `api.{asterisk}` and `api-int.{asterisk}` DNS records relate to control plane machines, so you must ensure that all nodes in your installed {product-title} cluster can access these DNS records.
+====
+
+.Prerequisites
+
+* You configured an {oci} account to host the {product-title} cluster. See "Access and Considerations" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance] (Oracle documentation).
+
+.Procedure
+
+* Create the required {oci-pca-short} resources and services.
++
+For more information, see "Terraform Script Execution" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance] (Oracle documentation).
\ No newline at end of file
diff --git a/modules/about-developer-perspective.adoc b/modules/about-developer-perspective.adoc
index 22cea552cb2f..a131d71c8d16 100644
--- a/modules/about-developer-perspective.adoc
+++ b/modules/about-developer-perspective.adoc
@@ -31,4 +31,4 @@ The *Developer* perspective provides workflows specific to developer use cases,
 You can use the *Topology* view to display applications, components, and workloads of your project. If you have no workloads in the project, the *Topology* view will show some links to create or import them. You can also use the *Quick Search* to import components directly.
 
 .Additional resources
-See link:https://docs.openshift.com/container-platform/4.17/applications/odc-viewing-application-composition-using-topology-view.html[Viewing application composition using the Topology] view for more information on using the *Topology* view in *Developer* perspective.
+See link:https://docs.openshift.com/container-platform/4.18/applications/odc-viewing-application-composition-using-topology-view.html[Viewing application composition using the Topology] view for more information on using the *Topology* view in *Developer* perspective.
diff --git a/modules/about-toolbox.adoc b/modules/about-toolbox.adoc
index bf771504d65c..6cda61ced3ee 100644
--- a/modules/about-toolbox.adoc
+++ b/modules/about-toolbox.adoc
@@ -7,7 +7,7 @@
 = About `toolbox`
 
 ifndef::openshift-origin[]
-`toolbox` is a tool that starts a container on a {op-system-first} system. The tool is primarily used to start a container that includes the required binaries and plugins that are needed to run commands such as `sosreport` and `redhat-support-tool`.
+`toolbox` is a tool that starts a container on a {op-system-first} system. The tool is primarily used to start a container that includes the required binaries and plugins that are needed to run commands such as `sosreport`.
 
 The primary purpose for a `toolbox` container is to gather diagnostic information and to provide it to Red Hat Support. However, if additional diagnostic tools are required, you can add RPM packages or run an image that is an alternative to the standard support tools image.
 endif::openshift-origin[]
diff --git a/modules/accessing-metrics-outside-cluster.adoc b/modules/accessing-metrics-outside-cluster.adoc
index d8788c0a52df..75823aeb4aa3 100644
--- a/modules/accessing-metrics-outside-cluster.adoc
+++ b/modules/accessing-metrics-outside-cluster.adoc
@@ -1,6 +1,5 @@
 // Module included in the following assemblies:
 //
-// * observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc
 // * observability/monitoring/accessing-third-party-monitoring-apis.adoc
 
 :_mod-docs-content-type: PROCEDURE
@@ -35,7 +34,7 @@ $ TOKEN=$(oc whoami -t)
 +
 [source,terminal]
 ----
-$ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.status.ingress[].host})
+$ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath='{.status.ingress[].host}')
 ----
 
 . Set the namespace to the namespace in which your service is running by using the following command:
diff --git a/modules/accessing-running-pods.adoc b/modules/accessing-running-pods.adoc
index 656f9a0257df..2ead4efe3e34 100644
--- a/modules/accessing-running-pods.adoc
+++ b/modules/accessing-running-pods.adoc
@@ -10,12 +10,12 @@ You can review running pods dynamically by opening a shell inside a pod or by ga
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 
diff --git a/modules/adding-ibm-z-lpar-agent-day-2.adoc b/modules/adding-ibm-z-lpar-agent-day-2.adoc
new file mode 100644
index 000000000000..f37206b9d175
--- /dev/null
+++ b/modules/adding-ibm-z-lpar-agent-day-2.adoc
@@ -0,0 +1,124 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_with_agent_based_installer/prepare-pxe-assets-agent.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="adding-ibm-z-lpar-agents-day-2_{context}"]
+= Adding {ibm-z-title} agents in a Logical Partition (LPAR) to an existing cluster
+
+In {product-title} {product-version}, the `.ins` and `initrd.img.addrsize` files are not automatically generated as part of the boot-artifacts for an existing cluster. You must manually generate these files for {ibm-z-name} clusters running in an LPAR.
+
+The `.ins` file is a special file that includes installation data and is present on the FTP server. You can access this file from the hardware management console (HMC) system. This file contains details such as mapping of the location of installation data on the disk or FTP server and the memory locations where the data is to be copied.
+
+.Prerequisites
+
+* A running file server with access to the LPAR.
+
+.Procedure
+
+. Generate the `.ins` and `initrd.img.addrsize` files:
+
+.. Retrieve the size of the `kernel` and `initrd` by running the following commands:
++
+[source,terminal]
+----
+$ KERNEL_IMG_PATH='./kernel.img'
+----
++
+[source,terminal]
+----
+$ INITRD_IMG_PATH='./initrd.img'
+----
++
+[source,terminal]
+----
+$ CMDLINE_PATH='./generic.prm'
+----
++
+[source,terminal]
+----
+$ kernel_size=$(stat -c%s $KERNEL_IMG_PATH)
+----
++
+[source,terminal]
+----
+$ initrd_size=$(stat -c%s $INITRD_IMG_PATH)
+----
+
+.. Round up the `kernel` size to the next Mebibytes (MiB) boundary by running the following command:
++
+[source,terminal]
+----
+$ BYTE_PER_MIB=$(( 1024 * 1024 )) offset=$(( (kernel_size + BYTE_PER_MIB - 1) / BYTE_PER_MIB * BYTE_PER_MIB ))
+----
+
+.. Create the kernel binary patch file that contains the `initrd` address and size by running the following commands:
++
+[source,terminal]
+----
+$ INITRD_IMG_NAME=$(echo $INITRD_IMG_PATH | rev | cut -d '/' -f 1 | rev)
+----
++
+[source,terminal]
+----
+$ KERNEL_OFFSET=0x00000000
+----
++
+[source,terminal]
+----
+$ KERNEL_CMDLINE_OFFSET=0x00010480
+----
++
+[source,terminal]
+----
+$ INITRD_ADDR_SIZE_OFFSET=0x00010408
+----
++
+[source,terminal]
+----
+$ OFFSET_HEX=(printf '0x%08x\n' offset)
+----
+
+.. Convert the address and size to binary format by running the following command:
++
+[source,terminal]
+----
+$ printf "$(printf '%016x\n' $initrd_size)" | xxd -r -p > temp_size.bin
+----
+
+.. Merge the address and size binaries by running the following command:
++
+[source,terminal]
+----
+$ cat temp_address.bin temp_size.bin > "$INITRD_IMG_NAME.addrsize"
+----
+
+.. Clean up temporary files by running the following command:
++
+[source,terminal]
+----
+$ rm -rf temp_address.bin temp_size.bin
+----
+
+.. Create the `.ins` file by running the following command:
++
+[source,terminal]
+----
+$ cat > generic.ins <<EOF
+$KERNEL_IMG_PATH $KERNEL_OFFSET
+$INITRD_IMG_PATH $OFFSET_HEX
+$INITRD_IMG_NAME.addrsize $INITRD_ADDR_SIZE_OFFSET
+$CMDLINE_PATH $KERNEL_CMDLINE_OFFSET
+EOF
+----
++
+[NOTE]
+====
+The file is based on the paths of the `kernel.img`, `initrd.img`, `initrd.img.addrsize`, and `cmdline` files and the memory locations where the data is to be copied.
+====
+
+. Transfer the `initrd`, `kernel`, `generic.ins`, and `initrd.img.addrsize` parameter files to the file server. For more information, see link:https://www.ibm.com/docs/en/linux-on-systems?topic=bl-booting-linux-in-lpar-mode[Booting Linux in LPAR mode] (IBM documentation).
+
+. Start the machine.
+
+. Repeat the procedure for all other machines in the cluster.
\ No newline at end of file
diff --git a/modules/adding-ibm-z-lpar-agent.adoc b/modules/adding-ibm-z-lpar-agent.adoc
index 139758db37e7..30dcb264ba04 100644
--- a/modules/adding-ibm-z-lpar-agent.adoc
+++ b/modules/adding-ibm-z-lpar-agent.adoc
@@ -23,17 +23,19 @@ rd.neednet=1 cio_ignore=all,!condev \
 console=ttysclp0 \
 ignition.firstboot ignition.platform.id=metal
 coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \// <1>
-coreos.inst.persistent-kargs=console=ttysclp0
+coreos.inst.persistent-kargs=console=ttysclp0 \
 ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \// <2>
 rd.znet=qeth,<network_adaptor_range>,layer2=1
 rd.<disk_type>=<adapter> \// <3>
-zfcp.allow_lun_scan=0
-ai.ip_cfg_override=1 \//
+fips=1 \// <4>
+zfcp.allow_lun_scan=0 \
+ai.ip_cfg_override=1 \
 random.trust_cpu=on rd.luks.options=discard
 ----
 <1> For the `coreos.live.rootfs_url` artifact, specify the matching `rootfs` artifact for the `kernel` and `initramfs` that you are starting. Only HTTP and HTTPS protocols are supported.
 <2> For the `ip` parameter, manually assign the IP address, as described in _Installing a cluster with z/VM on IBM Z and IBM LinuxONE_.
 <3> For installations on DASD-type disks, use `rd.dasd` to specify the DASD where {op-system-first} is to be installed. For installations on FCP-type disks, use `rd.zfcp=<adapter>,<wwpn>,<lun>` to specify the FCP disk where {op-system} is to be installed.
+<4> To enable FIPS mode, specify `fips=1`. This entry is required in addition to setting the `fips` parameter to `true` in the `install-config.yaml` file.
 +
 [NOTE]
 ====
diff --git a/modules/advanced-node-tuning-hosted-cluster.adoc b/modules/advanced-node-tuning-hosted-cluster.adoc
index 62f92ed3beae..66a73e040e02 100644
--- a/modules/advanced-node-tuning-hosted-cluster.adoc
+++ b/modules/advanced-node-tuning-hosted-cluster.adoc
@@ -114,7 +114,8 @@ After the nodes are available, the containerized TuneD daemon calculates the req
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator
+$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io \
+  -n openshift-cluster-node-tuning-operator
 ----
 +
 .Example output
@@ -130,7 +131,8 @@ rendered             123m
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
+$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io \
+  -n openshift-cluster-node-tuning-operator
 ----
 +
 .Example output
@@ -149,7 +151,8 @@ Both of the worker nodes in the new `NodePool` have the `openshift-node-hugepage
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
+$ oc --kubeconfig="<hosted_cluster_kubeconfig>" \
+  debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
 ----
 +
 .Example output
diff --git a/modules/agent-installer-architectures.adoc b/modules/agent-installer-architectures.adoc
index 782ce9022027..5dc2676ac604 100644
--- a/modules/agent-installer-architectures.adoc
+++ b/modules/agent-installer-architectures.adoc
@@ -27,7 +27,7 @@ $ ./openshift-install version
 .Example output
 [source,terminal]
 ----
-./openshift-install 4.17.0
+./openshift-install 4.18.0
 built from commit abc123def456
 release image quay.io/openshift-release-dev/ocp-release@sha256:123abc456def789ghi012jkl345mno678pqr901stu234vwx567yz0
 release architecture amd64
diff --git a/modules/agent-installer-configuring-fips-compliance.adoc b/modules/agent-installer-configuring-fips-compliance.adoc
index 3060d4aa4745..d8c712aab5e1 100644
--- a/modules/agent-installer-configuring-fips-compliance.adoc
+++ b/modules/agent-installer-configuring-fips-compliance.adoc
@@ -10,6 +10,11 @@
 
 During a cluster deployment, the Federal Information Processing Standards (FIPS) change is applied when the Red Hat Enterprise Linux CoreOS (RHCOS) machines are deployed in your cluster. For Red Hat Enterprise Linux (RHEL) machines, you must enable FIPS mode when you install the operating system on the machines that you plan to use as worker machines.
 
+[IMPORTANT]
+====
+{product-title} requires the use of a FIPS-capable installation binary to install a cluster in FIPS mode.
+====
+
 You can enable FIPS mode through the preferred method of `install-config.yaml` and `agent-config.yaml`:
 
 . You must set value of the `fips` field to `True` in the `install-config.yaml` file:
@@ -24,6 +29,11 @@ metadata:
   name: sno-cluster
 fips: True
 ----
++
+[IMPORTANT]
+====
+To enable FIPS mode on {ibm-z-name} clusters, you must also enable FIPS in either the `.parm` file or using `virt-install` as outlined in the procedures for manually adding {ibm-z-name} agents.
+====
 
 . Optional: If you are using the {ztp} manifests, you must set the value of `fips` as `True` in the `Agent-install.openshift.io/install-config-overrides` field in the `agent-cluster-install.yaml` file:
 
diff --git a/modules/albo-deleting.adoc b/modules/albo-deleting.adoc
new file mode 100644
index 000000000000..a218e6e99b26
--- /dev/null
+++ b/modules/albo-deleting.adoc
@@ -0,0 +1,31 @@
+// Module included in the following assemblies:
+//
+:_mod-docs-content-type: PROCEDURE
+[id="aws-load-balancer-operator-deleting_{context}"]
+= Deleting the example AWS Load Balancer Operator installation
+
+. Delete the hello world application namespace (and all the resources in the namespace):
++
+[source,terminal]
+----
+$ oc delete project hello-world
+----
++
+. Delete the AWS Load Balancer Operator and the AWS IAM roles:
++
+[source,terminal]
+----
+$ oc delete subscription aws-load-balancer-operator -n aws-load-balancer-operator
+$ aws iam detach-role-policy \
+  --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
+  --policy-arn $POLICY_ARN
+$ aws iam delete-role \
+  --role-name "${ROSA_CLUSTER_NAME}-alb-operator"
+----
++
+. Delete the AWS IAM policy:
++
+[source,terminal]
+----
+$ aws iam delete-policy --policy-arn $POLICY_ARN
+----
\ No newline at end of file
diff --git a/modules/albo-installation.adoc b/modules/albo-installation.adoc
new file mode 100644
index 000000000000..732ecf6cc78c
--- /dev/null
+++ b/modules/albo-installation.adoc
@@ -0,0 +1,288 @@
+// Module included in the following assemblies:
+//
+:_mod-docs-content-type: PROCEDURE
+[id="aws-load-balancer-operator-installation_{context}"]
+= Installing the AWS Load Balancer Operator
+
+After setting up your environment with your cluster, you can install the AWS Load Balancer Operator using the CLI.
+
+.Procedure
+. Create a new project within your cluster for the AWS Load Balancer Operator:
++
+[source,terminal]
+----
+$ oc new-project aws-load-balancer-operator
+----
+
+. Create an AWS IAM policy for the AWS Load Balancer Controller:
++
+[NOTE]
+====
+You can find the AWS IAM policy from link:https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/install/iam_policy.json[the upstream AWS Load Balancer Controller policy]. This policy includes all of the permissions you needed by the Operator to function.
+====
++
+[source,terminal]
+----
+$ POLICY_ARN=$(aws iam list-policies --query \
+      "Policies[?PolicyName=='aws-load-balancer-operator-policy'].{ARN:Arn}" \
+      --output text)
+$ if [[ -z "${POLICY_ARN}" ]]; then
+     wget -O "${SCRATCH}/load-balancer-operator-policy.json" \
+        https://raw.githubusercontent.com/rh-mobb/documentation/main/content/rosa/aws-load-balancer-operator/load-balancer-operator-policy.json
+     POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
+     --output text iam create-policy \
+     --policy-name aws-load-balancer-operator-policy \
+     --policy-document "file://${SCRATCH}/load-balancer-operator-policy.json")
+fi
+$ echo $POLICY_ARN
+----
++
+. Create an AWS IAM trust policy for AWS Load Balancer Operator:
++
+[source,terminal]
+----
+$ cat <<EOF > "${SCRATCH}/trust-policy.json"
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Condition": {
+   "StringEquals" : {
+     "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
+   }
+ },
+ "Principal": {
+   "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
+ },
+ "Action": "sts:AssumeRoleWithWebIdentity"
+ }
+ ]
+}
+EOF
+----
++
+. Create an AWS IAM role for the AWS Load Balancer Operator:
++
+[source,terminal]
+----
+$ ROLE_ARN=$(aws iam create-role --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
+   --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
+   --query Role.Arn --output text)
+$ echo $ROLE_ARN
+
+$ aws iam attach-role-policy --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
+     --policy-arn $POLICY_ARN
+----
++
+. Create a secret for the AWS Load Balancer Operator to assume our newly created AWS IAM role:
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: v1
+kind: Secret
+metadata:
+  name: aws-load-balancer-operator
+  namespace: aws-load-balancer-operator
+stringData:
+  credentials: |
+    [default]
+    role_arn = $ROLE_ARN
+    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
+EOF
+----
++
+. Install the AWS Load Balancer Operator:
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: operators.coreos.com/v1
+kind: OperatorGroup
+metadata:
+  name: aws-load-balancer-operator
+  namespace: aws-load-balancer-operator
+spec:
+  upgradeStrategy: Default
+---
+apiVersion: operators.coreos.com/v1alpha1
+kind: Subscription
+metadata:
+  name: aws-load-balancer-operator
+  namespace: aws-load-balancer-operator
+spec:
+  channel: stable-v1.0
+  installPlanApproval: Automatic
+  name: aws-load-balancer-operator
+  source: redhat-operators
+  sourceNamespace: openshift-marketplace
+  startingCSV: aws-load-balancer-operator.v1.0.0
+EOF
+----
++
+. Deploy an instance of the AWS Load Balancer Controller using the Operator:
++
+[NOTE]
+====
+If you get an error here wait a minute and try again, it means the Operator has not completed installing yet.
+====
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: networking.olm.openshift.io/v1
+kind: AWSLoadBalancerController
+metadata:
+  name: cluster
+spec:
+  credentials:
+    name: aws-load-balancer-operator
+EOF
+----
++
+. Check the that the Operator and controller pods are both running:
++
+[source,terminal]
+----
+$ oc -n aws-load-balancer-operator get pods
+----
++
+You should see the following, if not wait a moment and retry:
++
+[source,terminal]
+----
+NAME                                                             READY   STATUS    RESTARTS   AGE
+aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
+aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s
+----
+
+[id="aws-load-balancer-operator-validating-the-deployment_{context}"]
+== Validating the deployment
+
+. Create a new project:
++
+[source,terminal]
+----
+$ oc new-project hello-world
+----
++
+. Deploy a hello world application:
++
+[source,terminal]
+----
+$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
+----
++
+. Configure a NodePort service for the AWS ALB to connect to:
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: v1
+kind: Service
+metadata:
+  name: hello-openshift-nodeport
+  namespace: hello-world
+spec:
+  ports:
+    - port: 80
+      targetPort: 8080
+      protocol: TCP
+  type: NodePort
+  selector:
+    deployment: hello-openshift
+EOF
+----
++
+. Deploy an AWS ALB using the AWS Load Balancer Operator:
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: hello-openshift-alb
+  namespace: hello-world
+  annotations:
+    alb.ingress.kubernetes.io/scheme: internet-facing
+spec:
+  ingressClassName: alb
+  rules:
+    - http:
+        paths:
+          - path: /
+            pathType: Exact
+            backend:
+              service:
+                name: hello-openshift-nodeport
+                port:
+                  number: 80
+EOF
+----
++
+. Curl the AWS ALB Ingress endpoint to verify the hello world application is accessible:
++
+[NOTE]
+====
+AWS ALB provisioning takes a few minutes. If you receive an error that says `curl: (6) Could not resolve host`, please wait and try again.
+====
++
+[source,termnial]
+----
+$ INGRESS=$(oc -n hello-world get ingress hello-openshift-alb \
+    -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
+$ curl "http://${INGRESS}"
+----
++
+.Example output
+[source,text]
+----
+Hello OpenShift!
+----
+
+. Deploy an AWS NLB for your hello world application:
++
+[source,terminal]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: v1
+kind: Service
+metadata:
+  name: hello-openshift-nlb
+  namespace: hello-world
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-type: external
+    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
+    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
+spec:
+  ports:
+    - port: 80
+      targetPort: 8080
+      protocol: TCP
+  type: LoadBalancer
+  selector:
+    deployment: hello-openshift
+EOF
+----
++
+. Test the AWS NLB endpoint:
++
+[NOTE]
+====
+NLB provisioning takes a few minutes. If you receive an error that says `curl: (6) Could not resolve host`, please wait and try again.
+====
++
+[source,terminal]
+----
+$ NLB=$(oc -n hello-world get service hello-openshift-nlb \
+  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
+$ curl "http://${NLB}"
+----
++
+.Example output
+[source,text]
+----
+Hello OpenShift!
+----
\ No newline at end of file
diff --git a/modules/albo-prerequisites.adoc b/modules/albo-prerequisites.adoc
new file mode 100644
index 000000000000..b2da58398953
--- /dev/null
+++ b/modules/albo-prerequisites.adoc
@@ -0,0 +1,104 @@
+// Module included in the following assemblies:
+//
+:_mod-docs-content-type: PROCEDURE
+[id="aws-load-balancer-operator-prerequisites_{context}"]
+= Setting up your environment to install the AWS Load Balancer Operator
+
+The AWS Load Balancer Operator requires a cluster with multiple availiability zones (AZ), as well as three public subnets split across three AZs in the same virtual private cloud (VPC) as the cluster. 
+
+[IMPORTANT]
+====
+Because of these requirements, the AWS Load Balancer Operator maybe be unsuitable for many PrivateLink clusters. AWS NLBs do not have this restriction.
+====
+
+Before installing the AWS Load Balancer Operator, you must have configured the following:
+
+ifndef::openshift-rosa-hcp[]
+* A ROSA (classic architecture) cluster with multiple availability zones
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* A ROSA cluster with multiple availability zones
+endif::openshift-rosa-hcp[]
+* BYO VPC cluster
+* AWS CLI
+* OC CLI
+
+[id="aws-load-balancer-operator-environment_{context}"]
+== AWS Load Balancer Operator environment set up
+
+Optional: You can set up temporary environment variables to streamline your installation commands. 
+
+[NOTE]
+====
+If you decide not to use environmental variables, manually enter the values where prompted in the code snippets.
+====
+
+.Procedure
+
+. After logging into your cluster as an admin user, run the following commands:
++
+[source,terminal]
+----
+$ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}")
+$ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
+$ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed  's|^https://||')
+$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+$ export SCRATCH="/tmp/${CLUSTER_NAME}/alb-operator"
+$ mkdir -p ${SCRATCH}
+----
+
+. You can verify that the variables are set by running the following command:
++
+[source,terminal]
+----
+$ echo "Cluster name: ${CLUSTER_NAME}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
+----
++
+.Example output
+[source,terminal]
+----
+Cluster name: <cluster_id>, Region: us-east-2, OIDC Endpoint: oidc.op1.openshiftapps.com/<oidc_id>, AWS Account ID: <aws_id>
+----
+
+[id="aws-vpc-subnets_{context}"]
+== AWS VPC and subnets
+
+Before you can install the AWS Load Balancer Operator, you must tag your AWS VPC resources.
+
+.Procedure
+
+. Set the environmental variables to the proper values for your ROSA deployment:
++
+[source,terminal]
+----
+$ export VPC_ID=<vpc-id>
+$ export PUBLIC_SUBNET_IDS="<public-subnet-a-id> <public-subnet-b-id> <public-subnet-c-id>"
+$ export PRIVATE_SUBNET_IDS="<private-subnet-a-id> <private-subnet-b-id> <private-subnet-c-id>"
+----
+
+. Add a tag to your cluster's VPC with the cluster name:
++
+[source,terminal]
+----
+$ aws ec2 create-tags --resources ${VPC_ID} --tags Key=kubernetes.io/cluster/${CLUSTER_NAME},Value=owned --region ${REGION}
+----
+
+. Add a tag to your public subnets:
++
+[source,terminal]
+----
+$ aws ec2 create-tags \
+     --resources ${PUBLIC_SUBNET_IDS} \
+     --tags Key=kubernetes.io/role/elb,Value='' \
+     --region ${REGION}
+----
+
+. Add a tag to your private subnets:
++
+[source,terminal]
+----
+$ aws ec2 create-tags \
+     --resources ${PRIVATE_SUBNET_IDS} \
+     --tags Key=kubernetes.io/role/internal-elb,Value='' \
+     --region ${REGION}
+----
\ No newline at end of file
diff --git a/modules/architecture-platform-introduction.adoc b/modules/architecture-platform-introduction.adoc
index c5b8cda9123f..70f3a22cb0bc 100644
--- a/modules/architecture-platform-introduction.adoc
+++ b/modules/architecture-platform-introduction.adoc
@@ -4,18 +4,12 @@
 [id="architecture-platform-introduction_{context}"]
 = Introduction to {product-title}
 
-{product-title} is a platform for developing and running containerized
-applications. It is designed to allow applications and the data centers
-that support them to expand from just a few machines and applications to
-thousands of machines that serve millions of clients.
+{product-title} is a platform for developing and running containerized applications. It is designed to allow applications and the data centers that support them to expand from just a few machines and applications to thousands of machines that serve millions of clients.
 
-With its foundation in Kubernetes, {product-title} incorporates the same
-technology that serves as the engine for massive telecommunications, streaming
-video, gaming, banking, and other applications. Its implementation in open
-Red Hat technologies lets you extend your containerized applications beyond a
-single cloud to on-premise and multi-cloud environments.
+With its foundation in Kubernetes, {product-title} incorporates the same technology that serves as the engine for massive telecommunications, streaming video, gaming, banking, and other applications. Its implementation in open
+Red{nbsp}Hat technologies lets you extend your containerized applications beyond a single cloud to on-premise and multi-cloud environments.
 
-image::ocp_arch.png[Red Hat {oke}]
+image::525-OpenShift-arch-012025.png[Red Hat {oke}]
 
 // The architecture presented here is meant to give you insights into how {product-title} works. It does this by stepping you through the process of installing an {product-title} cluster, managing the cluster, and developing and deploying applications on it. Along the way, this architecture describes:
 
diff --git a/modules/aws-installing-an-aws-load-balancer-operator.adoc b/modules/aws-installing-an-aws-load-balancer-operator.adoc
index d5d5763dd43d..38505dc09590 100644
--- a/modules/aws-installing-an-aws-load-balancer-operator.adoc
+++ b/modules/aws-installing-an-aws-load-balancer-operator.adoc
@@ -15,7 +15,7 @@ You can install an AWS Load Balancer Operator and an AWS Load Balancer Controlle
 * You have access to modify the VPC and subnets of the created ROSA cluster.
 * You have installed the ROSA CLI (`rosa`).
 * You have installed the Amazon Web Services (AWS) CLI.
-* You are using OpenShift Container Platform 4.13 or later.
+* You are using {product-title} 4.13 or later.
 
 [IMPORTANT]
 ====
@@ -86,7 +86,7 @@ $ IDP_ARN="arn:aws:iam::{AWS_AccountNo}:oidc-provider/${IDP}" <1>
 .Example output
 [source,terminal,subs="quotes,verbatim"]
 ----
-$ cat EOF albo-operator-trusted-policy.json
+$ cat <<EOF > albo-operator-trusted-policy.json
 {
     "Version": "2012-10-17",
     "Statement": [
@@ -160,7 +160,7 @@ $ aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-a
 ----
 $ IDP='{Cluster_OIDC_Endpoint}'
 $ IDP_ARN="arn:aws:iam::{AWS_AccountNo}:oidc-provider/${IDP}"
-$ cat <EOF> albo-controller-trusted-policy.json
+$ cat <<EOF > albo-controller-trusted-policy.json
 {
     "Version": "2012-10-17",
     "Statement": [
@@ -172,7 +172,7 @@ $ cat <EOF> albo-controller-trusted-policy.json
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {
                 "StringEquals": {
-                    "${IDP}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"
+                    "${IDP}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager"
                 }
             }
         }
@@ -196,7 +196,7 @@ $ echo $CONTROLLER_ROLE_ARN
 ROLE	arn:aws:iam::<aws_account_number>:role/albo-controller	2023-08-02T12:13:22Z
 ASSUMEROLEPOLICYDOCUMENT	2012-10-17
 STATEMENT	    sts:AssumeRoleWithWebIdentity	Allow
-STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster
+STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager
 PRINCIPAL	    arn:aws:iam:<aws_account_number>:oidc-provider/<oidc_provider_id>
 ----
 +
@@ -243,7 +243,7 @@ ELBv2 resources (such as ALBs and NLBs) created by AWS Load Balancer Operator do
 +
 [source,terminal]
 ----
-$ cat EOF | oc apply -f -
+$ cat <<EOF | oc apply -f -
 apiVersion: operators.coreos.com/v1
 kind: OperatorGroup
 metadata:
@@ -258,7 +258,7 @@ EOF
 +
 [source,terminal]
 ----
-$ cat EOF | oc apply -f -
+$ cat <<EOF | oc apply -f -
 apiVersion: operators.coreos.com/v1alpha1
 kind: Subscription
 metadata:
diff --git a/modules/backing-up-the-3scale-operator.adoc b/modules/backing-up-the-3scale-operator.adoc
new file mode 100644
index 000000000000..2360281b88d5
--- /dev/null
+++ b/modules/backing-up-the-3scale-operator.adoc
@@ -0,0 +1,123 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="backing-up-the-3scale-operator_{context}"]
+= Backing up the 3scale Operator
+
+You can back up the Operator resources, and Secret and APIManager custom resources (CR). For more information, see "Creating a Backup CR".
+
+.Prerequisites
+
+* You created the Data Protection Application (DPA). 
+
+.Procedure
+
+. Back up the Operator resources, such as `operatorgroup`, `namespaces`, and `subscriptions`, by creating a YAML file with the following configuration: 
++
+.Example `backup.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: operator-install-backup
+  namespace: openshift-adp
+spec:
+  csiSnapshotTimeout: 10m0s
+  defaultVolumesToFsBackup: false
+  includedNamespaces:
+  - threescale   <1>
+  includedResources:
+  - operatorgroups
+  - subscriptions
+  - namespaces
+  itemOperationTimeout: 1h0m0s
+  snapshotMoveData: false
+  ttl: 720h0m0s
+----
+<1> Namespace where the 3scale Operator is installed.
++
+[NOTE]
+====
+You can also back up and restore `ReplicationControllers`, `Deployment`, and `Pod` objects to ensure that all manually set environments are backed up and restored. This does not affect the flow of restoration.
+====
+
+. Create a backup CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f backup.yaml
+----
+
+. Back up the Secret CR by creating a YAML file with the following configuration:
++
+.Example `backup-secret.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: operator-resources-secrets
+  namespace: openshift-adp
+spec:
+  csiSnapshotTimeout: 10m0s
+  defaultVolumesToFsBackup: false
+  includedNamespaces:
+  - threescale
+  includedResources:
+  - secrets
+  itemOperationTimeout: 1h0m0s
+  labelSelector:
+    matchLabels:
+      app: 3scale-api-management
+  snapshotMoveData: false
+  snapshotVolumes: false
+  ttl: 720h0m0s
+----
+
+. Create the Secret CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f backup-secret.yaml
+----
+
+. Back up the APIManager CR by creating a YAML file with the following configuration:
++
+.Example backup-apimanager.yaml file
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: operator-resources-apim
+  namespace: openshift-adp
+spec:
+  csiSnapshotTimeout: 10m0s
+  defaultVolumesToFsBackup: false
+  includedNamespaces:
+  - threescale
+  includedResources:
+  - apimanagers
+  itemOperationTimeout: 1h0m0s
+  snapshotMoveData: false
+  snapshotVolumes: false
+  storageLocation: ts-dpa-1
+  ttl: 720h0m0s
+  volumeSnapshotLocations:
+  - ts-dpa-1
+----
+
+. Create the APIManager CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f backup-apimanager.yaml
+----
+
+.Next steps
+
+* Back up the `mysql` database.
\ No newline at end of file
diff --git a/modules/backing-up-the-backend-redis-database.adoc b/modules/backing-up-the-backend-redis-database.adoc
new file mode 100644
index 000000000000..5848d9f81e9d
--- /dev/null
+++ b/modules/backing-up-the-backend-redis-database.adoc
@@ -0,0 +1,91 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="backing-up-the-backend-redis-database_{context}"]
+= Backing up the back-end Redis database
+
+You can back up the Redis database by adding the required annotations and by listing which resources to back up using the `includedResources` parameter.
+
+
+.Prerequisites
+
+* You backed up the 3scale Operator.
+* You backed up the mysql database.
+* The Redis queues have been drained before performing the backup.
+
+
+.Procedure
+
+. Edit the annotations on the `backend-redis` deployment by running the following command:
++
+[source, terminal]
+----
+$ oc edit deployment backend-redis -n threescale
+----
+
+. Add the following annotations:
++
+[source,yaml]
+----
+annotations:
+post.hook.backup.velero.io/command: >-
+         ["/bin/bash", "-c", "redis-cli CONFIG SET auto-aof-rewrite-percentage
+         100"]
+       pre.hook.backup.velero.io/command: >-
+         ["/bin/bash", "-c", "redis-cli CONFIG SET auto-aof-rewrite-percentage
+         0"]
+----
+
+. Create a YAML file with the following configuration to back up the Redis database:
++
+.Example `redis-backup.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: redis-backup
+  namespace: openshift-adp
+spec:
+  csiSnapshotTimeout: 10m0s
+  defaultVolumesToFsBackup: true
+  includedNamespaces:
+  - threescale
+  includedResources:
+  - deployment
+  - pods
+  - replicationcontrollers
+  - persistentvolumes
+  - persistentvolumeclaims
+  itemOperationTimeout: 1h0m0s
+  labelSelector:
+    matchLabels:
+      app: 3scale-api-management
+      threescale_component: backend
+      threescale_component_element: redis
+  snapshotMoveData: false
+  snapshotVolumes: false
+  ttl: 720h0m0s
+----
+
+. Back up the Redis database by running the following command:
++
+[source,terminal]
+----
+$ oc get backups.velero.io redis-backup -o yaml
+----
+
+.Verification
+
+* Verify that the Redis backup is completed by running the following command:: 
++
+[source,terminal]
+----
+$ oc get backups.velero.io
+----
+
+.Next steps
+
+* Restore the Secrets and APIManager CRs.
\ No newline at end of file
diff --git a/modules/backing-up-the-mysql-database.adoc b/modules/backing-up-the-mysql-database.adoc
new file mode 100644
index 000000000000..e7470f470f38
--- /dev/null
+++ b/modules/backing-up-the-mysql-database.adoc
@@ -0,0 +1,144 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="backing-up-the-mysql-database_{context}"]
+= Backing up the mysql database
+
+You can back up the `mysql` database by creating and attaching a persistent volume claim (PVC) to include the dumped data in the specified path.
+
+.Prerequisites
+
+* You have backed up the 3scale operator. 
+
+.Procedure
+
+. Create a YAML file with the following configuration for adding an additional PVC:
++
+.Example `ts_pvc.yaml` file
+[source,yaml]
+----
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: example-claim
+  namespace: threescale
+spec:
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+  storageClassName: gp3-csi
+  volumeMode: Filesystem
+----
+
+. Create the additional PVC by running the following command: 
++
+[source,terminal]
+----
+$ oc create -f ts_pvc.yml 
+----
+
+. Attach the PVC to the system database pod by editing the system database deployment to use the `mysql` dump:
++
+[source,terminal]
+----
+$ oc edit deployment system-mysql -n threescale
+----	
++
+[source,yaml]
+----
+  volumeMounts:
+    - name: example-claim
+      mountPath: /var/lib/mysqldump/data
+    - name: mysql-storage
+      mountPath: /var/lib/mysql/data
+    - name: mysql-extra-conf
+      mountPath: /etc/my-extra.d
+    - name: mysql-main-conf
+      mountPath: /etc/my-extra
+    ...
+      serviceAccount: amp
+  volumes:
+        - name: example-claim
+          persistentVolumeClaim:
+            claimName: example-claim <1>
+    ...
+----
+<1> The PVC that contains the dumped data.
+
+. Create a YAML file with following configuration to back up the `mysql` database:
++
+.Example `mysql.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: mysql-backup
+  namespace: openshift-adp
+spec:
+  csiSnapshotTimeout: 10m0s
+  defaultVolumesToFsBackup: true
+  hooks:
+    resources:
+    - name: dumpdb
+      pre:
+      - exec:
+          command:
+          - /bin/sh
+          - -c
+          - mysqldump -u $MYSQL_USER --password=$MYSQL_PASSWORD system --no-tablespaces
+            > /var/lib/mysqldump/data/dump.sql <1>
+          container: system-mysql
+          onError: Fail
+          timeout: 5m
+  includedNamespaces: <2>
+  - threescale
+  includedResources:
+  - deployment
+  - pods
+  - replicationControllers
+  - persistentvolumeclaims
+  - persistentvolumes
+  itemOperationTimeout: 1h0m0s
+  labelSelector:
+    matchLabels:
+      app: 3scale-api-management
+      threescale_component_element: mysql
+  snapshotMoveData: false
+  ttl: 720h0m0s
+----
+<1> A directory where the data is backed up.
+<2> Resources to back up.
+
+. Back up the `mysql` database by running the following command:
++
+[source,terminal]
+----
+$ oc create -f mysql.yaml
+----
+
+.Verification
+
+* Verify that the `mysql` backup is completed by running the following command:
++
+[source,terminal]
+----
+$ oc get backups.velero.io mysql-backup
+----
++
+.Example output
++
+[source,terminal]
+----
+NAME                  STATUS      CREATED   NAMESPACE    POD                    VOLUME          UPLOADER TYPE   STORAGE LOCATION   AGE
+mysql-backup-4g7qn   Completed   30s       threescale   system-mysql-2-9pr44   example-claim   kopia           ts-dpa-1           30s
+mysql-backup-smh85   Completed   23s       threescale   system-mysql-2-9pr44   mysql-storage   kopia           ts-dpa-1           30s
+----
+
+.Next steps
+
+* Back up the back-end Redis database.
\ No newline at end of file
diff --git a/modules/backup-etcd-hosted-cluster.adoc b/modules/backup-etcd-hosted-cluster.adoc
index 78c4fc34fdde..dd654548c8f2 100644
--- a/modules/backup-etcd-hosted-cluster.adoc
+++ b/modules/backup-etcd-hosted-cluster.adoc
@@ -19,28 +19,38 @@ This procedure requires API downtime.
 +
 [source,terminal]
 ----
-$ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p '{"spec":{"pausedUntil":"true"}}' --type=merge
+$ oc patch -n clusters hostedclusters/<hosted_cluster_name> \
+  -p '{"spec":{"pausedUntil":"true"}}' --type=merge
 ----
 
 . Stop all etcd-writer deployments by entering the following command:
 +
 [source,terminal]
 ----
-$ oc scale deployment -n <hosted_cluster_namespace> --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver
+$ oc scale deployment -n <hosted_cluster_namespace> --replicas=0 \
+  kube-apiserver openshift-apiserver openshift-oauth-apiserver
 ----
 
 . To take an etcd snapshot, use the `exec` command in each etcd container by entering the following command:
 +
 [source,terminal]
 ----
-$ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/etcd-ca/ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
+$ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \
+  env ETCDCTL_API=3 /usr/bin/etcdctl \
+  --cacert /etc/etcd/tls/etcd-ca/ca.crt \
+  --cert /etc/etcd/tls/client/etcd-client.crt \
+  --key /etc/etcd/tls/client/etcd-client.key \
+  --endpoints=localhost:2379 \
+  snapshot save /var/lib/data/snapshot.db
 ----
 
 . To check the snapshot status, use the `exec` command in each etcd container by running the following command:
 +
 [source,terminal]
 ----
-$ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
+$ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \
+  env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \
+  /var/lib/data/snapshot.db
 ----
 
 . Copy the snapshot data to a location where you can retrieve it later, such as an S3 bucket. See the following example.
@@ -78,7 +88,8 @@ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- curl -X PUT -T "/var/lib/da
 +
 [source,terminal]
 ----
-$ oc get hostedcluster <hosted_cluster_name> -o=jsonpath='{.spec.secretEncryption.aescbc}'
+$ oc get hostedcluster <hosted_cluster_name> \
+  -o=jsonpath='{.spec.secretEncryption.aescbc}'
 {"activeKey":{"name":"<hosted_cluster_name>-etcd-encryption-key"}}
 ----
 
@@ -86,7 +97,8 @@ $ oc get hostedcluster <hosted_cluster_name> -o=jsonpath='{.spec.secretEncryptio
 +
 [source,terminal]
 ----
-$ oc get secret <hosted_cluster_name>-etcd-encryption-key -o=jsonpath='{.data.key}'
+$ oc get secret <hosted_cluster_name>-etcd-encryption-key \
+  -o=jsonpath='{.data.key}'
 ----
 +
 You can decrypt this key when restoring a snapshot on a new cluster.
@@ -95,14 +107,16 @@ You can decrypt this key when restoring a snapshot on a new cluster.
 +
 [source,terminal]
 ----
-$ oc scale deployment -n <control_plane_namespace> --replicas=3 kube-apiserver openshift-apiserver openshift-oauth-apiserver
+$ oc scale deployment -n <control_plane_namespace> --replicas=3 \
+  kube-apiserver openshift-apiserver openshift-oauth-apiserver
 ----
 
 . Resume the reconciliation of the hosted cluster by entering the following command:
 +
 [source,terminal]
 ----
-$ oc patch -n <hosted_cluster_namespace> -p '[\{"op": "remove", "path": "/spec/pausedUntil"}]' --type=json
+$ oc patch -n <hosted_cluster_namespace> \
+  -p '[\{"op": "remove", "path": "/spec/pausedUntil"}]' --type=json
 ----
 
 .Next steps
diff --git a/modules/binding-infra-node-workloads-using-taints-tolerations.adoc b/modules/binding-infra-node-workloads-using-taints-tolerations.adoc
index e2e873e90e04..3a19de93d17a 100644
--- a/modules/binding-infra-node-workloads-using-taints-tolerations.adoc
+++ b/modules/binding-infra-node-workloads-using-taints-tolerations.adoc
@@ -7,11 +7,11 @@
 [id="binding-infra-node-workloads-using-taints-tolerations_{context}"]
 = Binding infrastructure node workloads using taints and tolerations
 
-If you have an infra node that has the `infra` and `worker` roles assigned, you must configure the node so that user workloads are not assigned to it.
+If you have an infrastructure node that has the `infra` and `worker` roles assigned, you must configure the node so that user workloads are not assigned to it.
 
 [IMPORTANT]
 ====
-It is recommended that you preserve the dual `infra,worker` label that is created for infra nodes and use taints and tolerations to manage nodes that user workloads are scheduled on. If you remove the `worker` label from the node, you must create a custom pool to manage it. A node with a label other than `master` or `worker` is not recognized by the MCO without a custom pool. Maintaining the `worker` label allows the node to be managed by the default worker machine config pool, if no custom pools that select the custom label exists. The `infra` label communicates to the cluster that it does not count toward the total number of subscriptions.
+It is recommended that you preserve the dual `infra,worker` label that is created for infrastructure nodes and use taints and tolerations to manage nodes that user workloads are scheduled on. If you remove the `worker` label from the node, you must create a custom pool to manage it. A node with a label other than `master` or `worker` is not recognized by the MCO without a custom pool. Maintaining the `worker` label allows the node to be managed by the default worker machine config pool, if no custom pools that select the custom label exists. The `infra` label communicates to the cluster that it does not count toward the total number of subscriptions.
 ====
 
 .Prerequisites
@@ -20,7 +20,7 @@ It is recommended that you preserve the dual `infra,worker` label that is create
 
 .Procedure
 
-. Add a taint to the infra node to prevent scheduling user workloads on it:
+. Add a taint to the infrastructure node to prevent scheduling user workloads on it:
 
 .. Determine if the node has the taint:
 +
@@ -36,7 +36,7 @@ oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
 Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
 Roles:              worker
  ...
-Taints:             node-role.kubernetes.io/infra:NoSchedule
+Taints:             node-role.kubernetes.io/infra=reserved:NoSchedule
  ...
 ----
 +
@@ -58,97 +58,61 @@ $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule
 +
 [TIP]
 ====
-You can alternatively apply the following YAML to add the taint:
+You can alternatively edit the pod specification to add the taint:
 
 [source,yaml]
 ----
-kind: Node
 apiVersion: v1
+kind: Node
 metadata:
-  name: <node_name>
-  labels:
-    ...
+  name: node1
+# ...
 spec:
   taints:
     - key: node-role.kubernetes.io/infra
-      effect: NoSchedule
       value: reserved
-  ...
+      effect: NoSchedule
+# ...
 ----
 ====
 +
-This example places a taint on `node1` that has key `node-role.kubernetes.io/infra` and taint effect `NoSchedule`. Nodes with the `NoSchedule` effect schedule only pods that tolerate the taint, but allow existing pods to remain scheduled on the node. 
+These examples place a taint on `node1` that has the `node-role.kubernetes.io/infra` key and the `NoSchedule` taint effect. Nodes with the `NoSchedule` effect schedule only pods that tolerate the taint, but allow existing pods to remain scheduled on the node. 
 +
 [NOTE]
 ====
 If a descheduler is used, pods violating node taints could be evicted from the cluster.
 ====
 
-.. Add the taint with NoExecute Effect along with the above taint with NoSchedule Effect:
-+
-[source,terminal]
-----
-$ oc adm taint nodes <node_name> <key>=<value>:<effect>
-----
+. Add tolerations to the pods that you want to schedule on the infrastructure node, such as the router, registry, and monitoring workloads. Referencing the previous examples, add the following tolerations to the `Pod` object specification:
 +
-For example:
-+
-[source,terminal]
-----
-$ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute
-----
-+
-[TIP]
-====
-You can alternatively apply the following YAML to add the taint:
-
 [source,yaml]
 ----
-kind: Node
 apiVersion: v1
+kind: Pod
 metadata:
-  name: <node_name>
-  labels:
-    ...
-spec:
-  taints:
-    - key: node-role.kubernetes.io/infra
-      effect: NoExecute
-      value: reserved
-  ...
-----
-====
-+
-This example places a taint on `node1` that has the key `node-role.kubernetes.io/infra` and taint effect `NoExecute`. Nodes with the `NoExecute` effect schedule only pods that tolerate the taint. The effect will remove any existing pods from the node that do not have a matching toleration. 
-+
+  annotations:
 
-
-. Add tolerations for the pod configurations you want to schedule on the infra node, like router, registry, and monitoring workloads. Add the following code to the `Pod` object specification:
-+
-[source,yaml]
-----
-tolerations:
-  - effect: NoSchedule <1>
-    key: node-role.kubernetes.io/infra <2>
-    value: reserved <3>
-  - effect: NoExecute <4>
-    key: node-role.kubernetes.io/infra <5>
-    operator: Exists <6>
-    value: reserved <7>
+# ...
+spec:
+# ...
+  tolerations:
+    - key: node-role.kubernetes.io/infra <1>
+      value: reserved <2>
+      effect: NoSchedule <3>
+      operator: Equal <4>
 ----
-<1> Specify the effect that you added to the node.
-<2> Specify the key that you added to the node.
-<3> Specify the value of the key-value pair taint that you added to the node.
-<4> Specify the effect that you added to the node.
-<5> Specify the key that you added to the node.
-<6> Specify the `Exists` Operator to require a taint with the key `node-role.kubernetes.io/infra` to be present on the node.
-<7> Specify the value of the key-value pair taint that you added to the node.
+<1> Specify the key that you added to the node.
+<2> Specify the value of the key-value pair taint that you added to the node.
+<3> Specify the effect that you added to the node.
+<4> Specify the `Equal` Operator to require a taint with the key `node-role.kubernetes.io/infra` to be present on the node.
 +
-This toleration matches the taint created by the `oc adm taint` command. A pod with this toleration can be scheduled onto the infra node.
+This toleration matches the taint created by the `oc adm taint` command. A pod with this toleration can be scheduled onto the infrastructure node.
 +
 [NOTE]
 ====
-Moving pods for an Operator installed via OLM to an infra node is not always possible. The capability to move Operator pods depends on the configuration of each Operator.
+Moving pods for an Operator installed via OLM to an infrastructure node is not always possible. The capability to move Operator pods depends on the configuration of each Operator.
 ====
 
-. Schedule the pod to the infra node using a scheduler. See the documentation for _Controlling pod placement onto nodes_ for details.
+. Schedule the pod to the infrastructure node by using a scheduler. See the documentation for "Controlling pod placement using the scheduler" for details.
+
+. Remove any workloads that you do not want, or that do not belong, on the new infrastructure node. See the list of workloads supported for use on infrastructure nodes in "{product-title} infrastructure components". 	
diff --git a/modules/bmo-about-the-hostfirmwaresettings-resource.adoc b/modules/bmo-about-the-hostfirmwaresettings-resource.adoc
index 36d0880ce346..07fdd6a3df3f 100644
--- a/modules/bmo-about-the-hostfirmwaresettings-resource.adoc
+++ b/modules/bmo-about-the-hostfirmwaresettings-resource.adoc
@@ -13,6 +13,11 @@ The `HostFirmwareSettings` resource contains two sections:
 . The `HostFirmwareSettings` spec.
 . The `HostFirmwareSettings` status.
 
+[NOTE]
+====
+Reading and modifying firmware settings is only supported for drivers based on the vendor-independent Redfish protocol, Fujitsu iRMC or HP iLO.
+====
+
 == The `HostFirmwareSettings` spec
 
 The `spec` section of the `HostFirmwareSettings` resource defines the desired state of the host's BIOS, and it is empty by default. Ironic uses the settings in the `spec.settings` section to update the baseboard management controller (BMC) when the host is in the `Preparing` state. Use the `FirmwareSchema` resource to ensure that you do not send invalid name/value pairs to hosts. See "About the FirmwareSchema resource" for additional details.
diff --git a/modules/bmo-about-the-hostupdatepolicy-resource.adoc b/modules/bmo-about-the-hostupdatepolicy-resource.adoc
new file mode 100644
index 000000000000..a4b4500fd421
--- /dev/null
+++ b/modules/bmo-about-the-hostupdatepolicy-resource.adoc
@@ -0,0 +1,34 @@
+// This is included in the following assemblies:
+//
+// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="bmo-about-the-hostupdatepolicy-resource_{context}"]
+= About the HostUpdatePolicy resource
+
+You can use the `HostUpdatePolicy` resource to enable or disable applying live updates to the firmware settings, BMC settings, or firmware settings of each bare-metal host. By default, the Operator disables live updates to already provisioned bare-metal hosts by default.
+
+.The `HostUpdatePolicy` spec
+
+The `spec` section of the `HostUpdatePolicy` resource provides two settings:
+
+`firmwareSettings`:: This setting corresponds to the `HostFirmwareSettings` resource. 
+
+`firmwareUpdates`:: This setting corresponds to the `HostFirmwareComponents` resource.
+
+When you set the value to `onPreparing`, you can only update the host during provisioning, which is the default setting. When you set the value to `onReboot`, you can update a provisioned host by applying the resource and rebooting the bare-metal host. Then, follow the procedure for editing the `HostFirmwareSettings` or `HostFirmwareComponents` resource.
+
+.Example `HostUpdatePolicy` resource
+[source,yaml]
+----
+apiVersion: metal3.io/v1alpha1
+kind: HostUpdatePolicy
+metadata:
+  name: <hostname> <1>
+  namespace: openshift-machine-api
+spec:
+  firmwareSettings: <setting> <2>
+  firmwareUpdates: <setting>
+----
+<1> The name of the bare-metal host.
+<2> The update policy setting. Specify `onPreparing` to disable live updates. Specify `onReboot` to enable live updates.
\ No newline at end of file
diff --git a/modules/bmo-bare-metal-operator-architecture.adoc b/modules/bmo-bare-metal-operator-architecture.adoc
index 763486b7236c..2bc0c235d06d 100644
--- a/modules/bmo-bare-metal-operator-architecture.adoc
+++ b/modules/bmo-bare-metal-operator-architecture.adoc
@@ -12,7 +12,7 @@ image::715_OpenShift_Bare_Metal_Operator_updates_0624.png[BMO architecture overv
 
 .BareMetalHost
 
-The `BareMetalHost` resource defines a physical host and its properties. When you provision a bare-metal host to the cluster, you must define a `BareMetalHost` resource for that host. For ongoing management of the host, you can inspect the information in the `BareMetalHost` or update this information.
+The `BareMetalHost` resource defines a physical host and its properties. When you provision a bare-metal host to the cluster, you must define a `BareMetalHost` resource for that host. For ongoing management of the host, you can inspect the information in the `BareMetalHost` resource or update this information.
 
 The `BareMetalHost` resource features provisioning information such as the following:
 
@@ -39,7 +39,7 @@ You must adhere to the schema specific to the vendor firmware when you edit the
 ====
 
 .FirmwareSchema
-Firmware settings vary among hardware vendors and host models. A `FirmwareSchema` resource is a read-only resource that contains the types and limits for each firmware setting on each host model. The data comes directly from the BMC by using the Ironic service. The `FirmwareSchema` resource enables you to identify valid values you can specify in the `spec` field of the `HostFirmwareSettings` resource.
+Firmware settings vary among hardware vendors and host models. A `FirmwareSchema` resource is a read-only resource that contains the types and limits for each firmware setting on each host model. The data comes directly from the BMC by using the Ironic service. You can use the `FirmwareSchema` resource to identify valid values that you can specify in the `spec` field of the `HostFirmwareSettings` resource.
 
 A `FirmwareSchema` resource can apply to many `BareMetalHost` resources if the schema is the same.
 
@@ -51,3 +51,7 @@ Metal^3^ provides the `HostFirmwareComponents` resource, which describes BIOS an
 .Additional resources
 * link:https://metal3.io/[Metal^3^ API service for provisioning bare-metal hosts]
 * link:https://ironicbaremetal.org/[Ironic API service for managing bare-metal infrastructure]
+
+.HostUpdatePolicy
+
+The `HostUpdatePolicy` resource can enable or disable live updates to the firmware settings, BMC settings, or BIOS settings of bare-metal hosts. By default, the `HostUpdatePolicy` resource for each bare-metal host restricts updates to hosts during provisioning. You must modify the `HostUpdatePolicy` resource for a host when you want to update the firmware settings, BMC settings, or BIOS settings after provisioning the host.
\ No newline at end of file
diff --git a/modules/bmo-config-using-bare-metal-operator.adoc b/modules/bmo-config-using-bare-metal-operator.adoc
index 152e7a98565b..f1c78d4ced2f 100644
--- a/modules/bmo-config-using-bare-metal-operator.adoc
+++ b/modules/bmo-config-using-bare-metal-operator.adoc
@@ -11,7 +11,7 @@ When deploying {product-title} on bare-metal hosts, there are times when you nee
 You can use the Bare Metal Operator (BMO) to provision, manage, and inspect bare-metal hosts in your cluster. The BMO can complete the following operations:
 
 * Provision bare-metal hosts to the cluster with a specific image.
-* Turn on or off a host.
+* Turn a host on or off.
 * Inspect hardware details of the host and report them to the bare-metal host.
 * Upgrade or downgrade a host's firmware to a specific version.
 * Inspect firmware and configure BIOS settings.
@@ -23,9 +23,12 @@ The BMO uses the following resources to complete these tasks:
 * `HostFirmwareSettings`
 * `FirmwareSchema`
 * `HostFirmwareComponents`
+* `HostUpdatePolicy`
 
 The BMO maintains an inventory of the physical hosts in the cluster by mapping each bare-metal host to an instance of the `BareMetalHost` custom resource definition. Each `BareMetalHost` resource features hardware, software, and firmware details. The BMO continually inspects the bare-metal hosts in the cluster to ensure each `BareMetalHost` resource accurately details the components of the corresponding host.
 
 The BMO also uses the `HostFirmwareSettings` resource, the `FirmwareSchema` resource, and the `HostFirmwareComponents` resource to detail firmware specifications and upgrade or downgrade firmware for the bare-metal host.
 
 The BMO interfaces with bare-metal hosts in the cluster by using the Ironic API service. The Ironic service uses the Baseboard Management Controller (BMC) on the host to interface with the machine.
+
+The BMO `HostUpdatePolicy` can enable or disable live updates to the firmware settings, BMC settings, or BIOS settings of a bare-metal host after provisioning the host. By default, the BMO disables live updates.
\ No newline at end of file
diff --git a/modules/bmo-editing-the-hostfirmwarecomponents-resource.adoc b/modules/bmo-editing-the-hostfirmwarecomponents-resource-of-a-provisioned-host.adoc
similarity index 69%
rename from modules/bmo-editing-the-hostfirmwarecomponents-resource.adoc
rename to modules/bmo-editing-the-hostfirmwarecomponents-resource-of-a-provisioned-host.adoc
index 2f7d12414a39..6c4d406d90dc 100644
--- a/modules/bmo-editing-the-hostfirmwarecomponents-resource.adoc
+++ b/modules/bmo-editing-the-hostfirmwarecomponents-resource-of-a-provisioned-host.adoc
@@ -1,28 +1,30 @@
 // This is included in the following assemblies:
 //
 // * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+:_mod-docs-content-type: PROCEDURE
+[id="bmo-editing-the-hostfirmwarecomponents-resource-of-a-provisioned-host_{context}"]
+= Editing the HostFirmwareComponents resource of a provisioned host
 
-[id="bmo-editing-the-hostfirmwarecomponents-resource_{context}"]
-= Editing the HostFirmwareComponents resource
-
-You can edit the `HostFirmwareComponents` resource of a node.
+You can edit the `HostFirmwareComponents` resource of a provisioned host.
 
 .Procedure
 
-. Get the detailed list of `HostFirmwareComponents` resources:
+. Get the detailed list of `HostFirmwareComponents` resources by running the following command:
 +
 [source,terminal]
 ----
 $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
 ----
 
-. Edit a host's `HostFirmwareComponents` resource:
+. Edit the `HostFirmwareComponents` resource by running the following command:
 +
 [source,terminal]
 ----
-$ oc edit <host_name> hostfirmwarecomponents -n openshift-machine-api <1>
+$ oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api <1>
 ----
-<1> Where `<host_name>` is the name of the host. The `HostFirmwareComponents` resource will open in the default editor for your terminal.
+<1> Where `<hostname>` is the name of the host. The `HostFirmwareComponents` resource will open in the default editor for your terminal.
+
+. Make the appropriate edits.
 +
 .Example output
 [source,yaml]
@@ -76,19 +78,19 @@ status:
 <1> To set a BIOS version, set the `name` attribute to `bios`.
 <2> To set a BIOS version, set the `url` attribute to the URL for the firmware version of the BIOS.
 <3> To set a BMC version, set the `name` attribute to `bmc`.
-<4> To set a BMC version, set the `url` attribute to the URL for the firmware verison of the BMC.
+<4> To set a BMC version, set the `url` attribute to the URL for the firmware version of the BMC.
 
 . Save the changes and exit the editor.
 
-. Get the host’s machine name:
+. Get the host machine name by running the following command:
 +
 [source,terminal]
 ----
 $ oc get bmh <host_name> -n openshift-machine name <1>
 ----
-<1> Where `<host_name>` is the name of the host. The machine name appears under the `CONSUMER` field.
+<1> Where `<host_name>` is the name of the host. The terminal displays the machine name under the `CONSUMER` field.
 
-. Annotate the machine to delete it from the machine set:
+. Annotate the machine to delete it from the machine set by running the following command:
 +
 [source,terminal]
 ----
@@ -96,21 +98,21 @@ $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n
 ----
 <1> Where `<machine_name>` is the name of the machine to delete.
 
-. Get a list of nodes and count the number of worker nodes:
+. Get a list of nodes and count the number of worker nodes by running the following command:
 +
 [source,terminal]
 ----
 $ oc get nodes
 ----
 
-. Get the machine set:
+. Get the machine set by running the following command:
 +
 [source,terminal]
 ----
 $ oc get machinesets -n openshift-machine-api
 ----
 
-. Scale the machine set:
+. Scale down the machine set by running the following command:
 +
 [source,terminal]
 ----
@@ -118,7 +120,7 @@ $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1
 ----
 <1> Where `<machineset_name>` is the name of the machine set and `<n-1>` is the decremented number of worker nodes.
 
-. When the host enters the `Available` state, scale up the machine set to make the `HostFirmwareComponents` resource changes take effect:
+. When the host enters the `Available` state, scale up the machine set to make the `HostFirmwareComponents` resource changes take effect by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/bmo-editing-the-hostfirmwaresettings-resource-of-a-provisioned-host.adoc b/modules/bmo-editing-the-hostfirmwaresettings-resource-of-a-provisioned-host.adoc
new file mode 100644
index 000000000000..f2c0d88e046e
--- /dev/null
+++ b/modules/bmo-editing-the-hostfirmwaresettings-resource-of-a-provisioned-host.adoc
@@ -0,0 +1,100 @@
+// This is included in the following assemblies:
+//
+// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="bmo-editing-the-hostfirmwaresettings-resource-of-a-provisioned-host_{context}"]
+= Editing the HostFirmwareSettings resource of a provisioned host
+
+To make changes to the `HostFirmwareSettings` spec for a provisioned host, perform the following actions:
+
+* Edit the host `HostFirmwareSettings` resource.
+* Delete the host from the machine set.
+* Scale down the machine set.
+* Scale up the machine set to make the changes take effect.
+
+[IMPORTANT]
+====
+You can only edit hosts when they are in the `provisioned` state, excluding read-only values. You cannot edit hosts in the `externally provisioned` state.
+====
+
+.Procedure
+
+. Get the list of `HostFirmwareSettings` resources by running the following command:
++
+[source,terminal]
+----
+$ oc get hfs -n openshift-machine-api
+----
+
+. Edit the host `HostFirmwareSettings` resource by running the following command:
++
+[source,terminal]
+----
+$ oc edit hfs <hostname> -n openshift-machine-api
+----
++
+Where `<hostname>` is the name of a provisioned host. The `HostFirmwareSettings` resource will open in the default editor for your terminal.
+
+. Add name and value pairs to the `spec.settings` section by running the following command:
++
+.Example
+[source,terminal]
+----
+spec:
+  settings:
+    name: value <1>
+----
+<1> Use the `FirmwareSchema` resource to identify the available settings for the host. You cannot set values that are read-only.
+
+. Save the changes and exit the editor.
+
+. Get the host machine name by running the following command:
++
+[source,terminal]
+----
+ $ oc get bmh <hostname> -n openshift-machine name
+----
++
+Where `<hostname>` is the name of the host. The terminal displays the machine name under the `CONSUMER` field.
+
+. Annotate the machine to delete it from the machine set by running the following command:
++
+[source,terminal]
+----
+$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
+----
++
+Where `<machine_name>` is the name of the machine to delete.
+
+. Get a list of nodes and count the number of worker nodes by running the following command:
++
+[source,terminal]
+----
+$ oc get nodes
+----
+
+. Get the machine set by running the following command:
++
+[source,terminal]
+----
+$ oc get machinesets -n openshift-machine-api
+----
+
+. Scale the machine set by running the following command:
++
+[source,terminal]
+----
+$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
+----
++
+Where `<machineset_name>` is the name of the machine set and `<n-1>` is the decremented number of worker nodes.
+
+. When the host enters the `Available` state, scale up the machine set to make the `HostFirmwareSettings` resource changes take effect by running the following command:
++
+[source,terminal]
+----
+$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
+----
++
+Where `<machineset_name>` is the name of the machine set and `<n>` is the number of worker nodes.
diff --git a/modules/bmo-editing-the-hostfirmwaresettings-resource.adoc b/modules/bmo-editing-the-hostfirmwaresettings-resource.adoc
deleted file mode 100644
index 9660ec94c922..000000000000
--- a/modules/bmo-editing-the-hostfirmwaresettings-resource.adoc
+++ /dev/null
@@ -1,96 +0,0 @@
-// This is included in the following assemblies:
-//
-// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="bmo-editing-the-hostfirmwaresettings-resource_{context}"]
-= Editing the HostFirmwareSettings resource
-
-You can edit the `HostFirmwareSettings` of provisioned hosts.
-
-[IMPORTANT]
-====
-You can only edit hosts when they are in the `provisioned` state, excluding read-only values. You cannot edit hosts in the `externally provisioned` state.
-
-====
-
-.Procedure
-
-. Get the list of `HostFirmwareSettings` resources:
-+
-[source,terminal]
-----
-$ oc get hfs -n openshift-machine-api
-----
-
-. Edit a host's `HostFirmwareSettings` resource:
-+
-[source,terminal]
-----
-$ oc edit hfs <host_name> -n openshift-machine-api
-----
-+
-Where `<host_name>` is the name of a provisioned host. The `HostFirmwareSettings` resource will open in the default editor for your terminal.
-
-. Add name/value pairs to the `spec.settings` section:
-+
-.Example
-[source,terminal]
-----
-spec:
-  settings:
-    name: value <1>
-----
-<1> Use the `FirmwareSchema` resource to identify the available settings for the host. You cannot set values that are read-only.
-
-. Save the changes and exit the editor.
-
-. Get the host's machine name:
-+
-[source,terminal]
-----
- $ oc get bmh <host_name> -n openshift-machine name
-----
-+
-Where `<host_name>` is the name of the host. The machine name appears under the `CONSUMER` field.
-
-. Annotate the machine to delete it from the machineset:
-+
-[source,terminal]
-----
-$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
-----
-+
-Where `<machine_name>` is the name of the machine to delete.
-
-. Get a list of nodes and count the number of worker nodes:
-+
-[source,terminal]
-----
-$ oc get nodes
-----
-
-. Get the machineset:
-+
-[source,terminal]
-----
-$ oc get machinesets -n openshift-machine-api
-----
-
-. Scale the machineset:
-+
-[source,terminal]
-----
-$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
-----
-+
-Where `<machineset_name>` is the name of the machineset and `<n-1>` is the decremented number of worker nodes.
-
-. When the host enters the `Available` state, scale up the machineset to make the `HostFirmwareSettings` resource changes take effect:
-+
-[source,terminal]
-----
-$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
-----
-+
-Where `<machineset_name>` is the name of the machineset and `<n>` is the number of worker nodes.
diff --git a/modules/bmo-getting-the-firmwareschema-resource.adoc b/modules/bmo-getting-the-firmwareschema-resource.adoc
index 0fec18ca30b9..7bf56dc4c5eb 100644
--- a/modules/bmo-getting-the-firmwareschema-resource.adoc
+++ b/modules/bmo-getting-the-firmwareschema-resource.adoc
@@ -10,14 +10,14 @@ Each host model from each vendor has different BIOS settings. When editing the `
 
 .Procedure
 
-. To get a list of `FirmwareSchema` resource instances, execute the following:
+. Get the list of `FirmwareSchema` resource instances by running the following command:
 +
 [source,terminal]
 ----
 $ oc get firmwareschema -n openshift-machine-api
 ----
 
-. To get a particular `FirmwareSchema` instance, execute:
+. Get a particular `FirmwareSchema` instance by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/bmo-getting-the-hostfirmwarecomponents-resource.adoc b/modules/bmo-getting-the-hostfirmwarecomponents-resource.adoc
index 0edddac6c43b..0a492cb6908f 100644
--- a/modules/bmo-getting-the-hostfirmwarecomponents-resource.adoc
+++ b/modules/bmo-getting-the-hostfirmwarecomponents-resource.adoc
@@ -1,7 +1,7 @@
 // This is included in the following assemblies:
 //
 // * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
-
+:_mod-docs-content-type: PROCEDURE
 [id="bmo-getting-the-hostfirmwarecomponents-resource_{context}"]
 = Getting the HostFirmwareComponents resource
 
@@ -9,21 +9,21 @@ The `HostFirmwareComponents` resource contains the specific firmware version of
 
 .Procedure
 
-. Get the detailed list of `HostFirmwareComponents` resources:
+. Get the detailed list of `HostFirmwareComponents` resources by running the following command:
 +
 [source,terminal]
 ----
 $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
 ----
 
-. Get the list of `HostFirmwareComponents` resources:
+. Get the list of `HostFirmwareComponents` resources by running the following command:
 +
 [source,terminal]
 ----
 $ oc get hostfirmwarecomponents -n openshift-machine-api
 ----
 
-. Get the `HostFirmwareComponents` resource for a particular host:
+. Get the `HostFirmwareComponents` resource for a particular host by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/bmo-getting-the-hostfirmwaresettings-resource.adoc b/modules/bmo-getting-the-hostfirmwaresettings-resource.adoc
index b680459025dd..9d48afaeaaf3 100644
--- a/modules/bmo-getting-the-hostfirmwaresettings-resource.adoc
+++ b/modules/bmo-getting-the-hostfirmwaresettings-resource.adoc
@@ -1,7 +1,7 @@
 // This is included in the following assemblies:
 //
 // * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
-
+:_mod-docs-content-type: PROCEDURE
 [id="bmo-getting-the-hostfirmwaresettings-resource_{context}"]
 = Getting the HostFirmwareSettings resource
 
@@ -9,7 +9,7 @@ The `HostFirmwareSettings` resource contains the vendor-specific BIOS properties
 
 .Procedure
 
-. Get the detailed list of `HostFirmwareSettings` resources:
+. Get the detailed list of `HostFirmwareSettings` resources by running the following command:
 +
 [source,terminal]
 ----
@@ -21,14 +21,14 @@ $ oc get hfs -n openshift-machine-api -o yaml
 You can use `hostfirmwaresettings` as the long form of `hfs` with the `oc get` command.
 ====
 
-. Get the list of `HostFirmwareSettings` resources:
+. Get the list of `HostFirmwareSettings` resources by running the following command:
 +
 [source,terminal]
 ----
 $ oc get hfs -n openshift-machine-api
 ----
 
-. Get the `HostFirmwareSettings` resource for a particular host
+. Get the `HostFirmwareSettings` resource for a particular host by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/bmo-performing-a-live-update-to-the-hostfirmwarecomponents-resource.adoc b/modules/bmo-performing-a-live-update-to-the-hostfirmwarecomponents-resource.adoc
new file mode 100644
index 000000000000..506b02a0cc42
--- /dev/null
+++ b/modules/bmo-performing-a-live-update-to-the-hostfirmwarecomponents-resource.adoc
@@ -0,0 +1,73 @@
+// This is included in the following assemblies:
+//
+// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+:_mod-docs-content-type: PROCEDURE
+[id="bmo-performing-a-live-update-to-the-hostfirmwarecomponents-resource_{context}"]
+= Performing a live update to the HostFirmwareComponents resource
+
+You can perform a live update to the `HostFirmwareComponents` resource on an already provisioned host. Live updates do not trigger deprovisioning and reprovisioning the host.
+
+:FeatureName: Live updating a host
+include::snippets/technology-preview.adoc[]
+:!FeatureName:
+
+[IMPORTANT]
+====
+Do not perform live updates on production hosts. You can perform live updates to the BIOS for testing purposes. We do not recommend that you perform live updates to the BMC on {product-title} {product-version} for test purposes, especially on earlier generation hardware.
+====
+
+.Prerequisites
+
+* The `HostUpdatePolicy` resource must have the `firmwareUpdates` parameter set to `onReboot`.
+
+.Procedure
+
+. Update the `HostFirmwareComponents` resource by running the following command:
++
+[source,terminal]
+----
+$ oc patch hostfirmwarecomponents <hostname> --type merge -p \// <1>
+    '{"spec": {"updates": [{"component": "<type>", \// <2>
+                        "url": "<url>"}]}}' <3>
+----
+<1> Replace `<hostname>` with the name of the host.
+<2> Replace `<type>` with the type of component. Specify `bios` or `bmc`.
+<3> Replace `<url>` with the URL for the component.
++
+[NOTE]
+====
+You can also use the `oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api` command to update the resource.
+====
+
+. Cordon and drain the node by running the following command:
++
+[source,terminal]
+----
+$ oc drain <node_name> --force <1> 
+----
+<1> Replace `<node_name>` with the name of the node.
+
+. Power off the host for a period of 5 minutes by running the following command:
++
+[source,terminal]
+----
+$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
+----
++
+This step ensures that daemonsets or controllers mark any infrastructure pods that might be running on the node as offline, while the remaining nodes handle incoming requests.
+
+. After 5 minutes, power on the host by running the following command:
++
+[source,terminal]
+----
+$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
+----
++
+The servicing operation commences and the Bare Metal Operator (BMO) sets the `operationalStatus` parameter of the `BareMetalHost` to `servicing`. The BMO updates the `operationalStatus` parameter to `OK` after updating the resource. If an error occurs, the BMO updates the `operationalStatus` parameter to `error` and retries the operation.
+
+. Uncordon the node by running the following command:
++
+[source,terminal]
+----
+$ oc uncordon <node_name>
+----
diff --git a/modules/bmo-performing-a-live-update-to-the-hostfirmwaresettings-resource.adoc b/modules/bmo-performing-a-live-update-to-the-hostfirmwaresettings-resource.adoc
new file mode 100644
index 000000000000..92740526985b
--- /dev/null
+++ b/modules/bmo-performing-a-live-update-to-the-hostfirmwaresettings-resource.adoc
@@ -0,0 +1,66 @@
+// This is included in the following assemblies:
+//
+// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+:_mod-docs-content-type: PROCEDURE
+[id="bmo-performing-a-live-update-to-the-hostfirmwaresettings-resource_{context}"]
+= Performing a live update to the HostFirmwareSettings resource
+
+You can perform a live update to the `HostFirmareSettings` resource after it has begun running workloads. Live updates do not trigger deprovisioning and reprovisioning the host.
+
+:FeatureName: Live updating a host
+include::snippets/technology-preview.adoc[]
+:!FeatureName:
+
+.Prerequisites
+
+* The `HostUpdatePolicy` resource must the have `firmwareSettings` parameter set to `onReboot`.
+
+.Procedure
+
+. Update the `HostFirmwareSettings` resource by running the following command:
++
+[source,terminal]
+----
+$ oc patch hostfirmwaresettings <hostname> --type merge -p \// <1>
+    '{"spec": {"settings": {"<name>": "<value>"}}}' <2>
+----
+<1> Replace `<hostname>` with the name of the host.
+<2> Replace `<name>` with the name of the setting. Replace `<value>` with the value of the setting. You can set multiple name-value pairs.
++
+[NOTE]
+====
+Get the `FirmwareSchema` resource to determine which settings the hardware supports and what settings and values you can update. You cannot update read-only values and you cannot update the `FirmwareSchema` resource. You can also use the `oc edit <hostname> hostfirmwaresettings -n openshift-machine-api` command to update the `HostFirmwareSettings` resource.
+====
+
+. Cordon and drain the node by running the following command:
++
+[source,terminal]
+----
+$ oc drain <node_name> --force <1>
+----
+<1> Replace `<node_name>` with the name of the node.
+
+. Power off the host for a period of 5 minutes by running the following command:
++
+[source,terminal]
+----
+$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
+----
++
+This step ensures that daemonsets or controllers can mark any infrastructure pods that might be running on the host as offline, while the remaining hosts handle incoming requests.
+
+. After 5 minutes, power on the host by running the following command:
++
+[source,terminal]
+----
+$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
+----
++
+The servicing operation commences and the Bare Metal Operator (BMO) sets the `operationalStatus` parameter of the `BareMetalHost` to `servicing`. The BMO updates the `operationalStatus` parameter to `OK` after updating the resource. If an error occurs, the BMO updates the `operationalStatus` parameter to `error` and retries the operation.
+
+. Once Ironic completes the update and the host powers up, uncordon the node by running the following command:
++
+[source,terminal]
+----
+$ oc uncordon <node_name>
+----
diff --git a/modules/bmo-setting-the-hostupdatepolicy-resource.adoc b/modules/bmo-setting-the-hostupdatepolicy-resource.adoc
new file mode 100644
index 000000000000..7c2c1a2ff89c
--- /dev/null
+++ b/modules/bmo-setting-the-hostupdatepolicy-resource.adoc
@@ -0,0 +1,47 @@
+// This is included in the following assemblies:
+//
+// * installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc
+:_mod-docs-content-type: PROCEDURE
+
+[id="bmo-setting-the-hostupdatepolicy-resource_{context}"]
+= Setting the HostUpdatePolicy resource
+
+By default, the `HostUpdatePolicy` disables live updates. To enable live updates, use the following procedure.
+
+:FeatureName: Setting the `HostUpdatePolicy` resource
+include::snippets/technology-preview.adoc[]
+:!FeatureName:
+
+.Procedure
+
+. Create the `HostUpdatePolicy` resource by running the following command:
++
+[source,terminal]
+----
+$ vim hup.yaml
+----
++
+You can use any text editor you prefer.
++
+.Example HostUpdatePolicy resource
+[source,yaml]
+----
+apiVersion: metal3.io/v1alpha1
+kind: HostUpdatePolicy
+metadata:
+  name: <hostname> <1>
+  namespace: openshift-machine-api
+spec:
+  firmwareSettings: onReboot
+  firmwareUpdates: onReboot
+----
+<1> Replace `<hostname>` with the name of the host.
+
+. Save the changes to the `hup.yaml` file.
+
+. Apply the policy by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f hup.yaml
+----
diff --git a/modules/bound-sa-tokens-configuring.adoc b/modules/bound-sa-tokens-configuring.adoc
index 5bca7522dc81..d37c9a59a036 100644
--- a/modules/bound-sa-tokens-configuring.adoc
+++ b/modules/bound-sa-tokens-configuring.adoc
@@ -10,17 +10,17 @@ You can configure pods to request bound service account tokens by using volume p
 
 .Prerequisites
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have created a service account. This procedure assumes that the service account is named `build-robot`.
 
 .Procedure
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 . Optional: Set the service account issuer.
 +
 This step is typically not required if the bound tokens are used only within the cluster.
@@ -98,7 +98,7 @@ $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {en
       sleep 1; \
       done
 ----
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 . Configure a pod to use a bound service account token by using volume projection.
 
diff --git a/modules/builds-restricting-build-strategy-globally.adoc b/modules/builds-restricting-build-strategy-globally.adoc
index 8937671956ce..b8580ee097c2 100644
--- a/modules/builds-restricting-build-strategy-globally.adoc
+++ b/modules/builds-restricting-build-strategy-globally.adoc
@@ -9,10 +9,6 @@
 
 You can allow a set of specific users to create builds with a particular strategy.
 
-.Prerequisites
-
-* Disable global access to the build strategy.
-
 .Procedure
 
 * Assign the role that corresponds to the build strategy to a specific user. For
diff --git a/modules/builds-restricting-build-strategy-to-user.adoc b/modules/builds-restricting-build-strategy-to-user.adoc
index 136f41e09612..099787872fae 100644
--- a/modules/builds-restricting-build-strategy-to-user.adoc
+++ b/modules/builds-restricting-build-strategy-to-user.adoc
@@ -9,10 +9,6 @@
 
 Similar to granting the build strategy role to a user globally, you can allow a set of specific users within a project to create builds with a particular strategy.
 
-.Prerequisites
-
-* Disable global access to the build strategy.
-
 .Procedure
 
 * Assign the role that corresponds to the build strategy to a specific user within a project. For example, to add the `system:build-strategy-docker` role within the project `devproject` to the user `devuser`:
diff --git a/modules/builds-running-entitled-builds-with-sharedsecret-objects.adoc b/modules/builds-running-entitled-builds-with-sharedsecret-objects.adoc
index c074881836ef..4e7cadfcf1ed 100644
--- a/modules/builds-running-entitled-builds-with-sharedsecret-objects.adoc
+++ b/modules/builds-running-entitled-builds-with-sharedsecret-objects.adoc
@@ -8,7 +8,7 @@ The `SharedSecret` object allows you to share and synchronize secrets across nam
 
 [IMPORTANT]
 ====
-The Shared Resource CSI Driver feature is now generally available in link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.1[{builds-v2title} 1.1]. This feature is now deprecated in {product-title}. To use this feature, ensure you are using {builds-v2title} 1.1 or a more recent version.
+The Shared Resource CSI Driver feature is now generally available in link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.1[{builds-v2title} 1.1]. This feature is now removed in {product-title} 4.18 and later. To use this feature, ensure that you are using {builds-v2title} 1.1 or later.
 ====
 
 .Prerequisites
diff --git a/modules/c3-assisted-installer-completing-installation-manifests.adoc b/modules/c3-assisted-installer-completing-installation-manifests.adoc
new file mode 100644
index 000000000000..2c565455b069
--- /dev/null
+++ b/modules/c3-assisted-installer-completing-installation-manifests.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-completing-installation-manifests_{context}"]
+= Adding custom manifests
+
+Create, modify, and upload the four mandatory custom manifests provided by Oracle.
+
+* In the `C3/custom_manifests_C3/manifests` folder, the following manifests are mandatory:
+
+** `oci-ccm.yml`
+** `oci-csi.yml`
+
+* In the `C3/custom_manifests_C3/openshift` folder, the following manifests are mandatory:
+
+** `machineconfig-ccm.yml`
+** `machineconfig-csi.yml` 
+
+.Prerequisites
+
+* Prepare the custom manifests. For details, see step 8 in the "Install the Cluster using the RH Assisted Installer UI" section of the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+.Procedure
+
+. Navigate to the *Custom manifests* page.
+
+. Upload and save the `oci-ccm.yml` and `oci-csi.yml` manifest files:
+
+.. In the *Folder* field, select *manifests*.
+
+.. In the *File name* field, enter `oci-ccm.yml`.
+
+.. In the *Content* section, click *Browse*. 
+
+.. Select the *oci-ccm.yml* file from the `C3/custom_ manifest_C3/manifests` folder.
+
+.. Click *Add another manifest* and repeat the previous substeps for the `oci-csi.yml` file.
+
+. Upload and save the `machineconfig-ccm.yml` and `machineconfig-csi.yml` manifest files:
+
+.. Click *Add another manifest*.
+
+.. In the *Folder* field, select *openshift*.
+
+.. In the *File name* field, enter `machineconfig-ccm.yml`.
+
+.. In the *Content* section, click *Browse*. 
+
+.. Select the *machineconfig-ccm.yml* file from the `C3/custom_ manifest_C3/openshift` folder.
+
+.. Click *Add another manifest* and repeat the previous substeps for the `machineconfig-csi.yml` file.
+
+. Click *Next* to save the custom manifests.
+
+. From the *Review and create* page, click *Install cluster* to create your {product-title} cluster. This process takes approximately thirty minutes.
diff --git a/modules/c3-assisted-installer-completing-installation-networking.adoc b/modules/c3-assisted-installer-completing-installation-networking.adoc
new file mode 100644
index 000000000000..862a6681a20b
--- /dev/null
+++ b/modules/c3-assisted-installer-completing-installation-networking.adoc
@@ -0,0 +1,19 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-completing-installation-networking_{context}"]
+= Configuring networking
+
+On the *Networking* page, add the NTP sources for any hosts that display the `Some validations failed` status.
+
+.Procedure
+
+. In the *Host inventory* table, click the *Some validations failed* link for each host displaying this status.
+
+. Click *Add NTP sources*, and then add the IP address `169.254.169.254` for one of the nodes. 
+
+. Wait for 2 - 3 minutes until all the *Some validations failed* indicators disappear. 
+
+. Select *Next*.
\ No newline at end of file
diff --git a/modules/c3-assisted-installer-completing-installation-nodes.adoc b/modules/c3-assisted-installer-completing-installation-nodes.adoc
new file mode 100644
index 000000000000..5fdd00cbd356
--- /dev/null
+++ b/modules/c3-assisted-installer-completing-installation-nodes.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-completing-installation-nodes_{context}"]
+= Assigning node roles
+
+If the Terraform scripts completed successfully, twelve hosts are now listed for the cluster. Three control plane hosts and three compute hosts have the status "Disconnected". Three control plane hosts and three compute hosts have the status "Insufficient". 
+
+Delete the disconnected hosts and assign roles to the remaining hosts. 
+
+.Procedure
+
+. From the link:https://console.redhat.com/openshift/assisted-installer/clusters[{ai-full} web console], select the cluster and navigate to the *Host discovery* page. 
+
+. Delete the six hosts with a "Disconnected" status, by clicking the option button for each host and selecting *Remove host*. The status of the remaining hosts changes from "Insufficient" to "Ready". This process can take up to three minutes.
+
+. From the *Role* column, assign the *Control plane* role to the three nodes with a boot size of 1.10 TB. Assign the *Worker* role to the three nodes with boot size of 100 GB. 
+
+. Rename any hosts with a name shorter than 63 characters, by clicking the option button for the host and selecting *Change hostname*. Otherwise the cluster installation will fail. 
+
+. Click *Next*. 
+
+. On the *Storage* page, click *Next*.
\ No newline at end of file
diff --git a/modules/c3-assisted-installer-opening-cluster.adoc b/modules/c3-assisted-installer-opening-cluster.adoc
new file mode 100644
index 000000000000..65dd9a473490
--- /dev/null
+++ b/modules/c3-assisted-installer-opening-cluster.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-opening-cluster_{context}"]
+= Opening {product-title} from the {oci-c3-no-rt} web console
+
+For instructions to access the {product-title} console from {oci-c3-no-rt}, see step 15 - 17 in the "Install the Cluster using the RH Assisted Installer UI" section of the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
diff --git a/modules/c3-assisted-installer-overview.adoc b/modules/c3-assisted-installer-overview.adoc
new file mode 100644
index 000000000000..c95ca756793f
--- /dev/null
+++ b/modules/c3-assisted-installer-overview.adoc
@@ -0,0 +1,46 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="c3-ai-overview_{context}"]
+= Overview
+
+You can install {product-title} on {oci-c3-no-rt} by using the {ai-full}. 
+
+For an alternative installation method, see "Installing a cluster on {oci-c3} by using the Agent-based Installer".
+
+.Preinstallation considerations
+
+* Ensure that your installation meets the prerequisites specified for Oracle. For details, see the "Access and Considerations" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+* Ensure that your infrastructure is certified and uses a compatible cloud instance type. For details, see link:https://catalog.redhat.com/cloud/detail/216977[Oracle Cloud Infrastructure].
+
+* Ensure that you are performing the installation on a virtual machine.
+
+.Installation process
+
+The installation process builds a bastion host within the designated compartment of the {product-title} cluster. The bastion host is used to run two Terraform scripts:
+
+* The first script builds IAM Resources in the {oci} Home region of the {oci-c3-short} system (two Dynamic Groups and one Policy).
+
+* The second script builds the infrastructure resources on the {oci-c3-short} system to support the {product-title} cluster, including the {product-title} VCN, public and private subnets, load balancers, Internet GW, NAT GW, and DNS server. The script includes all the resources needed to activate the control plane nodes and compute nodes that form a cluster. 
+
+The bastion host is installed in the designated {product-title} Compartment and configured to communicate through a designated {oci-c3-short} DRG Subnet or Internet GW Subnet within the {oci-c3-short} parent tenancy. 
+
+The installation process subsequently provisions three control plane (master) nodes and three compute (worker) nodes, together with the external and internal Load Balancers that form the cluster. This is the standard implementation for {oci-first-no-rt}. 
+
+.Main steps
+
+The main steps of the procedure are as follows:
+
+. Preparing the {oci-c3-short} bastion server.
+
+. Running the Terraform script via the Home region. 
+
+. Preparing the {product-title} image for {oci-first-no-rt}. 
+
+. Running the Terraform script via the {oci-c3-short} region.
+
+. Installing the cluster by using the {ai-full} web console.
+
diff --git a/modules/c3-assisted-installer-preparing-bastion-server.adoc b/modules/c3-assisted-installer-preparing-bastion-server.adoc
new file mode 100644
index 000000000000..d7d4b499bda8
--- /dev/null
+++ b/modules/c3-assisted-installer-preparing-bastion-server.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-preparing-bastian-server_{context}"]
+= Preparing the {oci} bastion server
+
+By implementing a bastion host, you can securely and efficiently manage access to your {oci-c3-no-rt} resources, ensuring that your private instances remain protected and accessible only through a secure, controlled entry point.
+
+.Prerequisites
+
+* See the "Bastion server - prerequisites" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+.Procedure
+
+. Install the bastion server. For details, see the "Bastion Installation" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+. Install the Terraform application which is used to run the Terraform script. For details, see the "Terraform Installation" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+. Install and configure the {oci} command line interface (CLI). For details, see the "Installing and Configuring the {oci} CLI" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
+.Additional resources
+
+* link:https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm[Quick start - Installing the CLI (Oracle documentation)].
\ No newline at end of file
diff --git a/modules/c3-assisted-installer-preparing-image-converting.adoc b/modules/c3-assisted-installer-preparing-image-converting.adoc
new file mode 100644
index 000000000000..11ff53cd6568
--- /dev/null
+++ b/modules/c3-assisted-installer-preparing-image-converting.adoc
@@ -0,0 +1,19 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-assisted-installer-preparing-image-converting_{context}"]
+= Converting and uploading the image to {oci-c3-no-rt}
+
+Convert the ISO image to an {oci} image and upload it to your {oci-c3-short} system from your OCI Home Region Object 
+Store.
+
+.Procedure
+
+. Convert the image from ISO to {oci}.
+. Upload the {oci} image to an {oci} bucket, and generate a Pre-Authenticated Request (PAR) URL.
+. Import the {oci} image to the {oci-c3-short} portal.
+. Copy the Oracle Cloud Identifier (OCID) of the image for use in the next procedure.
+
+For the full procedure, see step 6 - 8 in the "OpenShift Image Preparation" section of the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
\ No newline at end of file
diff --git a/modules/c3-assisted-installer-preparing-image-generating.adoc b/modules/c3-assisted-installer-preparing-image-generating.adoc
new file mode 100644
index 000000000000..36c1018698d2
--- /dev/null
+++ b/modules/c3-assisted-installer-preparing-image-generating.adoc
@@ -0,0 +1,78 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-assisted-installer-preparing-image-generating_{context}"]
+= Generating the image in the {ai-full}
+
+Create a cluster and download the discovery ISO image.
+
+.Procedure
+
+. Log in to link:https://console.redhat.com/[{ai-full} web console] with your credentials.
+
+. In the *Red Hat OpenShift* tile, select *OpenShift*. 
+
+. In the *Red Hat {product-title}* tile, select *Create Cluster*.
+
+. On the *Cluster Type* page, scroll to the end of the *Cloud* tab, and select *Oracle Cloud Infrastructure (virtual machines)*. 
+
+. On the *Create an OpenShift Cluster* page, select the *Interactive* tile.
+
+. On the *Cluster Details* page, complete the following fields:
++
+[cols="1,3",options="header",subs="quotes"]
+|===
+|Field |Action required
+
+|*Cluster name*
+|Specify the name of your {product-title} cluster. This name is the same name you used to create the resource via the Terraform scripts. The name must be between 1-54 characters. It can use lowercase alphanumeric characters or hyphen (-), but must start and end with a lowercase letter or a number.
+
+|*Base domain*
+|Specify the base domain of the cluster. This is the value used for the `zone_dns` variables in the Terraform scripts that run on {oci-c3-short}. Make a note of the value.
+
+|*OpenShift version*
+| Select *OpenShift 4.16.20*. If it is not immediately visible, scroll to the end of the dropdown menu, select *Show all available versions*, and type the version in the search box.
+
+|*Integrate with external partner platforms*
+|Select *Oracle Cloud Infrastructure*.
+
+After you specify this value, the *Include custom manifests* checkbox is selected by default and the *Custom manifests* page is added to the wizard.
+|===
+
+. Leave the default settings for the remaining fields, and click *Next*.
+
+. On the *Operators* page, click *Next*.
+
+. On the *Host Discovery* page, click *Add hosts* and complete the following steps:
++
+[NOTE]
+====
+The minimal ISO image is the mandatory *Provisioning type* for the {oci-first-no-rt}, and cannot be changed.
+====
+
+.. In the *SSH public key* field, add the SSH public key by copying the output of the following command: 
++
+[source,terminal]
+----
+$ cat ~/.ssh/id_rsa.put
+----
++
+The SSH public key will be installed on all {product-title} control plane and compute nodes.
+
+.. Click the *Show proxy settings* checkbox.
+
+.. Add the proxy variables from the `/etc/environment` file of the bastion server that you configured earlier:
++
+[source,terminal]
+----
+http_proxy=http://www-proxy.<your_domain>.com:80 
+https_proxy=http://www-proxy.<your_domain>.com:80 
+no_proxy=localhost,127.0.0.1,1,2,3,4,5,6,7,8,9,0,.<your_domain>.com 
+#(ie.oracle.com,.oraclecorp.com) 
+---- 
+
+.. Click *Generate Discovery ISO* to generate the discovery ISO image file.
+
+. Click *Download Discovery ISO* to save the file to your local system. After you download the ISO file, you can rename it as required, for example `discovery_image_<your_cluster_name>.iso`.
diff --git a/modules/c3-assisted-installer-running-script-via-home.adoc b/modules/c3-assisted-installer-running-script-via-home.adoc
new file mode 100644
index 000000000000..6107a7adaf76
--- /dev/null
+++ b/modules/c3-assisted-installer-running-script-via-home.adoc
@@ -0,0 +1,27 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-running-script-via-home_{context}"]
+= Running the Terraform script via the Home region
+
+Copy the Terraform scripts `createInfraResources.tf` and `terraform.tfvars` onto the bastion server. Then run the `createInfraResources.tf` script to create the Dynamic Group Identity resources on your {oci-c3-short} {oci} Home Region. These resources include dynamic groups, policies, and tags.
+
+.Prerequisites
+
+* You have tenancy privileges to create Dynamic Groups and Policies. If not, you can manually provision them during this procedure.
+
+.Procedure
+
+. Connect to the bastion server via SSH.
+
+. Create `OpenShift\createResourceOnHomeRegion` folders. 
+
+. Copy the `createInfraResources.tf` and `terraform.tfvars` files from the C3_PCA GitHub repository into the `createResourceOnHomeRegion` folder.
+
+. Ensure that you have access to the source environment, and that your C3 certificate has been exported.
+
+. Run the `createInfraResources.tf` Terraform script.
+
+For the full procedure, see the "Terraform Script Execution Part-1 (Run Script via Home Region)" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
\ No newline at end of file
diff --git a/modules/c3-assisted-installer-running-script-via-region.adoc b/modules/c3-assisted-installer-running-script-via-region.adoc
new file mode 100644
index 000000000000..8def1fe8298a
--- /dev/null
+++ b/modules/c3-assisted-installer-running-script-via-region.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-c3-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="c3-ai-running-script-via-region_{context}"]
+= Running the Terraform script via the C3 region
+
+Run the `terraform.tfvars` Terraform script to create all infrastructure resources on {oci-c3-short}. These resources include the {product-title} VCN, public and private subnets, load balancers, internet GW, NAT GW, and DNS server.
+
+This procedure deploys a cluster consisting of three control plane (master) and three compute (worker) nodes. After deployment, you must rename and reboot the nodes. This process temporarily duplicates nodes, requiring manual cleanup in the next procedure.
+
+.Procedure
+
+. Connect to the bastion server via SSH.
+
+. Set the C3 Certificate location and export the certificate. 
+
+. Run the `terraform.tfvars` script to create three control plane nodes and three compute nodes. 
+
+. Update the labels for the control plane and compute nodes.
+
+. Stop and restart the instances one by one on the {oci-c3-short} portal.
+
+For the full procedure, see the "Terraform Script Execution - Part 2" section in the link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_assisted_installer.pdf?source=:em:nl:mt::::PCATP[Oracle documentation].
+
diff --git a/modules/capi-arch-resources.adoc b/modules/capi-arch-resources.adoc
index 88b2221349b5..5fe588308f97 100644
--- a/modules/capi-arch-resources.adoc
+++ b/modules/capi-arch-resources.adoc
@@ -6,11 +6,11 @@
 [id="capi-arch-resources_{context}"]
 = Cluster API primary resources
 
-The Cluster API consists of the following primary resources. For the Technology Preview of this feature, you must create these resources manually in the `openshift-cluster-api` namespace.
+The Cluster API consists of the following primary resources. For the Technology Preview of this feature, you must create some of these resources manually in the `openshift-cluster-api` namespace.
 
 Cluster:: A fundamental unit that represents a cluster that is managed by the Cluster API.
 
-Infrastructure:: A provider-specific resource that defines properties that are shared by all the compute machine sets in the cluster, such as the region and subnets.
+Infrastructure cluster:: A provider-specific resource that defines properties that all of the compute machine sets in the cluster share, such as the region and subnets.
 
 Machine template:: A provider-specific template that defines the properties of the machines that a compute machine set creates.
 
diff --git a/modules/capi-creating-cluster-resource.adoc b/modules/capi-creating-cluster-resource.adoc
index 793d18157045..16abcfb57900 100644
--- a/modules/capi-creating-cluster-resource.adoc
+++ b/modules/capi-creating-cluster-resource.adoc
@@ -43,9 +43,25 @@ spec:
 <2> Specify the infrastructure kind for the cluster.
 The following values are valid:
 +
-* `AWSCluster`: The cluster is running on {aws-first}.
-* `GCPCluster`: The cluster is running on {gcp-first}.
-* `VSphereCluster`: The cluster is running on {vmw-first}.
+|====
+|Cluster cloud provider |Value
+
+|{aws-first}
+|`AWSCluster`
+
+|{gcp-first}
+|`GCPCluster`
+
+|{azure-first}
+|`AzureCluster`
+
+|{rh-openstack-first}
+|`OpenStackCluster`
+
+|{vmw-first}
+|`VSphereCluster`
+
+|====
 --
 
 . Create the cluster CR by running the following command:
diff --git a/modules/capi-creating-machine-set.adoc b/modules/capi-creating-machine-set.adoc
index 7b46a53b8a87..dce60e98e310 100644
--- a/modules/capi-creating-machine-set.adoc
+++ b/modules/capi-creating-machine-set.adoc
@@ -18,7 +18,7 @@ You can create compute machine sets that use the Cluster API to dynamically mana
 
 * You have installed the {oc-first}.
 
-* You have created the cluster, infrastructure, and machine template resources.
+* You have created the cluster and machine template resources.
 
 .Procedure
 
@@ -46,6 +46,7 @@ spec:
 # ...
 ----
 <1> Specify a name for the compute machine set.
+The cluster ID, machine role, and region form a typical pattern for this value in the following format: `<cluster_name>-<role>-<region>`.
 <2> Specify the name of the cluster.
 <3> Specify the details for your environment. These parameters are provider specific. For more information, see the sample Cluster API compute machine set YAML for your provider.
 --
diff --git a/modules/capi-creating-machine-template.adoc b/modules/capi-creating-machine-template.adoc
index 0591043ccd2d..fb8b9b06ef33 100644
--- a/modules/capi-creating-machine-template.adoc
+++ b/modules/capi-creating-machine-template.adoc
@@ -18,7 +18,7 @@ You can create a provider-specific machine template resource by creating a YAML
 
 * You have installed the {oc-first}.
 
-* You have created and applied the cluster and infrastructure resources.
+* You have created and applied the cluster resource.
 
 .Procedure
 
@@ -36,10 +36,28 @@ spec:
   template:
     spec: # <3>
 ----
-<1> Specify the machine template kind. This value must match the value for your platform. The following values are valid:
-* `AWSMachineTemplate`: The cluster is running on {aws-first}.
-* `GCPMachineTemplate`: The cluster is running on {gcp-first}.
-* `VSphereMachineTemplate`: The cluster is running on {vmw-first}.
+<1> Specify the machine template kind. This value must match the value for your platform.
+The following values are valid:
++
+|====
+|Cluster cloud provider |Value
+
+|{aws-first}
+|`AWSMachineTemplate`
+
+|{gcp-first}
+|`GCPMachineTemplate`
+
+|{azure-first}
+|`AzureMachineTemplate`
+
+|{rh-openstack-first}
+|`OpenStackMachineTemplate`
+
+|{vmw-first}
+|`VSphereMachineTemplate`
+
+|====
 <2> Specify a name for the machine template.
 <3> Specify the details for your environment. These parameters are provider specific. For more information, see the sample Cluster API machine template YAML for your provider.
 --
diff --git a/modules/capi-limitations.adoc b/modules/capi-limitations.adoc
index d15bbbf6a5d4..a3f5836d9e1f 100644
--- a/modules/capi-limitations.adoc
+++ b/modules/capi-limitations.adoc
@@ -15,9 +15,9 @@ Using the Cluster API to manage machines is a Technology Preview feature and has
 Enabling this feature set cannot be undone and prevents minor version updates.
 ====
 
-* Only {aws-first}, {gcp-first}, and {vmw-first} clusters can use the Cluster API.
+* Only {aws-first}, {gcp-first}, {azure-first}, {rh-openstack-first}, and {vmw-first} clusters can use the Cluster API.
 
-* You must manually create the primary resources that the Cluster API requires.
+* You must manually create some of the primary resources that the Cluster API requires.
 For more information, see "Getting started with the Cluster API".
 
 * You cannot use the Cluster API to manage control plane machines.
diff --git a/modules/capi-modifying-machine-template.adoc b/modules/capi-modifying-machine-template.adoc
index 8e6a8afda7a5..ef1a2533ee01 100644
--- a/modules/capi-modifying-machine-template.adoc
+++ b/modules/capi-modifying-machine-template.adoc
@@ -25,10 +25,28 @@ You can update the machine template resource for your cluster by modifying the Y
 ----
 $ oc get <machine_template_kind> <1>
 ----
-<1> Specify the value that corresponds to your platform. The following values are valid:
-* `AWSMachineTemplate`: The cluster is running on {aws-first}.
-* `GCPMachineTemplate`: The cluster is running on {gcp-first}.
-* `VSphereMachineTemplate`: The cluster is running on {vmw-first}.
+<1> Specify the value that corresponds to your platform.
+The following values are valid:
++
+|====
+|Cluster cloud provider |Value
+
+|{aws-full}
+|`AWSMachineTemplate`
+
+|{gcp-full}
+|`GCPMachineTemplate`
+
+|{azure-first}
+|`AzureMachineTemplate`
+
+|{rh-openstack}
+|`OpenStackMachineTemplate`
+
+|{vmw-full}
+|`VSphereMachineTemplate`
+
+|====
 --
 +
 .Example output
@@ -42,7 +60,7 @@ NAME              AGE
 +
 [source,terminal]
 ----
-$ oc get <template_name> -o yaml > <template_name>.yaml
+$ oc get <machine_template_kind> <template_name> -o yaml > <template_name>.yaml
 ----
 +
 where `<template_name>` is the name of the machine template resource for your cluster.
diff --git a/modules/capi-yaml-cluster.adoc b/modules/capi-yaml-cluster.adoc
index 7f26d8515c42..ec38fc16023b 100644
--- a/modules/capi-yaml-cluster.adoc
+++ b/modules/capi-yaml-cluster.adoc
@@ -29,10 +29,24 @@ spec:
 <1> Specify the name of the cluster.
 <2> Specify the IP address of the control plane endpoint and the port used to access it.
 <3> Specify the infrastructure kind for the cluster.
-Valid values are:
+The following values are valid:
 +
---
-* `AWSCluster`: The cluster is running on {aws-full}.
-* `GCPCluster`: The cluster is running on {gcp-full}.
-* `VSphereCluster`: The cluster is running on {vmw-full}.
---
\ No newline at end of file
+|====
+|Cluster cloud provider |Value
+
+|{aws-full}
+|`AWSCluster`
+
+|{gcp-short}
+|`GCPCluster`
+
+|{azure-short}
+|`AzureCluster`
+
+|{rh-openstack}
+|`OpenStackCluster`
+
+|{vmw-full}
+|`VSphereCluster`
+
+|====
\ No newline at end of file
diff --git a/modules/capi-yaml-infrastructure-aws.adoc b/modules/capi-yaml-infrastructure-aws.adoc
deleted file mode 100644
index cfb20233b206..000000000000
--- a/modules/capi-yaml-infrastructure-aws.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-// Module included in the following assemblies:
-//
-// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="capi-yaml-infrastructure-aws_{context}"]
-= Sample YAML for a Cluster API infrastructure resource on {aws-full}
-
-The infrastructure resource is provider-specific and defines properties that are shared by all the compute machine sets in the cluster, such as the region and subnets.
-The compute machine set references this resource when creating machines.
-
-[source,yaml]
-----
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
-kind: AWSCluster # <1>
-metadata:
-  name: <cluster_name> # <2>
-  namespace: openshift-cluster-api
-spec:
-  controlPlaneEndpoint: # <3>
-    host: <control_plane_endpoint_address>
-    port: 6443
-  region: <region> # <4>
-----
-<1> Specify the infrastructure kind for the cluster.
-This value must match the value for your platform.
-<2> Specify the cluster ID as the name of the cluster.
-<3> Specify the address of the control plane endpoint and the port to use to access it.
-<4> Specify the {aws-short} region.
\ No newline at end of file
diff --git a/modules/capi-yaml-infrastructure-gcp.adoc b/modules/capi-yaml-infrastructure-gcp.adoc
deleted file mode 100644
index 96d0a3733118..000000000000
--- a/modules/capi-yaml-infrastructure-gcp.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// Module included in the following assemblies:
-//
-// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-gcp.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="capi-yaml-infrastructure-gcp_{context}"]
-= Sample YAML for a Cluster API infrastructure resource on {gcp-full}
-
-The infrastructure resource is provider-specific and defines properties that are shared by all the compute machine sets in the cluster, such as the region and subnets.
-The compute machine set references this resource when creating machines.
-
-[source,yaml]
-----
-apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-kind: GCPCluster # <1>
-metadata:
-  name: <cluster_name> # <2>
-spec:
-  controlPlaneEndpoint: # <3>
-    host: <control_plane_endpoint_address>
-    port: 6443
-  network:
-    name: <cluster_name>-network
-  project: <project> # <4>
-  region: <region> # <5>
-----
-<1> Specify the infrastructure kind for the cluster.
-This value must match the value for your platform.
-<2> Specify the cluster ID as the name of the cluster.
-<3> Specify the IP address of the control plane endpoint and the port used to access it.
-<4> Specify the {gcp-short} project name.
-<5> Specify the {gcp-short} region.
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-set-aws.adoc b/modules/capi-yaml-machine-set-aws.adoc
index 468aea4cbea0..adb5604cd6e1 100644
--- a/modules/capi-yaml-machine-set-aws.adoc
+++ b/modules/capi-yaml-machine-set-aws.adoc
@@ -7,7 +7,7 @@
 = Sample YAML for a Cluster API compute machine set resource on {aws-full}
 
 The compute machine set resource defines additional properties of the machines that it creates.
-The compute machine set also references the infrastructure resource and machine template when creating machines.
+The compute machine set also references the cluster resource and machine template when creating machines.
 
 [source,yaml]
 ----
@@ -16,28 +16,35 @@ kind: MachineSet
 metadata:
   name: <machine_set_name> # <1>
   namespace: openshift-cluster-api
+  labels:
+    cluster.x-k8s.io/cluster-name: <cluster_name> # <2>
 spec:
   clusterName: <cluster_name> # <2>
   replicas: 1
   selector:
     matchLabels:
       test: example
+      cluster.x-k8s.io/cluster-name: <cluster_name>
+      cluster.x-k8s.io/set-name: <machine_set_name>
   template:
     metadata:
       labels:
         test: example
+        cluster.x-k8s.io/cluster-name: <cluster_name>
+        cluster.x-k8s.io/set-name: <machine_set_name>
+        node-role.kubernetes.io/<role>: ""
     spec:
       bootstrap:
-         dataSecretName: worker-user-data # <3>
+         dataSecretName: worker-user-data
       clusterName: <cluster_name>
       infrastructureRef:
         apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-        kind: AWSMachineTemplate # <4>
-        name: <template_name> # <5>
+        kind: AWSMachineTemplate # <3>
+        name: <template_name> # <4>
 ----
 <1> Specify a name for the compute machine set.
+The cluster ID, machine role, and region form a typical pattern for this value in the following format: `<cluster_name>-<role>-<region>`.
 <2> Specify the cluster ID as the name of the cluster.
-<3> For the Cluster API Technology Preview, the Operator can use the worker user data secret from the `openshift-machine-api` namespace.
-<4> Specify the machine template kind.
+<3> Specify the machine template kind.
 This value must match the value for your platform.
-<5> Specify the machine template name.
+<4> Specify the machine template name.
diff --git a/modules/capi-yaml-machine-set-azure.adoc b/modules/capi-yaml-machine-set-azure.adoc
new file mode 100644
index 000000000000..566ac534d919
--- /dev/null
+++ b/modules/capi-yaml-machine-set-azure.adoc
@@ -0,0 +1,50 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-machine-set-azure_{context}"]
+= Sample YAML for a Cluster API compute machine set resource on {azure-full}
+
+The compute machine set resource defines additional properties of the machines that it creates.
+The compute machine set also references the cluster resource and machine template when creating machines.
+
+[source,yaml]
+----
+apiVersion: cluster.x-k8s.io/v1beta1
+kind: MachineSet
+metadata:
+  name: <machine_set_name> # <1>
+  namespace: openshift-cluster-api
+  labels:
+    cluster.x-k8s.io/cluster-name: <cluster_name> # <2>
+spec:
+  clusterName: <cluster_name>
+  replicas: 1
+  selector:
+    matchLabels:
+      test: example
+      cluster.x-k8s.io/cluster-name: <cluster_name>
+      cluster.x-k8s.io/set-name: <machine_set_name>
+  template:
+    metadata:
+      labels:
+        test: example
+        cluster.x-k8s.io/cluster-name: <cluster_name>
+        cluster.x-k8s.io/set-name: <machine_set_name>
+        node-role.kubernetes.io/<role>: ""
+    spec:
+      bootstrap:
+         dataSecretName: worker-user-data
+      clusterName: <cluster_name>
+      infrastructureRef:
+        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+        kind: AzureMachineTemplate # <3>
+        name: <template_name> # <4>
+----
+<1> Specify a name for the compute machine set.
+The cluster ID, machine role, and region form a typical pattern for this value in the following format: `<cluster_name>-<role>-<region>`.
+<2> Specify the cluster ID as the name of the cluster.
+<3> Specify the machine template kind.
+This value must match the value for your platform.
+<4> Specify the machine template name.
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-set-gcp.adoc b/modules/capi-yaml-machine-set-gcp.adoc
index 784629644233..400a83ee2bd5 100644
--- a/modules/capi-yaml-machine-set-gcp.adoc
+++ b/modules/capi-yaml-machine-set-gcp.adoc
@@ -7,7 +7,7 @@
 = Sample YAML for a Cluster API compute machine set resource on {gcp-full}
 
 The compute machine set resource defines additional properties of the machines that it creates.
-The compute machine set also references the infrastructure resource and machine template when creating machines.
+The compute machine set also references the cluster resource and machine template when creating machines.
 
 [source,yaml]
 ----
@@ -16,30 +16,37 @@ kind: MachineSet
 metadata:
   name: <machine_set_name> # <1>
   namespace: openshift-cluster-api
+  labels:
+    cluster.x-k8s.io/cluster-name: <cluster_name> # <2>
 spec:
   clusterName: <cluster_name> # <2>
   replicas: 1
   selector:
     matchLabels:
       test: example
+      cluster.x-k8s.io/cluster-name: <cluster_name>
+      cluster.x-k8s.io/set-name: <machine_set_name>
   template:
     metadata:
       labels:
         test: example
+        cluster.x-k8s.io/cluster-name: <cluster_name>
+        cluster.x-k8s.io/set-name: <machine_set_name>
+        node-role.kubernetes.io/<role>: ""
     spec:
       bootstrap:
-         dataSecretName: worker-user-data # <3>
+         dataSecretName: worker-user-data
       clusterName: <cluster_name>
       infrastructureRef:
         apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-        kind: GCPMachineTemplate # <4>
-        name: <template_name> # <5>
-      failureDomain: <failure_domain> # <6>
+        kind: GCPMachineTemplate # <3>
+        name: <template_name> # <4>
+      failureDomain: <failure_domain> # <5>
 ----
 <1> Specify a name for the compute machine set.
+The cluster ID, machine role, and region form a typical pattern for this value in the following format: `<cluster_name>-<role>-<region>`.
 <2> Specify the cluster ID as the name of the cluster.
-<3> For the Cluster API Technology Preview, the Operator can use the worker user data secret from the `openshift-machine-api` namespace.
-<4> Specify the machine template kind.
+<3> Specify the machine template kind.
 This value must match the value for your platform.
-<5> Specify the machine template name.
-<6> Specify the failure domain within the {gcp-short} region.
\ No newline at end of file
+<4> Specify the machine template name.
+<5> Specify the failure domain within the {gcp-short} region.
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-set-rhosp.adoc b/modules/capi-yaml-machine-set-rhosp.adoc
new file mode 100644
index 000000000000..7b3015d69ac0
--- /dev/null
+++ b/modules/capi-yaml-machine-set-rhosp.adoc
@@ -0,0 +1,51 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-machine-set-rhosp_{context}"]
+= Sample YAML for a Cluster API compute machine set resource on {rh-openstack}
+
+The compute machine set resource defines additional properties of the machines that it creates.
+The compute machine set also references the infrastructure resource and machine template when creating machines.
+
+[source,yaml]
+----
+apiVersion: cluster.x-k8s.io/v1beta1
+kind: MachineSet
+metadata:
+  name: <machine_set_name> # <1>
+  namespace: openshift-cluster-api
+spec:
+  clusterName: <cluster_name> # <2>
+  replicas: 1
+  selector:
+    matchLabels:
+      test: example
+      cluster.x-k8s.io/cluster-name: <cluster_name>
+      cluster.x-k8s.io/set-name: <machine_set_name>
+  template:
+    metadata:
+      labels:
+        test: example
+        cluster.x-k8s.io/cluster-name: <cluster_name>
+        cluster.x-k8s.io/set-name: <machine_set_name>
+        node-role.kubernetes.io/<role>: ""
+    spec:
+      bootstrap:
+         dataSecretName: worker-user-data # <3>
+      clusterName: <cluster_name>
+      infrastructureRef:
+        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+        kind: OpenStackMachineTemplate # <4>
+        name: <template_name> # <5>
+      failureDomain: <nova_availability_zone> # <6>
+----
+<1> Specify a name for the compute machine set.
+<2> Specify the cluster ID as the name of the cluster.
+<3> For the Cluster API Technology Preview, the Operator can use the worker user data secret from the `openshift-machine-api` namespace.
+<4> Specify the machine template kind.
+This value must match the value for your platform.
+<5> Specify the machine template name.
+<6> Optional: Specify the name of the Nova availability zone for the machine set to create machines in.
+If you do not specify a value, machines are not restricted to a specific availability zone.
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-set-vsphere.adoc b/modules/capi-yaml-machine-set-vsphere.adoc
index afdc2ad61f78..58aac856d60c 100644
--- a/modules/capi-yaml-machine-set-vsphere.adoc
+++ b/modules/capi-yaml-machine-set-vsphere.adoc
@@ -7,7 +7,7 @@
 = Sample YAML for a Cluster API compute machine set resource on {vmw-full}
 
 The compute machine set resource defines additional properties of the machines that it creates.
-The compute machine set also references the infrastructure resource and machine template when creating machines.
+The compute machine set also references the cluster resource and machine template when creating machines.
 
 [source,yaml]
 ----
@@ -16,25 +16,32 @@ kind: MachineSet
 metadata:
   name: <machine_set_name> # <1>
   namespace: openshift-cluster-api
+  labels:
+    cluster.x-k8s.io/cluster-name: <cluster_name> # <2>
 spec:
   clusterName: <cluster_name> # <2>
   replicas: 1
   selector:
     matchLabels:
       test: example
+      cluster.x-k8s.io/cluster-name: <cluster_name>
+      cluster.x-k8s.io/set-name: <machine_set_name>
   template:
     metadata:
       labels:
         test: example
+        cluster.x-k8s.io/cluster-name: <cluster_name>
+        cluster.x-k8s.io/set-name: <machine_set_name>
+        node-role.kubernetes.io/<role>: ""
     spec:
       bootstrap:
-         dataSecretName: worker-user-data # <3>
+         dataSecretName: worker-user-data
       clusterName: <cluster_name>
       infrastructureRef:
         apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-        kind: VSphereMachineTemplate # <4>
-        name: <template_name> # <5>
-      failureDomain: # <6>
+        kind: VSphereMachineTemplate # <3>
+        name: <template_name> # <4>
+      failureDomain: # <5>
         - name: <failure_domain_name>
           region: <region_a>
           zone: <zone_a>
@@ -48,17 +55,17 @@ spec:
             - port-group
 ----
 <1> Specify a name for the compute machine set.
+The cluster ID, machine role, and region form a typical pattern for this value in the following format: `<cluster_name>-<role>-<region>`.
 <2> Specify the cluster ID as the name of the cluster.
-<3> For the Cluster API Technology Preview, the Operator can use the worker user data secret from the `openshift-machine-api` namespace.
-<4> Specify the machine template kind.
+<3> Specify the machine template kind.
 This value must match the value for your platform.
-<5> Specify the machine template name.
-<6> Specify the failure domain configuration details.
+<4> Specify the machine template name.
+<5> Specify the failure domain configuration details.
 +
 [NOTE]
 ====
 Using multiple regions and zones on a {vmw-short} cluster that uses the Cluster API is not a validated configuration.
 ====
 // This callout section can be updated if this configuration is validated. (see also: additional resources in cluster-api-config-options-vsphere.adoc)
-// <6> Specify one or more failure domains.
+// <5> Specify one or more failure domains.
 // For more information about specifying multiple regions and zones on a {vmw-short} cluster, see "Multiple regions and zones configuration for a cluster on {vmw-full}."
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-template-azure.adoc b/modules/capi-yaml-machine-template-azure.adoc
new file mode 100644
index 000000000000..9121bd4766b2
--- /dev/null
+++ b/modules/capi-yaml-machine-template-azure.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-azure.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-machine-template-azure_{context}"]
+= Sample YAML for a Cluster API machine template resource on {azure-full}
+
+The machine template resource is provider-specific and defines the basic properties of the machines that a compute machine set creates.
+The compute machine set references this template when creating machines.
+
+[source,yaml]
+----
+apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+kind: AzureMachineTemplate # <1>
+metadata:
+  name: <template_name> # <2>
+  namespace: openshift-cluster-api
+spec:
+  template:
+    spec: # <3>
+      disableExtensionOperations: true
+      identity: UserAssigned
+      image:
+        id: /subscriptions/<subscription_id>/resourceGroups/<cluster_name>-rg/providers/Microsoft.Compute/galleries/gallery_<compliant_cluster_name>/images/<cluster_name>-gen2/versions/latest # <4> 
+      networkInterfaces:
+        - acceleratedNetworking: true
+          privateIPConfigs: 1
+          subnetName: <cluster_name>-worker-subnet
+      osDisk:
+        diskSizeGB: 128
+        managedDisk:
+          storageAccountType: Premium_LRS
+        osType: Linux
+      sshPublicKey: <ssh_key_value>
+      userAssignedIdentities:
+        - providerID: 'azure:///subscriptions/<subscription_id>/resourcegroups/<cluster_name>-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<cluster_name>-identity'
+      vmSize: Standard_D4s_v3
+----
+<1> Specify the machine template kind.
+This value must match the value for your platform.
+<2> Specify a name for the machine template.
+<3> Specify the details for your environment.
+The values here are examples.
+<4> Specify an image that is compatible with your instance type. 
+The Hyper-V generation V2 images created by the installation program have a `-gen2` suffix, while V1 images have the same name without the suffix.
++
+[NOTE]
+====
+Default {product-title} cluster names contain hyphens (`-`), which are not compatible with {azure-short} gallery name requirements.
+The value of `<compliant_cluster_name>` in this configuration must use underscores (`_`) instead of hyphens to comply with these requirements.
+Other instances of `<cluster_name>` do not change.
+
+For example, a cluster name of `jdoe-test-2m2np` transforms to `jdoe_test_2m2np`.
+The full string for `gallery_<compliant_cluster_name>` in this example is `gallery_jdoe_test_2m2np`, not `gallery_jdoe-test-2m2np`.
+The complete value of `spec.template.spec.image.id` for this example value is `/subscriptions/<subscription_id>/resourceGroups/jdoe-test-2m2np-rg/providers/Microsoft.Compute/galleries/gallery_jdoe_test_2m2np/images/jdoe-test-2m2np-gen2/versions/latest`.
+====
\ No newline at end of file
diff --git a/modules/capi-yaml-machine-template-rhosp.adoc b/modules/capi-yaml-machine-template-rhosp.adoc
new file mode 100644
index 000000000000..d34720cd8840
--- /dev/null
+++ b/modules/capi-yaml-machine-template-rhosp.adoc
@@ -0,0 +1,34 @@
+// Module included in the following assemblies:
+//
+// * machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-rhosp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="capi-yaml-machine-template-rhosp_{context}"]
+= Sample YAML for a Cluster API machine template resource on {rh-openstack}
+
+The machine template resource is provider-specific and defines the basic properties of the machines that a compute machine set creates.
+The compute machine set references this template when creating machines.
+
+[source,yaml]
+----
+apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+kind: OpenStackMachineTemplate # <1>
+metadata:
+  name: <template_name> # <2>
+  namespace: openshift-cluster-api
+spec:
+  template:
+    spec: # <3>
+      flavor: <openstack_node_machine_flavor> # <4>
+      image:
+        filter:
+          name: <openstack_image> # <5>
+----
+<1> Specify the machine template kind.
+This value must match the value for your platform.
+<2> Specify a name for the machine template.
+<3> Specify the details for your environment.
+The values here are examples.
+<4> Specify the {rh-openstack} flavor to use.
+For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/configuring_the_compute_service_for_instance_creation/assembly_creating-flavors-for-launching-instances_instance-flavors[Creating flavors for launching instances].
+<5> Specify the image to use.
\ No newline at end of file
diff --git a/modules/cco-ccoctl-configuring.adoc b/modules/cco-ccoctl-configuring.adoc
index db8ea4cb73f8..5b9fdddf3ba0 100644
--- a/modules/cco-ccoctl-configuring.adoc
+++ b/modules/cco-ccoctl-configuring.adoc
@@ -1,7 +1,7 @@
 // Module included in the following assemblies:
 //
 //Postinstall  and update content
-// * post_installation_configuration/cluster-tasks.adoc
+// * post_installation_configuration/changing-cloud-credentials-configuration.adoc
 // * updating/preparing_for_updates/preparing-manual-creds-update.adoc
 //
 //Platforms that must use `ccoctl` and update content
@@ -169,155 +169,8 @@ ifdef::update[]
 * You have extracted the `CredentialsRequest` custom resources (CRs) from the {product-title} release image and ensured that a namespace that matches the text in the `spec.secretRef.namespace` field exists in the cluster.
 endif::update[]
 
-//AWS permissions needed when running ccoctl during install (I think we can omit from upgrade, since they already have an appropriate AWS account if they are upgrading).
-ifdef::aws-sts[]
-* You have created an AWS account for the `ccoctl` utility to use with the following permissions:
-+
-.Required AWS permissions
-[%collapsible]
-====
-**Required `iam` permissions**
-
-* `iam:CreateOpenIDConnectProvider`
-* `iam:CreateRole`
-* `iam:DeleteOpenIDConnectProvider`
-* `iam:DeleteRole`
-* `iam:DeleteRolePolicy`
-* `iam:GetOpenIDConnectProvider`
-* `iam:GetRole`
-* `iam:GetUser`
-* `iam:ListOpenIDConnectProviders`
-* `iam:ListRolePolicies`
-* `iam:ListRoles`
-* `iam:PutRolePolicy`
-* `iam:TagOpenIDConnectProvider`
-* `iam:TagRole`
-
-**Required `s3` permissions**
-
-* `s3:CreateBucket`
-* `s3:DeleteBucket`
-* `s3:DeleteObject`
-* `s3:GetBucketAcl`
-* `s3:GetBucketTagging`
-* `s3:GetObject`
-* `s3:GetObjectAcl`
-* `s3:GetObjectTagging`
-* `s3:ListBucket`
-* `s3:PutBucketAcl`
-* `s3:PutBucketPolicy`
-* `s3:PutBucketPublicAccessBlock`
-* `s3:PutBucketTagging`
-* `s3:PutObject`
-* `s3:PutObjectAcl`
-* `s3:PutObjectTagging`
-
-**Required `cloudfront` permissions**
-
-* `cloudfront:ListCloudFrontOriginAccessIdentities`
-* `cloudfront:ListDistributions`
-* `cloudfront:ListTagsForResource`
-====
-+
-If you plan to store the OIDC configuration in a private S3 bucket that is accessed by the IAM identity provider through a public CloudFront distribution URL, the AWS account that runs the `ccoctl` utility requires the following additional permissions:
-+
-.Additional permissions for a private S3 bucket with CloudFront
-[%collapsible]
-====
-* `cloudfront:CreateCloudFrontOriginAccessIdentity`
-* `cloudfront:CreateDistribution`
-* `cloudfront:DeleteCloudFrontOriginAccessIdentity`
-* `cloudfront:DeleteDistribution`
-* `cloudfront:GetCloudFrontOriginAccessIdentity`
-* `cloudfront:GetCloudFrontOriginAccessIdentityConfig`
-* `cloudfront:GetDistribution`
-* `cloudfront:TagResource`
-* `cloudfront:UpdateDistribution`
-
-[NOTE]
-=====
-These additional permissions support the use of the `--create-private-s3-bucket` option when processing credentials requests with the `ccoctl aws create-all` command.
-=====
-====
-endif::aws-sts[]
-
-//Azure permissions needed when running ccoctl during install.
-ifdef::azure-workload-id[]
-* You have created a global Microsoft Azure account for the `ccoctl` utility to use with the following permissions:
-+
-.Required Azure permissions
-[%collapsible]
-====
-* Microsoft.Resources/subscriptions/resourceGroups/read
-* Microsoft.Resources/subscriptions/resourceGroups/write
-* Microsoft.Resources/subscriptions/resourceGroups/delete
-* Microsoft.Authorization/roleAssignments/read
-* Microsoft.Authorization/roleAssignments/delete
-* Microsoft.Authorization/roleAssignments/write
-* Microsoft.Authorization/roleDefinitions/read
-* Microsoft.Authorization/roleDefinitions/write
-* Microsoft.Authorization/roleDefinitions/delete
-* Microsoft.Storage/storageAccounts/listkeys/action
-* Microsoft.Storage/storageAccounts/delete
-* Microsoft.Storage/storageAccounts/read
-* Microsoft.Storage/storageAccounts/write
-* Microsoft.Storage/storageAccounts/blobServices/containers/write
-* Microsoft.Storage/storageAccounts/blobServices/containers/delete
-* Microsoft.Storage/storageAccounts/blobServices/containers/read
-* Microsoft.ManagedIdentity/userAssignedIdentities/delete
-* Microsoft.ManagedIdentity/userAssignedIdentities/read
-* Microsoft.ManagedIdentity/userAssignedIdentities/write
-* Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read
-* Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
-* Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/delete
-* Microsoft.Storage/register/action
-* Microsoft.ManagedIdentity/register/action
-====
-endif::azure-workload-id[]
-
-//GCP permissions needed when running ccoctl during install.
-ifdef::google-cloud-platform[]
-* You have added one of the following authentication options to the GCP account that the installation program uses:
-
-** The **IAM Workload Identity Pool Admin** role.
-
-** The following granular permissions:
-+
-.Required GCP permissions
-[%collapsible]
-====
-* compute.projects.get
-* iam.googleapis.com/workloadIdentityPoolProviders.create
-* iam.googleapis.com/workloadIdentityPoolProviders.get
-* iam.googleapis.com/workloadIdentityPools.create
-* iam.googleapis.com/workloadIdentityPools.delete
-* iam.googleapis.com/workloadIdentityPools.get
-* iam.googleapis.com/workloadIdentityPools.undelete
-* iam.roles.create
-* iam.roles.delete
-* iam.roles.list
-* iam.roles.undelete
-* iam.roles.update
-* iam.serviceAccounts.create
-* iam.serviceAccounts.delete
-* iam.serviceAccounts.getIamPolicy
-* iam.serviceAccounts.list
-* iam.serviceAccounts.setIamPolicy
-* iam.workloadIdentityPoolProviders.get
-* iam.workloadIdentityPools.delete
-* resourcemanager.projects.get
-* resourcemanager.projects.getIamPolicy
-* resourcemanager.projects.setIamPolicy
-* storage.buckets.create
-* storage.buckets.delete
-* storage.buckets.get
-* storage.buckets.getIamPolicy
-* storage.buckets.setIamPolicy
-* storage.objects.create
-* storage.objects.delete
-* storage.objects.list
-====
-endif::google-cloud-platform[]
+//Permissions requirements (per platform, for install and key rotation)
+include::snippets/ccoctl-provider-permissions-requirements.adoc[]
 
 .Procedure
 
diff --git a/modules/cco-ccoctl-creating-at-once.adoc b/modules/cco-ccoctl-creating-at-once.adoc
index 294fbb8b7924..519313421583 100644
--- a/modules/cco-ccoctl-creating-at-once.adoc
+++ b/modules/cco-ccoctl-creating-at-once.adoc
@@ -204,7 +204,7 @@ $ ccoctl gcp create-all \
   --project=<gcp_project_id> \// <3>
   --credentials-requests-dir=<path_to_credentials_requests_directory> <4>
 ----
-<1> Specify the user-defined name for all created GCP resources used for tracking.
+<1> Specify the user-defined name for all created {gcp-short} resources used for tracking. If you plan to install the {gcp-short} Filestore Container Storage Interface (CSI) Driver Operator, retain this value.
 <2> Specify the GCP region in which cloud resources will be created.
 <3> Specify the GCP project ID in which cloud resources will be created.
 <4> Specify the directory containing the files of `CredentialsRequest` manifests to create GCP service accounts.
diff --git a/modules/ccs-gcp-customer-procedure-wif.adoc b/modules/ccs-gcp-customer-procedure-wif.adoc
index 182c91442c44..62cf745e4143 100644
--- a/modules/ccs-gcp-customer-procedure-wif.adoc
+++ b/modules/ccs-gcp-customer-procedure-wif.adoc
@@ -39,24 +39,45 @@ Besides the required customer procedures listed in _Required customer procedure_
 
 . Install the link:https://console.redhat.com/openshift/downloads[OpenShift Cluster Manager API command-line interface (`ocm`)].
 +
-To use the OCM CLI, you must authenticate against your Red Hat {cluster-manager} account. This is accomplished with the {cluster-manager} API token.
+
+[IMPORTANT]
+====
+[subs="attributes+"]
+OpenShift Cluster Manager API command-line interface (`ocm`) is a Developer Preview feature only.
+For more information about the support scope of Red Hat Developer Preview features, see link:https://access.redhat.com/support/offerings/devpreview/[Developer Preview Support Scope].
+====
 +
-You can obtain your token link:https://console.redhat.com/openshift/token/show[here].
+// To use the OCM CLI, you must authenticate against your Red Hat {cluster-manager} account. This is accomplished with the {cluster-manager} API token.
+// +
+// You can obtain your token link:https://console.redhat.com/openshift/token/show[here].
+
+. To authenticate against your Red Hat {cluster-manager} account, run one of the following commands.
 
-. To authenticate against your Red Hat {cluster-manager} account, run the following command:
+.. If your system supports a web-based browser, run the Red{nbsp}Hat single sign-on (SSO) authorization code command for secure authentication:
 +
+.Syntax
 [source,terminal]
 ----
-$ ocm login --token <token> <1>
+$ ocm login --use-auth-code
 ----
-<1> Replace `<token>` with your {cluster-manager} API token.
 +
-[IMPORTANT]
-====
-[subs="attributes+"]
-OpenShift Cluster Manager API command-line interface (`ocm`) is a Technology Preview feature only.
-For more information about the support scope of Red Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
-====
+Running this command will redirect you to the Red Hat SSO login. Log in with your Red{nbsp}Hat login or email.
++
+.. If you are working with containers, remote hosts, and other environments without a web browser, run the Red{nbsp}Hat single sign-on (SSO) device code command for secure authentication:
+
++
+.Syntax
+[source,terminal]
+----
+$ ocm login --use-device-code
+----
+Running this command will redirect you to the Red{nbsp}Hat SSO login and provide a log in code.
+
++
+
+To switch accounts, logout from https://sso.redhat.com and run the `ocm logout` command in your terminal before attempting to login again.
+
++
 
 . Install the link:https://cloud.google.com/sdk/docs/install[gcloud CLI].
 +
diff --git a/modules/ccs-gcp-customer-procedure.adoc b/modules/ccs-gcp-customer-procedure.adoc
index 828601c815b7..6d04f4e57f35 100644
--- a/modules/ccs-gcp-customer-procedure.adoc
+++ b/modules/ccs-gcp-customer-procedure.adoc
@@ -6,21 +6,33 @@
 
 = Required customer procedure
 
-The Customer Cloud Subscription (CCS) model allows Red Hat to deploy and manage {product-title} into a customer's Google Cloud Platform (GCP) project. Red Hat requires several prerequisites to provide these services.
+The Customer Cloud Subscription (CCS) model allows Red{nbsp}Hat to deploy and manage {product-title} into a customer's Google Cloud Platform (GCP) project. Red Hat requires several prerequisites to provide these services.
 [NOTE]
 ====
 The following requirements in this topic apply to {product-title} on {GCP} clusters created using both the service account and Workload Identity Federation authentication type. For additional requirements that apply to the service account authentication type only, see _Service account authentication type procedure_. For additional requirements that apply to the Workload Identity Federation authentication type only, see _Workload Identity Federation authentication type procedure_.
 ====
 
-[WARNING]
-====
-To use {product-title} in your GCP project, the following GCP organizational policy constraints cannot be in place:
+.Prerequisites
+
+Before using {product-title} in your GCP project, confirm that the following organizational policy constraints are configured correctly where applicable:
 
-* `constraints/iam.allowedPolicyMemberDomains` (This policy constraint is supported only if Red Hat's `DIRECTORY_CUSTOMER_IDs C02k0l5e8` and `C04j7mbwl` are included in the allow list. Use this policy constraint with caution).
+* `constraints/iam.allowedPolicyMemberDomains`
+** This policy constraint is supported only if Red{nbsp}Hat's Directory Customer ID's `C02k0l5e8` and `C04j7mbwl` are included in the allowlist.
 * `constraints/compute.restrictLoadBalancerCreationForTypes`
-* `constraints/compute.requireShieldedVm` (This policy constraint is supported only if the cluster is installed with "Enable Secure Boot support for Shielded VMs" selected during the initial cluster creation).
-* `constraints/compute.vmExternalIpAccess` (This policy constraint is supported when installing a private cluster with GCP Private Service Connect (PSC). For all other cases, this policy constraint is supported only after installation).
+** This policy constraint is supported only when creating a private cluster with GCP Private Service Connect (PSC). You must ensure that the `INTERNAL_TCP_UDP` load balancer type is included in the allowlist or excluded from the deny list.
++
+[IMPORTANT]
 ====
+Although the `EXTERNAL_NETWORK_TCP_UDP` load balancer type is not required when creating a private cluster with GCP Private Service Connect (PSC), disallowing it via this constraint will prevent the cluster from being able to create externally accessible load balancers.
+====
+
+* `constraints/compute.requireShieldedVm`
+** This policy constraint is supported only if the cluster is created with *Enable Secure Boot support for Shielded VMs* selected during the initial cluster creation.
+* `constraints/compute.vmExternalIpAccess`
+** This policy constraint is supported only when creating a private cluster with GCP Private Service Connect (PSC). For all other cluster types, this policy constraint is supported only after cluster creation.
+* `constraints/compute.trustedImageProjects policy`
+** This policy constraint is supported only when the projects `redhat-marketplace-public`, `rhel-cloud`, and `rhcos-cloud` are included in the allowlist. If this policy constraint is enabled and these projects are not included in the allowlist, cluster creation will fail.
+
 
 .Procedure
 
diff --git a/modules/cert-manager-acme-http01.adoc b/modules/cert-manager-acme-http01.adoc
index 338a02a922dc..6b4ac5eea09b 100644
--- a/modules/cert-manager-acme-http01.adoc
+++ b/modules/cert-manager-acme-http01.adoc
@@ -89,22 +89,21 @@ metadata:
   namespace: my-ingress-namespace                                <2>
   annotations:
     cert-manager.io/cluster-issuer: letsencrypt-staging          <3>
-    acme.cert-manager.io/http01-ingress-class: openshift-default <4>
 spec:
-  ingressClassName: openshift-default                            <5>
+  ingressClassName: openshift-default                            <4>
   tls:
   - hosts:
-    - <hostname>                                                 <6>
-    secretName: sample-tls                                       <7>
+    - <hostname>                                                 <5>
+    secretName: sample-tls                                       <6>
   rules:
-  - host: <hostname>                                             <8>
+  - host: <hostname>                                             <7>
     http:
       paths:
       - path: /
         pathType: Prefix
         backend:
           service:
-            name: sample-workload                                <9>
+            name: sample-workload                                <8>
             port:
               number: 80
 ----
@@ -112,11 +111,10 @@ spec:
 <2> Specify the namespace that you created for the Ingress.
 <3> Specify the cluster issuer that you created.
 <4> Specify the Ingress class.
-<5> Specify the Ingress class.
-<6> Replace `<hostname>` with the Subject Alternative Name to be associated with the certificate. This name is used to add DNS names to the certificate.
-<7> Specify the secret to store the created certificate in.
-<8> Replace `<hostname>` with the hostname. You can use the `<host_name>.<cluster_ingress_domain>` syntax to take advantage of the `*.<cluster_ingress_domain>` wildcard DNS record and serving certificate for the cluster. For example, you might use `apps.<cluster_base_domain>`. Otherwise, you must ensure that a DNS record exists for the chosen hostname.
-<9> Specify the name of the service to expose. This example uses a service named `sample-workload`.
+<5> Replace `<hostname>` with the Subject Alternative Name (SAN) to be associated with the certificate. This name is used to add DNS names to the certificate.
+<6> Specify the secret that stores the certificate.
+<7> Replace `<hostname>` with the hostname. You can use the `<host_name>.<cluster_ingress_domain>` syntax to take advantage of the `*.<cluster_ingress_domain>` wildcard DNS record and serving certificate for the cluster. For example, you might use `apps.<cluster_base_domain>`. Otherwise, you must ensure that a DNS record exists for the chosen hostname.
+<8> Specify the name of the service to expose. This example uses a service named `sample-workload`.
 
 .. Create the `Ingress` object by running the following command:
 +
diff --git a/modules/cert-manager-enabling-istio.adoc b/modules/cert-manager-enabling-istio.adoc
new file mode 100644
index 000000000000..becb153d282f
--- /dev/null
+++ b/modules/cert-manager-enabling-istio.adoc
@@ -0,0 +1,37 @@
+// Module included in the following assemblies:
+//
+// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cert-manager-enabling-istio_{context}"]
+= Enabling the Istio-CSR feature
+
+Use this procedure to enable the Istio-CSR feature in {cert-manager-operator}.
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` role.
+
+.Procedure
+
+* Update the deployment for the {cert-manager-operator} to use the config map by running the following command:
++
+[source,terminal]
+----
+$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"UNSUPPORTED_ADDON_FEATURES","value":"IstioCSR=true"}]}}}'
+----
+
+.Verification
+
+. Verify that the deployments have finished rolling out by running the following command:
++
+[source,terminal]
+----
+$ oc rollout status deployment/cert-manager-operator-controller-manager -n cert-manager-operator
+----
++
+.Example output
+[source,terminal]
+----
+deployment "cert-manager-operator-controller-manager" successfully rolled out
+----
\ No newline at end of file
diff --git a/modules/cert-manager-issuer-types.adoc b/modules/cert-manager-issuer-types.adoc
index 240f384ef8ab..1a5ff6fd0ded 100644
--- a/modules/cert-manager-issuer-types.adoc
+++ b/modules/cert-manager-issuer-types.adoc
@@ -12,6 +12,7 @@ The {cert-manager-operator} has been tested with the following issuer types:
 * Certificate Authority (CA)
 * Self-signed
 * link:https://cert-manager.io/docs/configuration/vault/[Vault]
+* link:https://cert-manager.io/docs/configuration/venafi/[Venafi]
 * link:https://www.nokia.com/networks/security-portfolio/netguard/certificate-manager/[Nokia NetGuard Certificate Manager] (NCM)
 * link:https://cloud.google.com/security/products/certificate-authority-service[Google cloud Certificate Authority Service] (Google CAS)
 
@@ -28,6 +29,7 @@ The following table outlines the test coverage for each tested issuer type:
 | CA                                 | Fully Tested       | Ensures basic CA functionality.
 | Self-signed                          | Fully Tested       | Ensures basic self-signed functionality.
 | Vault | Fully Tested   | Limited to standard Vault setups due to infrastructure access constraints.
+| Venafi | Partially tested | Subject to provider-specific limitations.
 | NCM | Partially Tested   | Subject to provider-specific limitations.
 | Google CAS          | Partially Tested       | Compatible with common CA configurations.
 |===
diff --git a/modules/cert-manager-istio-creating-issuer.adoc b/modules/cert-manager-istio-creating-issuer.adoc
new file mode 100644
index 000000000000..b44b77b6eff4
--- /dev/null
+++ b/modules/cert-manager-istio-creating-issuer.adoc
@@ -0,0 +1,76 @@
+// Module included in the following assemblies:
+//
+// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cert-manager-istio-creating-issuer_{context}"]
+= Creating a root CA issuer for the Istio-CSR agent
+
+Use this procedure to create the root CA issuer for Istio-CSR agent.
+
+[NOTE]
+====
+Other supported issuers can be used, except for the ACME issuer, which is not supported. For more information, see "{cert-manager-operator} issuer providers".
+====
+
+* Create a YAML file, for example, `issuer.yaml`, that defines the `Issuer` and `Certificate` objects:
++
+.Example `issuer.yaml` file
+[source,yaml]
+----
+apiVersion: cert-manager.io/v1
+kind: Issuer <1>
+metadata:
+  name: selfsigned
+  namespace: <istio_project_name> <2>
+spec:
+  selfSigned: {}
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: istio-ca
+  namespace: <istio_project_name>
+spec:
+ isCA: true
+  duration: 87600h # 10 years
+  secretName: istio-ca
+  commonName: istio-ca
+  privateKey:
+    algorithm: ECDSA
+    size: 256
+  subject:
+    organizations:
+      - cluster.local
+      - cert-manager
+  issuerRef:
+    name: selfsigned
+    kind: Issuer <1>
+    group: cert-manager.io
+---
+kind: Issuer
+metadata:
+  name: istio-ca
+  namespace: <istio_project_name> <2>
+spec:
+  ca:
+    secretName: istio-ca
+----
+<1> Specify the `Issuer` or `ClusterIssuer`.
+<2> Specify the name of the Istio project.
+
+.Verification
+
+* Verify that the Issuer is created and ready to use by running the following command:
++
+[source,terminal]
+----
+$ oc get issuer istio-ca -n <istio_project_name>
+----
++
+.Example output
+[source,terminal]
+----
+NAME       READY   AGE
+istio-ca   True    3m
+----
diff --git a/modules/cert-manager-istio-csr-installing.adoc b/modules/cert-manager-istio-csr-installing.adoc
new file mode 100644
index 000000000000..75fdf33ccd83
--- /dev/null
+++ b/modules/cert-manager-istio-csr-installing.adoc
@@ -0,0 +1,117 @@
+// Module included in the following assemblies:
+//
+// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cert-manager-istio-csr-installing_{context}"]
+= Creating the `IstioCSR` custom resource
+
+Use this procedure to install the Istio-CSR agent through {cert-manager-operator}.
+
+.Prerequisites
+
+* You have access to the cluster with `cluster-admin` privileges.
+* You have enabled the Istio-CSR feature.
+* You have created the `Issuer` or `ClusterIssuer` resources required for generating certificates for the Istio-CSR agent.
++
+[NOTE]
+====
+If you are using `Issuer` resource, create the `Issuer` and `Certificate` resources in the {SMProductName} or `Istiod` namespace. Certificate requests are generated in the same namespace, and role-based access control (RBAC) is configured accordingly.  
+==== 
+
+.Procedure
+
+. Create a new project for installing Istio-CSR by running the following command. You can use an existing project and skip this step.
++
+[source,terminal]
+----
+$ oc new-project <istio_csr_project_name>
+----
+
+. Create the `IstioCSR` custom resource to enable Istio-CSR agent managed by the {cert-manager-operator} for processing Istio workload and control plane certificate signing requests.
++
+[NOTE]  
+====  
+Only one `IstioCSR` custom resource (CR) is supported at a time. If multiple `IstioCSR` CRs are created, only one will be active. Use the `status` sub-resource of `IstioCSR` to check if a resource is unprocessed.  
+
+* If multiple `IstioCSR` CRs are created simultaneously, none will be processed.  
+* If multiple `IstioCSR` CRs are created sequentially, only the first one will be processed. 
+* To prevent new requests from being rejected, delete any unprocessed `IstioCSR` CRs.
+* The Operator does not automatically remove objects created for `IstioCSR`. If an active `IstioCSR` resource is deleted and a new one is created in a different namespace without removing the previous deployments, multiple `istio-csr` deployments may remain active. This behavior is not recommended and is not supported.    
+====  
+
+.. Create a YAML file, for example, `istiocsr.yaml`, that defines the `IstioCSR` object:
++
+.Example `IstioCSR.yaml` file
+[source,yaml]
+----
+apiVersion: operator.openshift.io/v1alpha1
+kind: IstioCSR
+metadata:
+  name: default
+  namespace: <istio_csr_project_name>
+spec:
+  IstioCSRConfig:
+    certManager:
+      issuerRef:
+        name: istio-ca  <1>
+        kind: Issuer <2>
+        group: cert-manager.io
+    istiodTLSConfig:
+      trustDomain: cluster.local
+    istio:
+      namespace: istio-system
+----
+<1> Specify the `Issuer` or `ClusterIssuer` name. It should be the same name as the CA issuer defined in the `issuer.yaml` file.
+<2> Specify the `Issuer` or `ClusterIssuer` kind. It should be the same kind as the CA issuer defined in the `issuer.yaml` file.
+
+.. Create the `IstioCSR` custom resource by running the following command:
++
+[source,terminal]
+----
+$ oc create -f IstioCSR.yaml
+----
+
+.Verification
+
+. Verify that the Istio-CSR deployment is ready by running the following command:
++
+[source,terminal]
+----
+$ oc get deployment -n <istio_csr_project_name>
+----
++
+.Example output
+[source,terminal]
+----
+NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
+cert-manager-istio-csr   1/1     1            1           24s
+----
+
+. Verify that the Istio-CSR pods are running by running the following command:
++
+[source,terminal]
+----
+$ oc get pod -n <istio_csr_project_name>
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                  	 READY   STATUS	  RESTARTS    AGE
+cert-manager-istio-csr-5c979f9b7c-bv57w  1/1     Running  0           45s
+----
+
+** Verify that the Istio-CSR pod is not reporting any errors in the logs by running the following command:
++
+[source,terminal]
+----
+$ oc -n <istio_csr_project_name> logs <istio_csr_pod_name>
+----
+
+** Verify that the {cert-manager-operator} pod is not reporting any errors by running the following command:
++
+[source,terminal]
+----
+$ oc -n cert-manager-operator logs <cert_manager_operator_pod_name>
+----
\ No newline at end of file
diff --git a/modules/cert-manager-istio-csr-uninstalling.adoc b/modules/cert-manager-istio-csr-uninstalling.adoc
new file mode 100644
index 000000000000..440fc3763bbd
--- /dev/null
+++ b/modules/cert-manager-istio-csr-uninstalling.adoc
@@ -0,0 +1,61 @@
+// Module included in the following assemblies:
+//
+// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cert-manager-istio-csr-uninstalling_{context}"]
+= Uninstalling the Istio-CSR agent managed by {cert-manager-operator}
+
+Use this procedure to uninstall the Istio-CSR agent managed by {cert-manager-operator}.
+
+.Prerequisites
+
+* You have access to the cluster with `cluster-admin` privileges.
+* You have enabled the Istio-CSR feature.
+* You have created the `IstioCSR` custom resource.
+
+.Procedure
+
+. Remove the `IstioCSR` custom resource by running the following command:
++
+[source,terminal]
+----
+$ oc -n <istio-csr_project_name> delete istiocsrs.operator.openshift.io default
+----
+
+. Remove related resources:
++
+[IMPORTANT]
+====
+To avoid disrupting any {SMProductName} or Istio components, ensure that no component is referencing the Istio-CSR service or the certificates issued for Istio before removing the following resources.
+====
+
+.. List the cluster scoped-resources by running the following command and save the names of the listed resources for later reference:
++
+[source,terminal]
+----
+$ oc get clusterrolebindings,clusterroles -l "app=cert-manager-istio-csr,app.kubernetes.io/name=cert-manager-istio-csr"
+----
+
+.. List the resources in Istio-csr deployed namespace by running the following command and save the names of the listed resources for later reference:
++
+[source,terminal]
+----
+$ oc get certificate,deployments,services,serviceaccounts -l "app=cert-manager-istio-csr,app.kubernetes.io/name=cert-manager-istio-csr" -n <istio_csr_project_name>
+----
+
+.. List the resources in {SMProductName} or Istio deployed namespaces by running the following command and save the names of the listed resources for later reference:
++
+[source,terminal]
+----
+$ oc get roles,rolebindings -l "app=cert-manager-istio-csr,app.kubernetes.io/name=cert-manager-istio-csr" -n <istio_csr_project_name>
+----
+
+.. For each resource listed in previous steps, delete the resource by running the following command:
++
+[source,terminal]
+----
+$ oc -n <istio_csr_project_name> delete <resource_type>/<resource_name>
+----
++
+Repeat this process until all of the related resources have been deleted.
diff --git a/modules/cert-manager-istio-csr-updating.adoc b/modules/cert-manager-istio-csr-updating.adoc
new file mode 100644
index 000000000000..ae71dcc8a211
--- /dev/null
+++ b/modules/cert-manager-istio-csr-updating.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="cert-manager-istio-csr-updating_{context}"]
+= Upgrading the {cert-manager-operator} with Istio-CSR feature enabled 
+
+When the Istio-CSR TechPreview feature gate is enabled, the Operator cannot be upgraded. To use to the next available version, you must uninstall the {cert-manager-operator} and remove all Istio-CSR resources before reinstalling it.
\ No newline at end of file
diff --git a/modules/cert-manager-supported-versions.adoc b/modules/cert-manager-supported-versions.adoc
index 7c031dca2352..ff14c8eb0905 100644
--- a/modules/cert-manager-supported-versions.adoc
+++ b/modules/cert-manager-supported-versions.adoc
@@ -5,6 +5,5 @@
 :_mod-docs-content-type: REFERENCE
 [id="cert-manager-operator-supported-versions_{context}"]
 = Supported {cert-manager-operator} versions
-{product-title} {product-version} supports the following versions of {cert-manager-operator}:
 
-* {cert-manager-operator} 1.13
\ No newline at end of file
+For the list of supported versions of the {cert-manager-operator} across different {product-title} releases, see the "Platform Agnostic Operators" section in the link:https://access.redhat.com/support/policy/updates/openshift_operators[{product-title} update and support policy].
\ No newline at end of file
diff --git a/modules/certificate-injection-using-operators.adoc b/modules/certificate-injection-using-operators.adoc
index 17e526a88a87..5eec582d6006 100644
--- a/modules/certificate-injection-using-operators.adoc
+++ b/modules/certificate-injection-using-operators.adoc
@@ -73,7 +73,7 @@ spec:
       volumes:
       - name: trusted-ca
         configMap:
-          name: trusted-ca
+          name: ca-inject
           items:
             - key: ca-bundle.crt <1>
               path: tls-ca-bundle.pem <2>
diff --git a/modules/checking-mco-node-status-configuring.adoc b/modules/checking-mco-node-status-configuring.adoc
new file mode 100644
index 000000000000..7c6fae0056ed
--- /dev/null
+++ b/modules/checking-mco-node-status-configuring.adoc
@@ -0,0 +1,139 @@
+// Module included in the following assemblies:
+//
+// * post_installation_configuration/machine-configuration-tasks.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="checking-mco-node-status-congifuring_{context}"]
+= Checking machine config node status
+
+During the update of a machine config pool (MCP), you can monitor the progress of all control plane and worker nodes in your cluster by using the `oc get machineconfignodes` and `oc describe machineconfignodes` commands. These commands provide information that can be helpful if issues arise during the update and you need to troubleshoot a node.
+
+You cannot use these commands with custom machine config pools.
+
+For more information on the meaning of these fields, see "About checking machine config node status."
+
+.Prerequisites
+
+* You enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`:
++
+[source,terminal]
+----
+$ oc edit featuregate cluster
+----
++
+.Example `FeatureGate` CR
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: FeatureGate
+metadata:
+  name: cluster
+spec:
+  featureSet: TechPreviewNoUpgrade
+----
++
+[WARNING]
+====
+Enabling the `TechPreviewNoUpgrade` feature set on your cluster cannot be undone and prevents minor version updates. This feature set allows you to enable these Technology Preview features on test clusters, where you can fully test them. Do not enable this feature set on production clusters.
+====
++
+After you save the changes, new machine configs are created, the machine config pools are updated, and scheduling on each node is disabled while the change is being applied.
+
+.Procedure
+
+* View the update status of all nodes in the cluster, including the current and desired machine configurations, by running the following command:
++
+[source,terminal]
+----
+$ oc get machineconfignodes
+----
++
+.Example output
+[source,text]
+----
+NAME                                       POOLNAME   DESIREDCONFIG                                      CURRENTCONFIG                                      UPDATED
+ci-ln-mdb23yt-72292-kzdsg-master-0         master     rendered-master-f21b093d20f68a7c06f922ed3ea5fbc8   rendered-master-1abc053eec29e6c945670f39d6dc8afa   False
+ci-ln-mdb23yt-72292-kzdsg-master-1         master     rendered-master-1abc053eec29e6c945670f39d6dc8afa   rendered-master-1abc053eec29e6c945670f39d6dc8afa   True
+ci-ln-mdb23yt-72292-kzdsg-master-2         master     rendered-master-1abc053eec29e6c945670f39d6dc8afa   rendered-master-1abc053eec29e6c945670f39d6dc8afa   True
+ci-ln-mdb23yt-72292-kzdsg-worker-a-gfqjr   worker     rendered-worker-d0130cd74e9e576d7ba78ce166272bfb   rendered-worker-8f61bf839898a4487c3b5263a430e94a   False
+ci-ln-mdb23yt-72292-kzdsg-worker-b-gknq4   worker     rendered-worker-8f61bf839898a4487c3b5263a430e94a   rendered-worker-8f61bf839898a4487c3b5263a430e94a   True
+ci-ln-mdb23yt-72292-kzdsg-worker-c-mffrx   worker     rendered-worker-8f61bf839898a4487c3b5263a430e94a   rendered-worker-8f61bf839898a4487c3b5263a430e94a   True
+----
+
+* View of all machine config node status fields for the nodes in your cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get machineconfignodes -o wide
+----
++
+.Example output
+[source,text]
+----
+NAME                                       POOLNAME   DESIREDCONFIG                                      CURRENTCONFIG                                      UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED   UPDATECOMPATIBLE   UPDATEDFILESANDOS   CORDONEDNODE   DRAINEDNODE   REBOOTEDNODE   RELOADEDCRIO   UNCORDONEDNODE
+ci-ln-g6dr34b-72292-g9btv-master-0         master     rendered-master-d4e122320b351cdbe1df59ddb63ddcfc   rendered-master-6f2064fcb36d2a914de5b0c660dc49ff   False     True             Unknown          False                      False            False     True               Unknown             False          False         False          False          False
+ci-ln-g6dr34b-72292-g9btv-master-1         master     rendered-master-6f2064fcb36d2a914de5b0c660dc49ff   rendered-master-6f2064fcb36d2a914de5b0c660dc49ff   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-g6dr34b-72292-g9btv-master-2         master     rendered-master-6f2064fcb36d2a914de5b0c660dc49ff   rendered-master-6f2064fcb36d2a914de5b0c660dc49ff   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-g6dr34b-72292-g9btv-worker-a-sjh5r   worker     rendered-worker-671b88c8c569fa3f60dc1a27cf9c91f2   rendered-worker-d5534cb730e5e108905fc285c2a42b6c   False     True             Unknown          False                      False            False     True               Unknown             False          False         False          False          False
+ci-ln-g6dr34b-72292-g9btv-worker-b-xthbz   worker     rendered-worker-d5534cb730e5e108905fc285c2a42b6c   rendered-worker-d5534cb730e5e108905fc285c2a42b6c   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-g6dr34b-72292-g9btv-worker-c-gnpd6   worker     rendered-worker-d5534cb730e5e108905fc285c2a42b6c   rendered-worker-d5534cb730e5e108905fc285c2a42b6c   True      False            False            False                      False            False     False              False               False          False         False          False          False
+----
+
+* Check the update status of nodes in a specific machine config pool by running the following command:
++
+[source,terminal]
+----
+$ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name') <1>
+----
++
+.Example output
+[source,text]
+----
+NAME                                       POOLNAME   DESIREDCONFIG                                      CURRENTCONFIG                                      UPDATED
+ci-ln-g6dr34b-72292-g9btv-worker-a-sjh5r   worker     rendered-worker-d5534cb730e5e108905fc285c2a42b6c   rendered-worker-d5534cb730e5e108905fc285c2a42b6c   True
+ci-ln-g6dr34b-72292-g9btv-worker-b-xthbz   worker     rendered-worker-d5534cb730e5e108905fc285c2a42b6c   rendered-worker-faf6b50218a8bbce21f1370866283de5   False
+ci-ln-g6dr34b-72292-g9btv-worker-c-gnpd6   worker     rendered-worker-faf6b50218a8bbce21f1370866283de5   rendered-worker-faf6b50218a8bbce21f1370866283de5   True
+----
+
+* Check the update status of an individual node by running the following command:
++
+[source,terminal]
+----
+$ oc describe machineconfignode/<node_name>
+----
++
+.Example output
+[source,text]
+----
+Name:         <node_name>
+Namespace:
+Labels:       <none>
+Annotations:  <none>
+API Version:  machineconfiguration.openshift.io/v1alpha1
+Kind:         MachineConfigNode
+Metadata:
+  Creation Timestamp:  2023-10-17T13:08:58Z
+  Generation:          1
+  Resource Version:    49443
+  UID:                 4bd758ab-2187-413c-ac42-882e61761b1d
+Spec:
+  Node Ref:
+    Name:         <node_name>
+  Pool:
+    Name:         master
+  ConfigVersion:
+    Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
+Status:
+# ...
+    Message:               Drained node. The drain is complete as the desired drainer matches current drainer: drain-rendered-worker-01f27f752eb84eba917450e43636b210
+    Reason:                UpdateExecutedDrained
+    Status:                True
+    Type:                  Drained
+    Last Transition Time:  2025-01-14T15:45:55Z
+# ...  
+  Config Version:
+    Current:            rendered-master-8110974a5cea69dff5b263237b58abd8
+    Desired:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
+  Observed Generation:  6
+# ...  
+----
diff --git a/modules/checking-mco-node-status.adoc b/modules/checking-mco-node-status.adoc
index ec48b0c6750e..5527f70e4c64 100644
--- a/modules/checking-mco-node-status.adoc
+++ b/modules/checking-mco-node-status.adoc
@@ -2,83 +2,153 @@
 //
 // * post_installation_configuration/machine-configuration-tasks.adoc
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="checking-mco-node-status_{context}"]
-= Checking machine config node status
+= About checking machine config node status
 
-During updates you might want to monitor the progress of individual nodes in case issues arise and you need to troubleshoot a node.
+If you make changes to the default control plane or worker nodes in your cluster, for example by using a machine config or kubelet config, you can get detailed information about the progress of the node updates by using the machine config nodes custom resource. Any change that results in a new machine config triggers the node update process.
 
-To see the status of the Machine Config Operator (MCO) updates to your cluster, use the following `oc` commands:
+You can view this detailed information for nodes in the `control plane` and `worker` machine config pools that were created upon {product-title} installation. You cannot use custom machine config pools.
 
-:FeatureName: Improved MCO state reporting
+The `MachineConfigNode` custom resource allows you to monitor the progress of individual node updates as they move through the upgrade phases. This information can be helpful with troubleshooting if one of the nodes has an issue during the update. The custom resource reports where in the update process the node is at the moment, the phases that have completed, and the phases that are remaining.
+
+:FeatureName: The machine config node custom resource
 include::snippets/technology-preview.adoc[]
 
-.Prerequisites
-* You set `featureSet: TechPreviewNoUpgrade` in your `FeatureGate` custom resource (CR) to enable the feature set capability for your cluster.
+The node update process consists of the following phases and subphases that are tracked by the machine config node custom resource, explained with more detail later in this section:
+
+* *Update Prepared*. The MCO stops the configuration drift monitoring process and verifies that the newly-created machine config can be applied to a node.
+** *UpdateCompatible*
+* *Update Executed*. The MCO cordons and drains the node and applies the new machine config to the node's files and operating system, as needed. It contains the following sub-phases:
+** *Cordoned*
+** *Drained*
+** *AppliedFilesAndOS*
+* *PinnedImageSetsProgressing* The MCO is performing the steps needed to pin and pre-load container images. 
+* *PinnedImageSetsDegraded* The pinned image process failed. You can view the reason for the failure by using the `oc describe machineconfignode` command, as described later in this section.
+* *Update Post update action*. The MCO reboots the node or reloads CRI-O, as needed.
+** *RebootedNode*
+** *ReloadedCRIO*
+* *Update Complete*. The MCO uncordons the nodes, updates the node state to the cluster, and resumes producing node metrics.
+** *Updated*
+** *Uncordoned*
+* *Resumed*. The MCO restarts the config drift monitor process and the node returns to operational state.
+
+As the update moves through these phases, you can query the `MachineConfigNode` custom resource, which reports one of the following conditions for each phase:
+
+* `True`. The phase is complete on that node or the MCO has started that phase on that node.
+* `False`.  The phase is either being executed or will not be executed on that node.
+* `Unknown`. The phase is either being executed on that node or has an error. If the phase has an error, you can use the `oc describe machineconfignodes` command for more information, as described later in this section.
+
+For example, consider a cluster with a newly-created machine config:
+
+[source,terminal]
+----
+$ oc get machineconfig
+----
+
+.Example output
+[source,text]
+----
+# ...
+rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   c00e2c941bc6e236b50e0bf3988e6c790cf2bbb2   3.4.0             6d15h
+rendered-master-a386c2d1550b927d274054124f58be68   c00e2c941bc6e236b50e0bf3988e6c790cf2bbb2   3.4.0             7m26s
+# ...
+rendered-worker-01f27f752eb84eba917450e43636b210   c00e2c941bc6e236b50e0bf3988e6c790cf2bbb2   3.4.0             6d15h <1>
+rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   c00e2c941bc6e236b50e0bf3988e6c790cf2bbb2   3.4.0             7m26s <2>
+# ...
+----
+<1> The current machine config for the control plane and worker nodes.
+<2> A newly-created machine config that is being applied to the control plane and worker nodes.
+
+You can watch as the nodes are updated with the new machine config:
 
-.Procedure
-. Get a summary of update statuses for all nodes in all machine config pools by running the following command:
-+
 [source,terminal]
 ----
 $ oc get machineconfignodes
 ----
-+
+
 .Example output
 [source,text]
 ----
-NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETED   UPDATECOMPLETED   RESUMED
-ip-10-0-12-194.ec2.internal   True      False             False              False                    False              False
-ip-10-0-17-102.ec2.internal   False     True              False              False                    False              False
-ip-10-0-2-232.ec2.internal    False     False             True               False                    False              False
-ip-10-0-59-251.ec2.internal   False     False             False              True                     False              False
-ip-10-0-59-56.ec2.internal    False     False             False              False                    True               True
-ip-10-0-6-214.ec2.internal    False     False             Unknown            False                    False              False
-----
-+
-where:
-+
-UPDATED:: The `True` status indicates that the MCO has applied the current machine config to that particular node. The `False` status indicates that the node is currently updating. The `Unknown` status means the operation is processing.
-UPDATEPREPARED:: The `False` status indicates that the MCO has not started reconciling the new machine configs to be distributed. The `True` status indicates that the MCO has completed this phase of the update. The `Unknown` status means the operation is processing.
-UPDATEEXECUTED:: The `False` status indicates that the MCO has not started cordoning and draining the node. It also indicates that the disk state and operating system have not started updating. The `True` status indicates that the MCO has completed this phase of the update. The `Unknown` status means the operation is processing.
-UPDATEPOSTACTIONCOMPLETED:: The `False` status indicates that the MCO has not started rebooting the node or closing the daemon. The `True` status indicates that the MCO has completed reboot and updating the node status. The `Unknown` status indicates either that an error has occurred during the update process at this phase, or that the MCO is currently applying the update.
-UPDATECOMPLETED:: The `False` status indicates that the MCO has not started uncordoning the node and updating the node state and metrics. The `True` status indicates that the MCO has finished updating the node state and available metrics.
-RESUMED:: The `False` status indicates that the MCO has not started the config drift monitor. The `True` status indicates that the node has resumed operation. The `Unknown` status means the operation is processing.
-+
-[NOTE]
-====
-Within the primary phases previously described, you can have secondary phases which you can use to see the update progression in more detail. You can get more information that includes secondary phases of updates by using the `-o wide` option of the preceding command. This provides the additional `UPDATECOMPATIBLE`, `UPDATEFILESANDOS`, `DRAINEDNODE`, `CORDONEDNODE`, `REBOOTNODE`, `RELOADEDCRIO` and `UNCORDONED` columns. These secondary phases do not always occur and depend on the type of update you want to apply.
-====
-
-. Check the update status of nodes in a specific machine config pool by running the following command:
-+
+NAME                                       POOLNAME   DESIREDCONFIG                                      CURRENTCONFIG                                      UPDATED
+ci-ln-ds73n5t-72292-9xsm9-master-0         master     rendered-master-a386c2d1550b927d274054124f58be68   rendered-master-a386c2d1550b927d274054124f58be68   True
+ci-ln-ds73n5t-72292-9xsm9-master-1         master     rendered-master-a386c2d1550b927d274054124f58be68   rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   False
+ci-ln-ds73n5t-72292-9xsm9-master-2         master     rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   True
+ci-ln-ds73n5t-72292-9xsm9-worker-a-2d8tz   worker     rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   True <1>
+ci-ln-ds73n5t-72292-9xsm9-worker-b-gw5sd   worker     rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   rendered-worker-01f27f752eb84eba917450e43636b210   False <2>
+ci-ln-ds73n5t-72292-9xsm9-worker-c-t227w   worker     rendered-worker-01f27f752eb84eba917450e43636b210   rendered-worker-01f27f752eb84eba917450e43636b210   True <3>
+----
+<1> This node has been updated. The new machine config, `rendered-worker-f351f6947f15cd0380514f4b1c89f8f2`, is shown as the desired and current machine configs.
+<2> This node is currently being updated to the new machine config. The previous and new machine configs are shown as the desired and current machine configs, respectively.
+<3> This node has not yet been updated to the new machine config. The previous machine config is shown as the desired and current machine configs.
+
+.Basic machine config node fields
+[cols="1,4",options="header"]
+|===
+|Field |Meaning
+|`NAME` |The name of the node.
+|`POOLNAME` |The name of the machine config pool associated with that node.
+|`DESIREDCONFIG` |The name of the new machine config that the node updates to.
+|`CURRENTCONFIG` |The name of the current machine configuration on that node.
+|`UPDATED` a|Indicates if the node has been updated with one of the following conditions:
+
+* If `False`, the node is being updated to the new machine configuration shown in the `DESIREDCONFIG` field.
+* If `True`, and the `CURRENTCONFIG` matches the new machine configuration shown in the `DESIREDCONFIG` field, the node has been updated.
+* If `True`, and the `CURRENTCONFIG` matches the old machine configuration shown in the `DESIREDCONFIG` field, that node has not been updated yet.
+|===
+// Field definitions based on https://github.com/openshift/api/pull/1596
+
+You can use the `-o wide` flag to display additional information about the updates:
+
 [source,terminal]
 ----
-$ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name') <1>
+$ oc get machineconfignodes -o wide
 ----
-<1> The name of the pool is the `MachineConfigPool` object name.
-+
+
 .Example output
 [source,text]
 ----
-NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED
-ip-10-0-48-226.ec2.internal   True      False            False            False                      False            False
-ip-10-0-5-241.ec2.internal    True      False            False            False                      False            False
-ip-10-0-74-108.ec2.internal   True      False            False            False                      False            False
+$ oc get machineconfignode -o wide
+NAME                                       POOLNAME   DESIREDCONFIG                                      CURRENTCONFIG                                      UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED   UPDATECOMPATIBLE   UPDATEDFILESANDOS   CORDONEDNODE   DRAINEDNODE   REBOOTEDNODE   RELOADEDCRIO   UNCORDONEDNODE
+ci-ln-ds73n5t-72292-9xsm9-master-0         master     rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-ds73n5t-72292-9xsm9-master-1         master     rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-ds73n5t-72292-9xsm9-master-2         master     rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   rendered-master-23cf200e4ee97daa6e39fdce24c9fb67   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-ds73n5t-72292-9xsm9-worker-a-2d8tz   worker     rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   True      False            False            False                      False            False     False              False               False          False         False          False          False
+ci-ln-ds73n5t-72292-9xsm9-worker-b-gw5sd   worker     rendered-worker-f351f6947f15cd0380514f4b1c89f8f2   rendered-worker-01f27f752eb84eba917450e43636b210   False     True             True             Unknown                    False            False     True               True                True           True          Unknown        False          False
+ci-ln-ds73n5t-72292-9xsm9-worker-c-t227w   worker     rendered-worker-01f27f752eb84eba917450e43636b210   rendered-worker-01f27f752eb84eba917450e43636b210   True      False            False            False                      False            False     False              False               False          False         False          False          False
 ----
 
-. Check the update status of an individual node by running the following command:
-+
+In addition to the fields defined in the previous table, the `-o wide` output displays the following fields:
+
+.Machine config node fields in the `-o wide` output
+[cols="1,4",options="header"]
+|===
+|Phase Name |Definition
+|`UPDATEPREPARED` |Indicates if the MCO is preparing to update the node.
+|`UPDATEEXECUTED` |Indicates if the MCO has completed the body of the update on the node.
+|`UPDATEPOSTACTIONCOMPLETE` |Indicates if the MCO has executed the post-update actions on the node.
+|`UPDATECOMPLETE` |Indicates if the MCO has completed the update on the node.
+|`RESUMED` |Indicates if the node has resumed normal processes.
+|`UPDATECOMPATIBLE` |Indicates if the MCO has determined it can execute the update on the node.
+|`UPDATEDFILESANDOS` |Indicates if the MCO has updated the node files and operating system.
+|`CORDONEDNODE` |Indicates if the MCO has marked the node as not schedulable.
+|`DRAINEDNODE` |Indicates if the MCO has drained the node.
+|`REBOOTEDNODE` |Indicates if the MCO has restarted the node.
+|`RELOADEDCRIO` |Indicates if the MCO has restarted the CRI-O service.
+|`UNCORDONEDNODE` |Indicates if the MCO has marked the node as schedulable.
+|===
+
+For more details on the update status, you can use the `oc describe machineconfignode` command:
+
 [source,terminal]
 ----
-$ oc describe machineconfignode/<node_name> <1>
+$ oc describe machineconfignode/<machine_config_node_name> -o yaml
 ----
-<1> The name of the node is the `MachineConfigNode` object name.
-+
+
 .Example output
 [source,text]
 ----
-Name:         <node_name>
+Name:         <machine_config_node_name> <1>
 Namespace:
 Labels:       <none>
 Annotations:  <none>
@@ -93,26 +163,92 @@ Spec:
   Node Ref:
     Name:         <node_name>
   Pool:
-    Name:         master
+    Name:         worker
   ConfigVersion:
-    Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b <1>
+    Desired: rendered-worker-f351f6947f15cd0380514f4b1c89f8f2 <2>
 Status:
   Conditions:
-    Last Transition Time:  2023-10-17T13:09:02Z
-    Message:               Node has completed update to config rendered-master-cf99e619747ab19165f11e3546c71f1e
-    Reason:                NodeUpgradeComplete
-    Status:                True
+    Last Transition Time:  2025-01-14T17:01:16Z
+    Message:               Node ci-ln-ds73n5t-72292-9xsm9-worker-b-gw5sd needs an update
+    Reason:                Updated
+    Status:                False
     Type:                  Updated
-    Last Transition Time:  2023-10-17T13:09:02Z
-    Message:               This node has not yet entered the UpdatePreparing phase
+    Last Transition Time:  2025-01-14T17:01:18Z
+    Message:               Update is Compatible.
+    Reason:                UpdateCompatible
+    Status:                True
+    Type:                  UpdatePrepared
+    Last Transition Time:  2025-01-14T17:04:08Z
+    Message:               Updated the Files and OS on disk as a part of the in progress phase
+    Reason:                AppliedFilesAndOS
+    Status:                True
+    Type:                  UpdateExecuted
+    Last Transition Time:  2025-01-14T17:04:08Z
+    Message:               Node will reboot into config rendered-worker-db01b33f959e5645a721da50a6db1fbb
+    Reason:                RebootedNode
+    Status:                Unknown
+    Type:                  UpdatePostActionComplete
+    Last Transition Time:  2025-01-14T16:04:27Z
+    Message:               Action during update to rendered-worker-f351f6947f15cd0380514f4b1c89f8f2: UnCordoned Node as part of completing upgrade phase
+    Reason:                Uncordoned
+    Status:                False
+    Type:                  UpdateComplete
+    Last Transition Time:  2025-01-14T16:04:27Z
+    Message:               Action during update to rendered-worker-f351f6947f15cd0380514f4b1c89f8f2: In desired config rendered-worker-01f27f752eb84eba917450e43636b210. Resumed normal operations.
+    Reason:                Resumed
+    Status:                False
+    Type:                  Resumed
+    Last Transition Time:  2025-01-14T17:01:18Z
+    Message:               Update Compatible. Post Cfg Actions []: Drain Required: true
+    Reason:                UpdatePreparedUpdateCompatible
+    Status:                True
+    Type:                  UpdateCompatible
+    Last Transition Time:  2025-01-14T17:03:57Z
+    Message:               Drained node. The drain is complete as the desired drainer matches current drainer: drain-rendered-worker-db01b33f959e5645a721da50a6db1fbb
+    Reason:                UpdateExecutedDrained
+    Status:                True
+    Type:                  Drained
+    Last Transition Time:  2025-01-14T17:04:08Z
+    Message:               Applied files and new OS config to node. OS did not need an update. SSH Keys did not need an update
+    Reason:                UpdateExecutedAppliedFilesAndOS
+    Status:                True
+    Type:                  AppliedFilesAndOS
+    Last Transition Time:  2025-01-14T17:01:23Z
+    Message:               Cordoned node. The node is reporting Unschedulable = true
+    Reason:                UpdateExecutedCordoned
+    Status:                True
+    Type:                  Cordoned
+    Last Transition Time:  2025-01-14T17:04:08Z
+    Message:               Upgrade requires a reboot. Currently doing this as the post update action.
+    Reason:                UpdatePostActionCompleteRebootedNode
+    Status:                Unknown
+    Type:                  RebootedNode
+    Last Transition Time:  2025-01-14T15:30:57Z
+    Message:               This node has not yet entered the ReloadedCRIO phase
     Reason:                NotYetOccured
     Status:                False
+    Type:                  ReloadedCRIO
+    Last Transition Time:  2025-01-14T16:04:27Z
+    Message:               Action during update to rendered-worker-f351f6947f15cd0380514f4b1c89f8f2: UnCordoned node. The node is reporting Unschedulable = false
+    Reason:                UpdateCompleteUncordoned
+    Status:                False
+    Type:                  Uncordoned
+    Last Transition Time:  2025-01-14T16:04:07Z
+    Message:               All is good
+    Reason:                AsExpected
+    Status:                False
+    Type:                  PinnedImageSetsDegraded
+    Last Transition Time:  2025-01-14T16:04:07Z
+    Message:               All pinned image sets complete
+    Reason:                AsExpected
+    Status:                False
+    Type:                  PinnedImageSetsProgressing
   Config Version:
-    Current:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
-    Desired:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b <2>
-  Health:               Healthy
-  Most Recent Error:
-  Observed Generation:  3
-----
-<1> The desired configuration specified in the `spec.configversion.desired` field updates immediately when a new configuration is detected on the node.
-<2> The desired configuration specified in the `status.configversion.desired` field updates only when the new configuration is validated by the Machine Config Daemon (MCD). The MCD performs validation by checking the current phase of the update. If the update successfully passes the `UPDATEPREPARED` phase, then the status adds the new configuration.
+    Current:            rendered-worker-01f27f752eb84eba917450e43636b210 <3>
+    Desired:            rendered-worker-f351f6947f15cd0380514f4b1c89f8f2
+  Observed Generation:  6
+# ...
+----
+<1> The `MachineConfigNode` object name.
+<2> The new machine configuration. This field updates after the MCO validates the machine config in the `UPDATEPREPARED` phase, then the status adds the new configuration.
+<3> The current machine config on the node.
diff --git a/modules/checking-mco-status.adoc b/modules/checking-mco-status.adoc
index f676ef98eddd..cc749e9cbc2c 100644
--- a/modules/checking-mco-status.adoc
+++ b/modules/checking-mco-status.adoc
@@ -102,13 +102,13 @@ $ oc get machineconfigs
 [source,terminal]
 ----
 NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
-00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
-00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
-01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
-01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
+00-master                        2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
+00-worker                        2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
+01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
+01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.4.0            5h18m
 ...
-rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
-rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
+rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
+rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
 ----
 +
 Note that the `MachineConfig` objects listed as `rendered` are not meant to be changed or deleted.
@@ -130,7 +130,7 @@ Name:         01-master-kubelet
 Spec:
   Config:
     Ignition:
-      Version:  3.2.0
+      Version:  3.4.0
     Storage:
       Files:
         Contents:
diff --git a/modules/cluster-autoscaler-about.adoc b/modules/cluster-autoscaler-about.adoc
index 1dbcebe4686e..022ed10eac30 100644
--- a/modules/cluster-autoscaler-about.adoc
+++ b/modules/cluster-autoscaler-about.adoc
@@ -5,28 +5,42 @@
 // * osd_cluster_admin/osd_nodes/osd-nodes-about-autoscaling-nodes.adoc
 // * osd_cluster_admin/osd-cluster-autoscaling.adoc
 // * rosa_cluster_admin/rosa-cluster-autoscaling.adoc
+// * rosa_cluster_admin/rosa-cluster-autoscaling-hcp.adoc (temporary)
+
 
 :_mod-docs-content-type: CONCEPT
 [id="cluster-autoscaler-about_{context}"]
 = About the cluster autoscaler
 
 The cluster autoscaler adjusts the size of an {product-title} cluster to meet its current deployment needs. It uses declarative, Kubernetes-style arguments to provide infrastructure management that does not rely on objects of a specific cloud provider. The cluster autoscaler has a cluster scope, and is not associated with a particular namespace.
+ifdef::openshift-rosa-hcp[]
+In {product-title}, the Cluster Autoscaler is fully managed, which means it is hosted along with the control plane.
+endif::openshift-rosa-hcp[]
+
 
 The cluster autoscaler increases the size of the cluster when there are pods that fail to schedule on any of the current worker nodes due to insufficient resources or when another node is necessary to meet deployment needs. The cluster autoscaler does not increase the cluster resources beyond the limits that you specify.
 
+ifdef::openshift-rosa-hcp[]
+The cluster autoscaler computes the total memory, CPU, and GPU only on the nodes that belong to autoscaling machine pools. All of the machine pool nodes that are not autoscaling are excluded from this aggregation. For example, if you set the `maxNodesTotal` to `50` on a {product-title} cluster with three machine pools in which a single machine pool is not autoscaling, the cluster autoscaler restricts the total nodes to `50` in only those two machine pools that are autoscaling. The single manually scaling machine pool can have additional nodes, making the overall cluster nodes total more than `50`.
+endif::openshift-rosa-hcp[]
+
+ifndef::openshift-rosa-hcp[]
 The cluster autoscaler computes the total
 ifndef::openshift-dedicated,openshift-rosa[]
 memory, CPU, and GPU
-endif::[]
+endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 memory and CPU
-endif::[]
+endif::openshift-dedicated,openshift-rosa[]
 on all nodes the cluster, even though it does not manage the control plane nodes. These values are not single-machine oriented. They are an aggregation of all the resources in the entire cluster. For example, if you set the maximum memory resource limit, the cluster autoscaler includes all the nodes in the cluster when calculating the current memory usage. That calculation is then used to determine if the cluster autoscaler has the capacity to add more worker resources.
+endif::openshift-rosa-hcp[]
 
+ifndef::openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 Ensure that the `maxNodesTotal` value in the `ClusterAutoscaler` resource definition that you create is large enough to account for the total possible number of machines in your cluster. This value must encompass the number of control plane machines and the possible number of compute machines that you might scale to.
 ====
+endif::openshift-rosa-hcp[]
 
 [discrete]
 [id="cluster-autoscaler-scale-down_{context}"]
diff --git a/modules/cluster-capi-operator.adoc b/modules/cluster-capi-operator.adoc
index f99d0703bc90..82aa589a7a61 100644
--- a/modules/cluster-capi-operator.adoc
+++ b/modules/cluster-capi-operator.adoc
@@ -7,7 +7,7 @@
 
 [NOTE]
 ====
-This Operator is available as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] for {aws-first}, {gcp-first}, and {vmw-first} clusters.
+This Operator is available as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] for {aws-first}, {gcp-first}, {azure-first}, {rh-openstack-first}, and {vmw-first} clusters.
 ====
 
 [discrete]
@@ -26,29 +26,31 @@ link:https://github.com/openshift/cluster-capi-operator[cluster-capi-operator]
 * `awsmachines.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
 ** CR: `awsmachine`
-** Validation: No
 
 *  `gcpmachines.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
 ** CR: `gcpmachine`
-** Validation: No
+
+*  `openstackmachines.infrastructure.cluster.x-k8s.io`
+** Scope: Namespaced
+** CR: `openstackmachine`
 
 *  `vspheremachines.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
 ** CR: `vspheremachine`
-** Validation: No
 
 * `awsmachinetemplates.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
 ** CR: `awsmachinetemplate`
-** Validation: No
 
 *  `gcpmachinetemplates.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
 ** CR: `gcpmachinetemplate`
-** Validation: No
+
+*  `openstackmachinetemplates.infrastructure.cluster.x-k8s.io`
+** Scope: Namespaced
+** CR: `openstackmachinetemplate`
 
 *  `vspheremachinetemplates.infrastructure.cluster.x-k8s.io`
 ** Scope: Namespaced
-** CR: `vspheremachinetemplate`
-** Validation: No
\ No newline at end of file
+** CR: `vspheremachinetemplate`
\ No newline at end of file
diff --git a/modules/cluster-compare-manual-match.adoc b/modules/cluster-compare-manual-match.adoc
index 0104d3a61566..ebd0a609f289 100644
--- a/modules/cluster-compare-manual-match.adoc
+++ b/modules/cluster-compare-manual-match.adoc
@@ -7,9 +7,15 @@
 [id="cluster-compare-manual-match_{context}"]
 = Configuring manual matching between CRs and templates
 
-For scenarios where the `cluster-compare` plugin's default matching does not work as expected, you can manually match a custom resource (CR) to a template. 
+In some cases, the `cluster-compare` plugin's default matching might not work as expected. You can manually define how a custom resource (CR) maps to a template by using a user configuration file.
 
-For example, if there is more than one CR in the cluster with the same `apiversion`, `kind`, `name`, and `namespace` fields, the plugin's default matching compares the CR that features the least differences. To control what CR the plugin chooses, you can create a user configuration YAML file with the manual matching configuration, then pass this configuration file to the `cluster-compare` command.
+By default, the plugin maps a CR to a template based on the `apiversion`, `kind`, `name`, and `namespace` fields. However, multiple templates might match a single CR. For example, this can occur in the following scenarios:
+
+* Multiple templates exist with the same `apiversion`, `kind`, `name`, and `namespace` fields.
+
+* Templates match any CR with a specific `apiversion` and `kind`, regardless of its `namespace` or `name`.
+
+When a CR matches multiple templates, the plugin uses a tie-breaking mechanism that selects the template with the fewest differences. To explicitly control which template the plugin chooses, you can create a user configuration YAML file that defines manual matching rules. You can pass this configuration file to the `cluster-compare` command to enforce the required template selection.
 
 .Procedure
 
@@ -18,12 +24,16 @@ For example, if there is more than one CR in the cluster with the same `apiversi
 .Example `user-config.yaml` file
 [source,yaml]
 ----
-correlationSettings:
-   manualCorrelation:
-      correlationPairs:
-         apps.v1.DaemonSet.kube-system.kindnet.yaml: "template_example.yaml" <1>
+correlationSettings: <1>
+   manualCorrelation: <2>
+      correlationPairs: <3>
+        ptp.openshift.io/v1_PtpConfig_openshift-ptp_grandmaster: optional/ptp-config/PtpOperatorConfig.yaml <4>
+        ptp.openshift.io/v1_PtpOperatorConfig_openshift-ptp_default: optional/ptp-config/PtpOperatorConfig.yaml
 ----
-<1> Specifies the CR and template pair to match. The CR specification uses the following format: `<apiversion>.<kind>.<namespace>.<name>`. For cluster scoped CRs that do not have a namespace, use the format `<apiversion>.<kind>.<name>`.
+<1> The `correlationSettings` section contains the manual correlation settings.
+<2> The `manualCorrelation` section specifies that manual correlation is enabled.
+<3> The `correlationPairs` section lists the CR and template pairs to manually match.
+<4> Specifies the CR and template pair to match. The CR specification uses the following format: `<apiversion>_<kind>_<namespace>_<name>`. For cluster-scoped CRs that do not have a namespace, use the following format: `<apiversion>_<kind>_<name>`. The path to the template must be relative to the `metadata.yaml` file.
 
 . Reference the user configuration file in a `cluster-compare` command by running the following command:
 +
diff --git a/modules/cluster-logging-kibana-scaling.adoc b/modules/cluster-logging-kibana-scaling.adoc
index cd7f3c4a734e..4ff78d1748d8 100644
--- a/modules/cluster-logging-kibana-scaling.adoc
+++ b/modules/cluster-logging-kibana-scaling.adoc
@@ -14,7 +14,7 @@ You can scale the pod that hosts the log visualizer for redundancy.
 +
 [source,terminal]
 ----
-$ oc edit ClusterLogging instance
+$ oc -n openshift-logging edit ClusterLogging instance
 ----
 +
 [source,yaml]
@@ -23,13 +23,13 @@ apiVersion: "logging.openshift.io/v1"
 kind: "ClusterLogging"
 metadata:
   name: "instance"
-
+  namespace: openshift-logging
 ....
 
 spec:
-    visualization:
-      type: "kibana"
-      kibana:
-        replicas: 1 <1>
+  visualization:
+    type: "kibana"
+    kibana:
+      replicas: 1 <1>
 ----
 <1> Specify the number of Kibana nodes.
diff --git a/modules/cluster-resources.adoc b/modules/cluster-resources.adoc
index 863254078ea4..0fb3d07f049c 100644
--- a/modules/cluster-resources.adoc
+++ b/modules/cluster-resources.adoc
@@ -6,12 +6,12 @@ You can interact with cluster resources by using the OpenShift CLI (`oc`) tool i
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the web console or you have installed the `oc` CLI tool.
 
 .Procedure
diff --git a/modules/cluster-wide-proxy-preqs.adoc b/modules/cluster-wide-proxy-preqs.adoc
index 1c9edb82ef36..c9099e69aeda 100644
--- a/modules/cluster-wide-proxy-preqs.adoc
+++ b/modules/cluster-wide-proxy-preqs.adoc
@@ -54,36 +54,5 @@ When using a cluster-wide proxy, you must configure the `s3.<aws_region>.amazona
 |https/443
 |The https://cloud.redhat.com/openshift site uses authentication from sso.redhat.com to download the cluster pull secret and use Red Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, and chargeback reporting.
 |===
-+
-** Your proxy must exclude re-encrypting the following site reliability engineering (SRE) and management URLs:
-+
-[cols="6,1,6",options="header"]
-|===
-|Address | Protocol/Port | Function
-|`*.osdsecuritylogs.splunkcloud.com`
-
-**OR**
-
-`inputs1.osdsecuritylogs.splunkcloud.com`
-`inputs2.osdsecuritylogs.splunkcloud.com`
-`inputs4.osdsecuritylogs.splunkcloud.com`
-`inputs5.osdsecuritylogs.splunkcloud.com`
-`inputs6.osdsecuritylogs.splunkcloud.com`
-`inputs7.osdsecuritylogs.splunkcloud.com`
-`inputs8.osdsecuritylogs.splunkcloud.com`
-`inputs9.osdsecuritylogs.splunkcloud.com`
-`inputs10.osdsecuritylogs.splunkcloud.com`
-`inputs11.osdsecuritylogs.splunkcloud.com`
-`inputs12.osdsecuritylogs.splunkcloud.com`
-`inputs13.osdsecuritylogs.splunkcloud.com`
-`inputs14.osdsecuritylogs.splunkcloud.com`
-`inputs15.osdsecuritylogs.splunkcloud.com`
-|tcp/9997
-|Used by the splunk-forwarder-operator as a log forwarding endpoint to be used by Red Hat SRE for log-based alerting.
-
-|`http-inputs-osdsecuritylogs.splunkcloud.com`
-|https/443
-|Used by the splunk-forwarder-operator as a log forwarding endpoint to be used by Red Hat SRE for log-based alerting.
-|===
 --
 
diff --git a/modules/cnf-about-ptp-and-clock-synchronization.adoc b/modules/cnf-about-ptp-and-clock-synchronization.adoc
index 10e0561a2c16..51b2f195a494 100644
--- a/modules/cnf-about-ptp-and-clock-synchronization.adoc
+++ b/modules/cnf-about-ptp-and-clock-synchronization.adoc
@@ -3,6 +3,7 @@
 // * networking/ptp/about-ptp.adoc
 
 :_mod-docs-content-type: CONCEPT
+:ptp-events-rest-api: v2
 [id="cnf-about-ptp-and-clock-synchronization_{context}"]
 = About PTP and clock synchronization error events
 
@@ -17,7 +18,8 @@ Event notifications are available to vRAN applications running on the same DU no
 A publish/subscribe REST API passes events notifications to the messaging bus.
 Publish/subscribe messaging, or pub-sub messaging, is an asynchronous service-to-service communication architecture where any message published to a topic is immediately received by all of the subscribers to the topic.
 
-The PTP Operator generates fast event notifications for every PTP-capable network interface. You can access the events by using a `cloud-event-proxy` sidecar container over an HTTP message bus.
+The PTP Operator generates fast event notifications for every PTP-capable network interface. 
+The consumer application can subscribe to PTP events by using the PTP events REST API {ptp-events-rest-api}.
 
 [NOTE]
 ====
diff --git a/modules/cnf-about-ptp-fast-event-notifications-framework.adoc b/modules/cnf-about-ptp-fast-event-notifications-framework.adoc
index 1d8c4fc48c7d..8e6cebef1d73 100644
--- a/modules/cnf-about-ptp-fast-event-notifications-framework.adoc
+++ b/modules/cnf-about-ptp-fast-event-notifications-framework.adoc
@@ -11,7 +11,5 @@ Use the Precision Time Protocol (PTP) fast event REST API v2 to subscribe cluste
 
 [NOTE]
 ====
-The fast events notifications framework uses a REST API for communication. The PTP events REST API v1 and v2 are based on the _O-RAN O-Cloud Notification API Specification for Event Consumers 3.0_ that is available from link:https://orandownloadsweb.azurewebsites.net/specifications[O-RAN ALLIANCE Specifications].
-
-Only the PTP events REST API v2 is O-RAN v3 compliant.
+The fast events notifications framework uses a REST API for communication. The PTP events REST API v2 is based on the _O-RAN O-Cloud Notification API Specification for Event Consumers 3.0_ that is available from link:https://orandownloadsweb.azurewebsites.net/specifications[O-RAN ALLIANCE Specifications].
 ====
diff --git a/modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc b/modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc
index 7e8feca993fd..be37b5eef187 100644
--- a/modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc
+++ b/modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc
@@ -2,7 +2,7 @@
 //
 //networking/hardware_networks/configuring-sriov-device.adoc
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="cnf-assigning-a-sriov-network-to-a-vrf_{context}"]
 = Assigning an SR-IOV network to a VRF
 
@@ -16,118 +16,3 @@ Applications that use VRFs need to bind to a specific device. The common usage i
 
 Using a VRF through the `ip vrf exec` command is not supported in {product-title} pods. To use VRF, bind applications directly to the VRF interface.
 ====
-
-[id="cnf-creating-an-additional-sriov-network-with-vrf-plug-in_{context}"]
-== Creating an additional SR-IOV network attachment with the CNI VRF plugin
-
-The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
-
-[NOTE]
-====
-Do not edit `NetworkAttachmentDefinition` custom resources that the SR-IOV Network Operator manages. Doing so might disrupt network traffic on your additional network.
-====
-
-To create an additional SR-IOV network attachment with the CNI VRF plugin, perform the following procedure.
-
-.Prerequisites
-
-* Install the {product-title} CLI (oc).
-* Log in to the {product-title} cluster as a user with cluster-admin privileges.
-
-.Procedure
-
-. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
-+
-[source,yaml]
-----
-apiVersion: sriovnetwork.openshift.io/v1
-kind: SriovNetwork
-metadata:
-  name: example-network
-  namespace: additional-sriov-network-1
-spec:
-  ipam: |
-    {
-      "type": "host-local",
-      "subnet": "10.56.217.0/24",
-      "rangeStart": "10.56.217.171",
-      "rangeEnd": "10.56.217.181",
-      "routes": [{
-        "dst": "0.0.0.0/0"
-      }],
-      "gateway": "10.56.217.1"
-    }
-  vlan: 0
-  resourceName: intelnics
-  metaPlugins : |
-    {
-      "type": "vrf", <1>
-      "vrfname": "example-vrf-name" <2>
-    }
-----
-<1> `type` must be set to `vrf`.
-<2> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
-
-. Create the `SriovNetwork` resource:
-+
-[source,terminal]
-----
-$ oc create -f sriov-network-attachment.yaml
-----
-
-.Verifying that the `NetworkAttachmentDefinition` CR is successfully created
-
-* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command.
-+
-[source,terminal]
-----
-$ oc get network-attachment-definitions -n <namespace> <1>
-----
-<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
-+
-.Example output
-[source,terminal]
-----
-NAME                            AGE
-additional-sriov-network-1      14m
-----
-+
-[NOTE]
-====
-There might be a delay before the SR-IOV Network Operator creates the CR.
-====
-
-.Verifying that the additional SR-IOV network attachment is successful
-
-To verify that the VRF CNI is correctly configured and the additional SR-IOV network attachment is attached, do the following:
-
-. Create an SR-IOV network that uses the VRF CNI.
-. Assign the network to a pod.
-. Verify that the pod network attachment is connected to the SR-IOV additional network. Remote shell into the pod and run the following command:
-+
-[source,terminal]
-----
-$ ip vrf show
-----
-+
-.Example output
-[source,terminal]
-----
-Name              Table
------------------------
-red                 10
-----
-. Confirm the VRF interface is master of the secondary interface:
-+
-[source,terminal]
-----
-$ ip link
-----
-+
-.Example output
-[source,terminal]
-----
-...
-5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
-...
-----
diff --git a/modules/cnf-configuring-kubelet-nro.adoc b/modules/cnf-configuring-kubelet-nro.adoc
index 805d1c5f94e9..e3e09384ab26 100644
--- a/modules/cnf-configuring-kubelet-nro.adoc
+++ b/modules/cnf-configuring-kubelet-nro.adoc
@@ -4,7 +4,7 @@
 
 :_module-type: PROCEDURE
 [id="cnf-configuring-kubelet-config-nro_{context}"]
-= Creating a KubeletConfig CRD
+= Creating a KubeletConfig CR
 
 The recommended way to configure a single NUMA node policy is to apply a performance profile. Another way is by creating and applying a `KubeletConfig` custom resource (CR), as shown in the following procedure.
 
diff --git a/modules/cnf-configuring-power-saving-for-nodes.adoc b/modules/cnf-configuring-power-saving-for-nodes.adoc
index a3ff8cff405a..7155845841a0 100644
--- a/modules/cnf-configuring-power-saving-for-nodes.adoc
+++ b/modules/cnf-configuring-power-saving-for-nodes.adoc
@@ -24,7 +24,7 @@ The feature is supported on Intel Ice Lake and later generations of Intel CPUs.
 [source,terminal,subs="attributes+"]
 ----
 $ podman run --entrypoint performance-profile-creator -v \
-/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v{product-version} \
+/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v{product-version} \
 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \
 --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \
 --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ <1>
diff --git a/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc b/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc
index 35be5e1d50b1..967ff1fe39f5 100644
--- a/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc
+++ b/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc
@@ -29,11 +29,6 @@ endif::[]
 ifeval::["{ptp-events-rest-api}" == "v2"]
 include::snippets/ptp-event-config-api-v2.adoc[]
 endif::[]
-+
-[NOTE]
-====
-In {product-title} 4.13 or later, you do not need to set the `spec.ptpEventConfig.transportHost` field in the `PtpOperatorConfig` resource when you use HTTP transport for PTP events.
-====
 
 .. Update the `PtpOperatorConfig` CR:
 +
diff --git a/modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc b/modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc
new file mode 100644
index 000000000000..0ad76722265a
--- /dev/null
+++ b/modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc
@@ -0,0 +1,120 @@
+// Module included in the following assemblies:
+//
+//networking/hardware_networks/configuring-sriov-device.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cnf-creating-an-additional-sriov-network-with-vrf-plug-in_{context}"]
+= Creating an additional SR-IOV network attachment with the CNI VRF plugin
+
+The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
+
+[NOTE]
+====
+Do not edit `NetworkAttachmentDefinition` custom resources that the SR-IOV Network Operator manages. Doing so might disrupt network traffic on your additional network.
+====
+
+To create an additional SR-IOV network attachment with the CNI VRF plugin, perform the following procedure.
+
+.Prerequisites
+
+* Install the {product-title} CLI (oc).
+* Log in to the {product-title} cluster as a user with cluster-admin privileges.
+
+.Procedure
+
+. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
++
+.Example `SriovNetwork` custom resource (CR) example
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetwork
+metadata:
+  name: example-network
+  namespace: additional-sriov-network-1
+spec:
+  ipam: |
+    {
+      "type": "host-local",
+      "subnet": "10.56.217.0/24",
+      "rangeStart": "10.56.217.171",
+      "rangeEnd": "10.56.217.181",
+      "routes": [{
+        "dst": "0.0.0.0/0"
+      }],
+      "gateway": "10.56.217.1"
+    }
+  vlan: 0
+  resourceName: intelnics
+  metaPlugins : |
+    {
+      "type": "vrf", <1>
+      "vrfname": "example-vrf-name" <2>
+    }
+----
+<1> `type` must be set to `vrf`.
+<2> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
+
+. Create the `SriovNetwork` resource:
++
+[source,terminal]
+----
+$ oc create -f sriov-network-attachment.yaml
+----
+
+.Verifying that the `NetworkAttachmentDefinition` CR is successfully created
+
+* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command:
++
+[source,terminal]
+----
+$ oc get network-attachment-definitions -n <namespace> <1>
+----
+<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
++
+.Example output
+[source,terminal]
+----
+NAME                            AGE
+additional-sriov-network-1      14m
+----
++
+[NOTE]
+====
+There might be a delay before the SR-IOV Network Operator creates the CR.
+====
+
+.Verifying that the additional SR-IOV network attachment is successful
+
+To verify that the VRF CNI is correctly configured and that the additional SR-IOV network attachment is attached, do the following:
+
+. Create an SR-IOV network that uses the VRF CNI.
+. Assign the network to a pod.
+. Verify that the pod network attachment is connected to the SR-IOV additional network. Remote shell into the pod and run the following command:
++
+[source,terminal]
+----
+$ ip vrf show
+----
++
+.Example output
+[source,terminal]
+----
+Name              Table
+-----------------------
+red                 10
+----
+. Confirm that the VRF interface is `master` of the secondary interface by running the following command:
++
+[source,terminal]
+----
+$ ip link
+----
++
+.Example output
+[source,terminal]
+----
+...
+5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
+...
+----
diff --git a/modules/cnf-creating-nrop-cr.adoc b/modules/cnf-creating-nrop-cr.adoc
index 598e7b4d6df6..dea7a0e6a083 100644
--- a/modules/cnf-creating-nrop-cr.adoc
+++ b/modules/cnf-creating-nrop-cr.adoc
@@ -33,7 +33,7 @@ spec:
         pools.operator.machineconfiguration.openshift.io/worker: "" <1>
 ----
 +
-<1> This should match the `MachineConfigPool` that you want to configure the NUMA Resources Operator on. For example, you might have created a `MachineConfigPool` named `worker-cnf` that designates a set of nodes expected to run telecommunications workloads.
+<1> This must match the `MachineConfigPool` resource that you want to configure the NUMA Resources Operator on. For example, you might have created a `MachineConfigPool` resource named `worker-cnf` that designates a set of nodes expected to run telecommunications workloads. Each `NodeGroup` must match exactly one `MachineConfigPool`. Configurations where `NodeGroup` matches more than one `MachineConfigPool` are not supported.
 
 .. Create the `NUMAResourcesOperator` CR by running the following command:
 +
@@ -41,11 +41,29 @@ spec:
 ----
 $ oc create -f nrop.yaml
 ----
+
+. Optional: To enable NUMA-aware scheduling for multiple machine config pools (MCPs), define a separate `NodeGroup` for each pool. For example, define three `NodeGroups` for `worker-cnf`, `worker-ht`, and `worker-other`, in the `NUMAResourcesOperator` CR as shown in the following example:
 +
-[NOTE]
-====
-Creating the `NUMAResourcesOperator` triggers a reboot on the corresponding machine config pool and therefore the affected node.
-====
+.Example YAML definition for a `NUMAResourcesOperator` CR with multiple `NodeGroups`
+[source,yaml]
+----
+apiVersion: nodetopology.openshift.io/v1
+kind: NUMAResourcesOperator
+metadata:
+  name: numaresourcesoperator
+spec:
+  logLevel: Normal
+  nodeGroups:
+    - machineConfigPoolSelector:
+        matchLabels:
+          machineconfiguration.openshift.io/role: worker-ht
+    - machineConfigPoolSelector:
+        matchLabels:
+          machineconfiguration.openshift.io/role: worker-cnf
+    - machineConfigPoolSelector:
+        matchLabels:
+          machineconfiguration.openshift.io/role: worker-other
+----
 
 .Verification
 
diff --git a/modules/cnf-disable-chronyd.adoc b/modules/cnf-disable-chronyd.adoc
index e7554dd6157b..4aa68f0ab3b3 100644
--- a/modules/cnf-disable-chronyd.adoc
+++ b/modules/cnf-disable-chronyd.adoc
@@ -30,7 +30,7 @@ metadata:
 spec:
   config:
     ignition:
-      version: 3.2.0
+      version: 3.4.0
     systemd:
       units:
         - contents: |
@@ -53,6 +53,14 @@ spec:
             WantedBy=multi-user.target
           enabled: false
           name: "chronyd.service"
+        - name: "kubelet-dependencies.target"
+          contents: |
+            [Unit]
+            Description=Dependencies necessary to run kubelet
+            Documentation=https://github.com/openshift/machine-config-operator/
+            Requires=basic.target network-online.target
+            Wants=NetworkManager-wait-online.service crio-wipe.service
+            Wants=rpc-statd.service
 ----
 <1> Node role where you want to disable `chronyd`, for example, `master`.
 
diff --git a/modules/cnf-image-based-upgrade-prep-extramanifests.adoc b/modules/cnf-image-based-upgrade-prep-extramanifests.adoc
index 7e2c1e353570..7010c172ce8b 100644
--- a/modules/cnf-image-based-upgrade-prep-extramanifests.adoc
+++ b/modules/cnf-image-based-upgrade-prep-extramanifests.adoc
@@ -8,6 +8,11 @@
 
 Create additional manifests that you want to apply to the target cluster.
 
+[NOTE]
+====
+If you add more than one extra manifest, and the manifests must be applied in a specific order, you must prefix the filenames of the manifests with numbers that represent the required order. For example, `00-namespace.yaml`, `01-sriov-extra-manifest.yaml`, and so on.
+====
+
 .Procedure
 
 . Create a YAML file that contains your extra manifests, such as SR-IOV.
diff --git a/modules/cnf-image-based-upgrade-prep.adoc b/modules/cnf-image-based-upgrade-prep.adoc
index a2c2b8de1f64..0809cada20d2 100644
--- a/modules/cnf-image-based-upgrade-prep.adoc
+++ b/modules/cnf-image-based-upgrade-prep.adoc
@@ -10,6 +10,18 @@ When you deploy the {lcao} on a cluster, an `ImageBasedUpgrade` custom resource
 After you created all the resources that you need during the upgrade, you can move on to the `Prep` stage.
 For more information, see the "Creating ConfigMap objects for the image-based upgrade with {lcao}" section.
 
+[NOTE]
+====
+In a disconnected environment, if the seed cluster's release image registry is different from the target cluster's release image registry, you must create an `ImageDigestMirrorSet` (IDMS) resource to configure alternative mirrored repository locations. For more information, see "Configuring image registry repository mirroring". 
+
+You can retrieve the release registry used in the seed image by running the following command:
+
+[source,terminal]
+----
+$ skopeo inspect docker://<imagename> | jq -r '.Labels."com.openshift.lifecycle-agent.seed_cluster_info" | fromjson | .release_registry'
+----
+====
+
 .Prerequisites
 
 * You have created resources to back up and restore your clusters.
diff --git a/modules/cnf-image-based-upgrade-seed-image-config.adoc b/modules/cnf-image-based-upgrade-seed-image-config.adoc
index d36ddbdf3a70..23fa62168c61 100644
--- a/modules/cnf-image-based-upgrade-seed-image-config.adoc
+++ b/modules/cnf-image-based-upgrade-seed-image-config.adoc
@@ -68,7 +68,7 @@ endif::[]
 |====
 . Dual-stack networking is not supported in this release.
 . If the seed cluster is installed in a disconnected environment, the target clusters must also be installed in a disconnected environment.
-. The proxy configuration on the seed and target clusters does not have to match.
+. The proxy configuration must be either enabled or disabled in both the seed and target clusters. However, the proxy servers configured on the clusters does not have to match.
 
 [id="ztp-image-based-upgrade-seed-image-config-ran_{context}"]
 == Seed image configuration using the RAN DU profile
diff --git a/modules/cnf-memory-optimization.adoc b/modules/cnf-memory-optimization.adoc
new file mode 100644
index 000000000000..0b0f1d44a44f
--- /dev/null
+++ b/modules/cnf-memory-optimization.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="cnf-configuring-kernal-page-size_{context}"]
+= Configuring memory page sizes
+
+By configuring memory page sizes, system administrators can implement more efficient memory management on a specific node to suit workload requirements. The Node Tuning Operator provides a method for configuring huge pages and kernel page sizes by using a performance profile.
\ No newline at end of file
diff --git a/modules/cnf-numa-resource-scheduling-strategies.adoc b/modules/cnf-numa-resource-scheduling-strategies.adoc
new file mode 100644
index 000000000000..0b659a64fd66
--- /dev/null
+++ b/modules/cnf-numa-resource-scheduling-strategies.adoc
@@ -0,0 +1,72 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/cnf-numa-aware-scheduling.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="cnf-numa-resource-scheduling-strategies_{context}"]
+= NUMA resource scheduling strategies 
+
+When scheduling high-performance workloads, the secondary scheduler can employ different strategies to determine which NUMA node within a chosen worker node will handle the workload. The supported strategies in {product-title} include `LeastAllocated`, `MostAllocated`, and `BalancedAllocation`. Understanding these strategies helps optimize workload placement for performance and resource utilization.
+
+When a high-performance workload is scheduled in a NUMA-aware cluster, the following steps occur: 
+
+.  The scheduler first selects a suitable worker node based on cluster-wide criteria. For example taints, labels, or resource availability.
+
+. After a worker node is selected, the scheduler evaluates its NUMA nodes and applies a scoring strategy to decide which NUMA node will handle the workload.
+
+. After a workload is scheduled, the selected NUMA node’s resources are updated to reflect the allocation.
+
+The default strategy applied is the `LeastAllocated` strategy. This assigns workloads to the NUMA node with the most available resources that is the least utilized NUMA node. The goal of this strategy is to spread workloads across NUMA nodes to reduce contention and avoid hotspots.
+
+The following table summarizes the different strategies and their outcomes:
+
+[discrete]
+[id="cnf-scoringstrategy-summary_{context}"]
+== Scoring strategy summary
+
+.Scoring strategy summary
+[cols="2,3,3", options="header"]
+|===
+|Strategy |Description |Outcome
+|`LeastAllocated` |Favors NUMA nodes with the most available resources. |Spreads workloads to reduce contention and ensure headroom for high-priority tasks.
+|`MostAllocated` |Favors NUMA nodes with the least available resources. |Consolidates workloads on fewer NUMA nodes, freeing others for energy efficiency.
+|`BalancedAllocation` |Favors NUMA nodes with balanced CPU and memory usage. |Ensures even resource utilization, preventing skewed usage patterns.
+|===
+
+[discrete]
+[id="cnf-leastallocated-example_{context}"]
+== LeastAllocated strategy example
+The `LeastAllocated` is the default strategy. This strategy assigns workloads to the NUMA node with the most available resources, minimizing resource contention and spreading workloads across NUMA nodes. This reduces hotspots and ensures sufficient headroom for high-priority tasks. Assume a worker node has two NUMA nodes, and the workload requires 4 vCPUs and 8 GB of memory:
+
+.Example initial NUMA nodes state
+[cols="5,2,2,2,2,2", options="header"]
+|===
+|NUMA node |Total CPUs |Used CPUs |Total memory (GB) |Used memory (GB) |Available resources
+|NUMA 1 |16 |12 |64 |56 |4 CPUs, 8 GB memory
+|NUMA 2 |16 |6 |64 |24 |10 CPUs, 40 GB memory
+|===
+
+Because NUMA 2 has more available resources compared to NUMA 1, the workload is assigned to NUMA 2.
+
+[discrete]
+[id="cnf-mostallocated-example_{context}"]
+== MostAllocated strategy example
+The `MostAllocated` strategy consolidates workloads by assigning them to the NUMA node with the least available resources, which is the most utilized NUMA node. This approach helps free other NUMA nodes for energy efficiency or critical workloads requiring full isolation. This example uses the "Example initial NUMA nodes state" values listed in the `LeastAllocated` section.
+
+The workload again requires 4 vCPUs and 8 GB memory. NUMA 1 has fewer available resources compared to NUMA 2, so the scheduler assigns the workload to NUMA 1, further utilizing its resources while leaving NUMA 2 idle or minimally loaded.
+
+[discrete]
+[id="cnf-balanceallocated-example_{context}"]
+== BalancedAllocation strategy example
+The `BalancedAllocation` strategy assigns workloads to the NUMA node with the most balanced resource utilization across CPU and memory. The goal is to prevent imbalanced usage, such as high CPU utilization with underutilized memory. Assume a worker node has the following NUMA node states:
+
+.Example NUMA nodes initial state for `BalancedAllocation`
+[cols="2,2,2,2",options="header"]
+|===
+|NUMA node |CPU usage |Memory usage |`BalancedAllocation` score
+|NUMA 1 |60% |55% |High (more balanced)
+|NUMA 2 |80% |20% |Low (less balanced)
+|===
+
+NUMA 1 has a more balanced CPU and memory utilization compared to NUMA 2 and therefore, with the `BalancedAllocation` strategy in place, the workload is assigned to NUMA 1.  
+
diff --git a/modules/cnf-scheduling-exact-based-on-reource.adoc b/modules/cnf-scheduling-exact-based-on-reource.adoc
new file mode 100644
index 000000000000..43032ead1980
--- /dev/null
+++ b/modules/cnf-scheduling-exact-based-on-reource.adoc
@@ -0,0 +1,121 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/cnf-numa-aware-scheduling.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cnf-changing-where-high-performance-workloads-run_{context}"]
+= Changing where high-performance workloads run 
+
+The NUMA-aware secondary scheduler is responsible for scheduling high-performance workloads on a worker node and within a NUMA node where the workloads can be optimally processed. By default, the secondary scheduler assigns workloads to the NUMA node within the chosen worker node that has the most available resources.
+
+If you want to change where the workloads run, you can add the `scoringStrategy` setting to the `NUMAResourcesScheduler` custom resource and set its value to either `MostAllocated`  or `BalancedAllocation`.  
+
+.Prerequisites
+
+* Install the OpenShift CLI (`oc`).
+* Log in as a user with `cluster-admin` privileges.
+
+.Procedure
+
+. Delete the currently running `NUMAResourcesScheduler` resource by using the following steps:
+
+.. Get the active `NUMAResourcesScheduler` by running the following command:
++
+[source,terminal]
+----
+$ oc get NUMAResourcesScheduler
+----
++
+.Example output
+[source,terminal]
+----
+NAME                     AGE
+numaresourcesscheduler   92m
+----
+
+.. Delete the secondary scheduler resource by running the following command:
++
+[source,terminal]
+----
+$ oc delete NUMAResourcesScheduler numaresourcesscheduler
+----
++
+.Example output
+[source,terminal]
+----
+numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
+----
+
+. Save the following YAML in the file `nro-scheduler-mostallocated.yaml`. This example changes the `scoringStrategy` to `MostAllocated`:
++
+[source,yaml]
+----
+apiVersion: nodetopology.openshift.io/v1
+kind: NUMAResourcesScheduler
+metadata:
+  name: numaresourcesscheduler
+spec:
+  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v{product-version}"
+  scoringStrategy:
+        type: "MostAllocated" <1>
+----
+<1> If the `scoringStrategy` configuration is omitted, the default of `LeastAllocated` applies.
+
+. Create the updated `NUMAResourcesScheduler` resource by running the following command:
++
+[source,terminal]
+----
+$ oc create -f nro-scheduler-mostallocated.yaml
+----
++
+.Example output
+[source,terminal]
+----
+numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
+----
+
+.Verification
+
+. Check that the NUMA-aware scheduler was successfully deployed by using the following steps:
+
+.. Run the following command to check that the custom resource definition (CRD) is created successfully:
++
+[source,terminal]
+----
+$ oc get crd | grep numaresourcesschedulers
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                                              CREATED AT
+numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
+----
+
+.. Check that the new custom scheduler is available by running the following command:
++
+[source,terminal]
+----
+$ oc get numaresourcesschedulers.nodetopology.openshift.io
+----
++
+.Example output
+[source,terminal]
+----
+NAME                     AGE
+numaresourcesscheduler   3h26m
+----
+
+. Verify that the `ScoringStrategy` has been applied correctly by running the following command to check the relevant `ConfigMap` resource for the scheduler: 
++
+[source,terminal]
+----
+$ oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1
+----
++
+.Example output
+[source,terminal]
+----
+scoringStrategy:
+  type: MostAllocated
+----
\ No newline at end of file
diff --git a/modules/compliance-crd-advanced-compliance-scan.adoc b/modules/compliance-crd-advanced-compliance-scan.adoc
index 20e41665c218..d58320611276 100644
--- a/modules/compliance-crd-advanced-compliance-scan.adoc
+++ b/modules/compliance-crd-advanced-compliance-scan.adoc
@@ -13,7 +13,7 @@ The Compliance Operator includes options for advanced users for debugging or int
 apiVersion: compliance.openshift.io/v1alpha1
 kind: ComplianceScan
 metadata:
-  name: <name of the scan>
+  name: <name_of_the_compliance_scan>
 spec:
   scanType: Node <1>
   profile: xccdf_org.ssgproject.content_profile_moderate <2>
@@ -55,5 +55,5 @@ You can programmatically fetch the `ComplianceScans` events. To generate events
 
 [source,terminal]
 ----
-oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name of the suite>
+oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name_of_the_compliance_scan>
 ----
diff --git a/modules/compliance-crd-compliance-suite.adoc b/modules/compliance-crd-compliance-suite.adoc
index 33c089441f84..0e736880b15a 100644
--- a/modules/compliance-crd-compliance-suite.adoc
+++ b/modules/compliance-crd-compliance-suite.adoc
@@ -15,7 +15,7 @@ For `Node` type scans, you should map the scan to the `MachineConfigPool`, since
 apiVersion: compliance.openshift.io/v1alpha1
 kind: ComplianceSuite
 metadata:
-  name: <name of the scan>
+  name: <name_of_the_suite>
 spec:
   autoApplyRemediations: false <1>
   schedule: "0 1 * * *" <2>
diff --git a/modules/compliance-supported-profiles.adoc b/modules/compliance-supported-profiles.adoc
index fe7bfc983d9b..bb3a5d282980 100644
--- a/modules/compliance-supported-profiles.adoc
+++ b/modules/compliance-supported-profiles.adoc
@@ -313,6 +313,8 @@ The following tables reflect the latest available profiles in the Compliance Ope
 |Platform
 |link:https://www.pcisecuritystandards.org/document_library?document=pci_dss[PCI Security Standards &#174; Council Document Library]
 |`x86_64`
+ `ppc64le`
+ `s390x`
 |
 
 |ocp4-pci-dss-4-0
@@ -334,6 +336,8 @@ The following tables reflect the latest available profiles in the Compliance Ope
 |Node ^[2]^
 |link:https://www.pcisecuritystandards.org/document_library?document=pci_dss[PCI Security Standards &#174; Council Document Library]
 |`x86_64`
+ `ppc64le`
+ `s390x`
 |{product-rosa} with {hcp} (ROSA HCP)
 
 |ocp4-pci-dss-node-4-0
diff --git a/modules/configuration-externalip.adoc b/modules/configuration-externalip.adoc
new file mode 100644
index 000000000000..49ced4802e71
--- /dev/null
+++ b/modules/configuration-externalip.adoc
@@ -0,0 +1,58 @@
+// Module included in the following assemblies:
+//
+// * networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="configuration-externalip_{context}"]
+= Configuration for ExternalIP
+
+Use of an external IP address in {product-title} is governed by the following parameters in the `Network.config.openshift.io` custom resource (CR) that is named `cluster`:
+
+* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This configuration requires less steps than manually assigning ExternalIPs to services, which requires managing the port space of a limited number of shared IP addresses. If you enable automatic assignment, a `Service` object with `spec.type=LoadBalancer` is allocated an external IP address.
+
+* `spec.externalIP.policy` defines the permissible IP address blocks when manually specifying an IP address. {product-title} does not apply policy rules to IP address blocks that you defined in the `spec.externalIP.autoAssignCIDRs` parameter.
+
+If routed correctly, external traffic from the configured external IP address block can reach service endpoints through any TCP or UDP port that the service exposes.
+
+[IMPORTANT]
+====
+As a cluster administrator, you must configure routing to externalIPs. You must also ensure that the IP address block you assign terminates at one or more nodes in your cluster. For more information, see link:https://kubernetes.io/docs/concepts/services-networking/service/#external-ips[Kubernetes External IPs].
+====
+
+{product-title} supports both the automatic and manual assignment of IP addresses, where each address is guaranteed to be assigned to a maximum of one service. This configuration ensures that each service can expose its chosen ports regardless of the ports exposed by other services.
+
+[NOTE]
+====
+To use IP address blocks defined by `autoAssignCIDRs` in {product-title}, you must configure the necessary IP address assignment and routing for your host network.
+====
+
+The following YAML describes a service with an external IP address configured:
+
+.Example `Service` object with `spec.externalIPs[]` set
+[source,yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  name: http-service
+spec:
+  clusterIP: 172.30.163.110
+  externalIPs:
+  - 192.168.132.253
+  externalTrafficPolicy: Cluster
+  ports:
+  - name: highport
+    nodePort: 31903
+    port: 30102
+    protocol: TCP
+    targetPort: 30102
+  selector:
+    app: web
+  sessionAffinity: None
+  type: LoadBalancer
+status:
+  loadBalancer:
+    ingress:
+    - ip: 192.168.132.253
+# ...
+----
diff --git a/modules/configuring-kernal-page-size.adoc b/modules/configuring-kernal-page-size.adoc
new file mode 100644
index 000000000000..19ad20a939d9
--- /dev/null
+++ b/modules/configuring-kernal-page-size.adoc
@@ -0,0 +1,79 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cnf-page-size-optimization_{context}"]
+= Configuring kernel page sizes
+
+Use the `kernelPageSize` specification in a performance profile to configure the kernel page size on a specific node. Specify larger kernel page sizes for memory-intensive, high-performance workloads. 
+
+[NOTE]
+====
+For nodes with an x86_64 or AMD64 architecture, you can only specify `4k` for the `kernelPageSize` specification. 
+For nodes with an AArch64 architecture, you can specify `4k` or `64k` for the `kernelPageSize` specification. You must disable the realtime kernel before you can use the `64k` option. 
+The default value is `4k`.
+====
+
+.Prerequisites
+
+* Access to the cluster as a user with the `cluster-admin` role.
+
+* Install the {oc-first}.
+
+.Procedure
+
+. Create a performance profile to target nodes where you want to configure the kernel page size by creating a YAML file that defines the `PerformanceProfile` resource:
++
+.Example `pp-kernel-pages.yaml` file
+[source,yaml]
+----
+apiVersion: performance.openshift.io/v1
+kind: PerformanceProfile
+metadata:
+    name: example-performance-profile
+#...
+spec:
+    kernelPageSize: "64k" <1>
+    realTimeKernel:
+        enabled: false <2>
+    nodeSelector:
+        node-role.kubernetes.io/worker: "" <3>
+----
+<1> This example specifies a kernel page size of `64k`. You can only specify `64k` for nodes with an AArch64 architecture. The default value is `4k`.
+<2> You must disable the realtime kernel to use the `64k` kernel page size option.
+<3> This example targets nodes with the `worker` role.
+
+. Apply the performance profile to the cluster:
++
+[source,bash]
+----
+$ oc create -f pp-kernel-pages.yaml
+----
++
+.Example output
+----
+performanceprofile.performance.openshift.io/example-performance-profile created
+----
+
+.Verification
+
+. Start a debug session on the node where you applied the performance profile by running the following command:
++
+[source,bash]
+----
+$ oc debug node/<node_name> <1>
+----
+<1> Replace `<node_name>` with the name of the node with the performance profile applied.
+
+. Verify that the kernel page size is set to the value you specified in the performance profile by running the following command:
++
+[source,bash]
+----
+$ getconf PAGESIZE
+----
++
+.Example output
+----
+65536
+----
diff --git a/modules/configuring-node-pools-for-hcp.adoc b/modules/configuring-node-pools-for-hcp.adoc
index 42c3c1cdc35c..bd97c1a3b082 100644
--- a/modules/configuring-node-pools-for-hcp.adoc
+++ b/modules/configuring-node-pools-for-hcp.adoc
@@ -21,7 +21,7 @@ On {hcp}, you can configure node pools by creating a `MachineConfig` object insi
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <configmap-name>
+  name: <configmap_name>
   namespace: clusters
 data:
   config: |
@@ -30,7 +30,7 @@ data:
     metadata:
       labels:
         machineconfiguration.openshift.io/role: worker
-      name: <machineconfig-name>
+      name: <machineconfig_name>
     spec:
       config:
         ignition:
@@ -64,9 +64,10 @@ metadata:
 # ...
 spec:
   config:
-  - name: ${configmap-name}
+  - name: <configmap_name> <1>
 # ...
 ----
+<1> Replace `<configmap_name>` with the name of your config map.
 
 //.Verification
 
diff --git a/modules/configuring-pods-static-ip.adoc b/modules/configuring-pods-static-ip.adoc
index 902ee5deda82..1f6408ca6710 100644
--- a/modules/configuring-pods-static-ip.adoc
+++ b/modules/configuring-pods-static-ip.adoc
@@ -10,7 +10,7 @@ The following example provisions a pod with a static IP address.
 
 [NOTE]
 ====
-* You can only specify the IP address for a pod's secondary network attachment for layer 2 attachments.
+* You can specify the IP address for the secondary network attachment of a pod only when the additional network attachment, a namespaced-scoped object, uses a layer 2 or localnet topology.
 * Specifying a static IP address for the pod is only possible when the attachment configuration does not feature subnets.
 ====
 
diff --git a/modules/configuring-vsphere-regions-zones.adoc b/modules/configuring-vsphere-regions-zones.adoc
index 67c383f54a7c..3a07866e7980 100644
--- a/modules/configuring-vsphere-regions-zones.adoc
+++ b/modules/configuring-vsphere-regions-zones.adoc
@@ -67,11 +67,11 @@ $ govc tags.create -c <zone_tag_category> <zone_tag>
 $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
 ----
 
-. Attach the zone tags to each vCenter data center object by entering the following command:
+. Attach the zone tags to each vCenter cluster object by entering the following command:
 +
 [source,terminal]
 ----
-$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
+$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/<cluster1>
 ----
 
 . Change to the directory that contains the installation program and initialize the cluster deployment according to your chosen installation requirements.
diff --git a/modules/containers-signature-verify-unsigned.adoc b/modules/containers-signature-verify-unsigned.adoc
index 45745d7a0d38..2743fd9b76dd 100644
--- a/modules/containers-signature-verify-unsigned.adoc
+++ b/modules/containers-signature-verify-unsigned.adoc
@@ -12,7 +12,7 @@ For example, the image references lacking a verifiable signature are contained i
 .Example release info output
 [source,terminal]
 ----
-$ oc adm release info  quay.io/openshift-release-dev/ ocp-release@sha256:2309578b68c5666dad62aed696f1f9d778ae1a089ee461060ba7b9514b7ca417 -o pullspec <1>
+$ oc adm release info quay.io/openshift-release-dev/ocp-release@sha256:2309578b68c5666dad62aed696f1f9d778ae1a089ee461060ba7b9514b7ca417 -o pullspec <1>
 quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9aafb914d5d7d0dec4edd800d02f811d7383a7d49e500af548eab5d00c1bffdb <2>
 ----
 
@@ -23,4 +23,4 @@ quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9aafb914d5d7d0dec4edd800d0
 == Automated verification during updates
 Verification of signatures is automatic. The OpenShift Cluster Version Operator (CVO) verifies signatures on the release images during an {product-title} update. This is an internal process. An {product-title} installation or update fails if the automated verification fails.
 
-Verification of signatures can also be done manually using the `skopeo` command-line utility.
\ No newline at end of file
+Verification of signatures can also be done manually using the `skopeo` command-line utility.
diff --git a/modules/coo-advantages.adoc b/modules/coo-advantages.adoc
new file mode 100644
index 000000000000..603694e2eef5
--- /dev/null
+++ b/modules/coo-advantages.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-advantages_{context}"]
+= Key advantages of using {coo-short}
+
+Deploying {coo-short} helps you address monitoring requirements that are hard to achieve using the default monitoring stack. 
+
+[id="coo-advantages-extensibility_{context}"]
+== Extensibility
+
+- You can add more metrics to a {coo-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
+- You can receive cluster-specific metrics from core platform monitoring through federation.
+- {coo-short} supports advanced monitoring scenarios like trend forecasting and anomaly detection.
+
+[id="coo-advantages-multi-tenancy_{context}"]
+== Multi-tenancy support
+
+- You can create monitoring stacks per user namespace.
+- You can deploy multiple stacks per namespace or a single stack for multiple namespaces.
+- {coo-short} enables independent configuration of alerts and receivers for different teams.
+
+[id="coo-advantages-scalability_{context}"]
+== Scalability
+
+- Supports multiple monitoring stacks on a single cluster.
+- Enables monitoring of large clusters through manual sharding.
+- Addresses cases where metrics exceed the capabilities of a single Prometheus instance.
+
+[id="coo-advantages-scalabilityflexibility_{context}"]
+== Flexibility
+
+- Decoupled from {product-title} release cycles.
+- Faster release iterations and rapid response to changing requirements.
+- Independent management of alerting rules.
\ No newline at end of file
diff --git a/modules/coo-distributed-tracing-ui-plugin-install.adoc b/modules/coo-distributed-tracing-ui-plugin-install.adoc
index 1009d113ed46..1a7cfb613785 100644
--- a/modules/coo-distributed-tracing-ui-plugin-install.adoc
+++ b/modules/coo-distributed-tracing-ui-plugin-install.adoc
@@ -3,7 +3,7 @@
 // * observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="coo-distributed-tracing-ui-plugin-install-_{context}"]
+[id="coo-distributed-tracing-ui-plugin-install_{context}"]
 = Installing the {coo-full} distributed tracing UI plugin
 
 
diff --git a/modules/coo-incident-detection-overview.adoc b/modules/coo-incident-detection-overview.adoc
new file mode 100644
index 000000000000..17a65d240a13
--- /dev/null
+++ b/modules/coo-incident-detection-overview.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+
+// * observability/cluster_observability_operator/ui_plugins/incident-detection-ui-plugin.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-incident-detection-overview_{context}"]
+= {coo-full} incident detection overview
+
+Clusters can generate significant volumes of monitoring data, making it hard for you to distinguish critical signals from noise.
+Single incidents can trigger a cascade of alerts, and this results in extended time to detect and resolve issues.
+
+The {coo-full} incident detection feature groups related alerts into *incidents*. These incidents are then visualized as timelines that are color-coded by severity.
+Alerts are mapped to specific components, grouped by severity, helping you to identify root causes by focusing on high impact components first.
+You can then drill down from the incident timelines to individual alerts to determine how to fix the underlying issue.
+
+{coo-full} incident detection transforms the alert storm into clear steps for faster understanding and resolution of the incidents that occur on your clusters.
diff --git a/modules/coo-incident-detection-using.adoc b/modules/coo-incident-detection-using.adoc
new file mode 100644
index 000000000000..eaa66fe91944
--- /dev/null
+++ b/modules/coo-incident-detection-using.adoc
@@ -0,0 +1,59 @@
+// Module included in the following assemblies:
+
+// * observability/cluster_observability_operator/ui_plugins/incident-detection-ui-plugin.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="coo-incident-detection-using_{context}"]
+= Using {coo-full} incident detection
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have logged in to the {product-title} web console.
+* You have installed the {coo-full}.
+* You have installed the {coo-full} monitoring UI plugin with incident detection enabled.
+
+
+.Procedure
+
+. In the Administrator perspective of the web console, click on *Observe* -> *Incidents*.
+
+. The Incidents Timeline UI shows the grouping of alerts into *incidents*. The color coding of the lines in the graph corresponds to the severity of the incident. By default, a seven day timeline is presented.
++
+image::coo-incidents-timeline-weekly.png[Weekly incidents timeline]
++
+[NOTE]
+====
+It will take at least 10 minutes to process the correlations and to see the timeline, after you enable incident detection.
+
+The analysis and grouping into incidents is performed only for alerts that are firing after you have enabled this feature. Alerts that have been resolved before feature enablement are not included.
+====
+
+. Zoom in to a 1-day view by clicking on the drop-down to specify the duration.
++
+image::coo-incidents-timeline-daily.png[Daily incidents timeline]
+
+. By clicking on an incident, you can see the timeline of alerts that are part of that incident, in the Alerts Timeline UI.
++
+image::coo-incident-alerts-timeline.png[Incidents alerts timeline]
+
+. In the list of alerts that follows, alerts are mapped to specific components, which are grouped by severity.
++
+image::coo-incident-alerts-components.png[Incidents alerts components]
+
+. Click to expand a compute component in the list. The underlying alerts related to that component are displayed.
++
+image::coo-incident-alerts-components-expanded.png[Incidents expanded components]
+
+. Click the link for a firing alert, to see detailed information about that alert.
+
+
+
+[NOTE]
+====
+**Known issues**
+
+* Depending on the order of the timeline bars, the tooltip might overlap and hide the underlying bar. You can still click the bar and select the incident or alert.
+
+* The Silence Alert button in the **Incidents** -> **Component** section does not pre-populate the fields and is not usable. As a workaround, you can use the same menu and the Silence Alert button in the **Alerting** section instead.
+====
\ No newline at end of file
diff --git a/modules/coo-monitoring-ui-plugin-install.adoc b/modules/coo-monitoring-ui-plugin-install.adoc
new file mode 100644
index 000000000000..8ab8cd1d71bc
--- /dev/null
+++ b/modules/coo-monitoring-ui-plugin-install.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+
+// * observability/cluster_observability_operator/ui_plugins/monitoring-ui-plugin.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="coo-monitoring-ui-plugin-install_{context}"]
+= Installing the {coo-full} monitoring UI plugin
+
+The monitoring UI plugin adds monitoring related UI features to the OpenShift web console, for the Advance Cluster Management (ACM) perspective and for incident detection.
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have logged in to the {product-title} web console.
+* You have installed the {coo-full}
+
+.Procedure
+
+. In the {product-title} web console, click *Operators* -> *Installed Operators* and select {coo-full}
+. Choose the *UI Plugin* tab (at the far right of the tab list) and press *Create UIPlugin*
+. Select *YAML view*, enter the following content, and then press *Create*:
++
+[source,yaml]
+----
+apiVersion: observability.openshift.io/v1alpha1
+kind: UIPlugin
+metadata:
+  name: monitoring
+spec:
+  type: Monitoring
+  monitoring:
+    acm: # <1>
+      enabled: true
+      alertmanager:
+        url: 'https://alertmanager.open-cluster-management-observability.svc:9095'
+      thanosQuerier:
+        url: 'https://rbac-query-proxy.open-cluster-management-observability.svc:8443'  
+    incidents: # <2>
+      enabled: true  
+----
+<1> Enable {rh-rhacm} features. You must configure the Alertmanager and ThanosQuerier Service endpoints.
+<2> Enable incident detection features. 
\ No newline at end of file
diff --git a/modules/coo-server-side-apply.adoc b/modules/coo-server-side-apply.adoc
new file mode 100644
index 000000000000..41ab94721d35
--- /dev/null
+++ b/modules/coo-server-side-apply.adoc
@@ -0,0 +1,302 @@
+//Module included in the following assemblies:
+//
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="server-side-apply_{context}"]
+= Using Server-Side Apply to customize Prometheus resources
+
+Server-Side Apply is a feature that enables collaborative management of Kubernetes resources. The control plane tracks how different users and controllers manage fields within a Kubernetes object. It introduces the concept of field managers and tracks ownership of fields. This centralized control provides conflict detection and resolution, and reduces the risk of unintended overwrites.
+
+Compared to Client-Side Apply, it is more declarative, and tracks field management instead of last applied state.
+
+Server-Side Apply:: Declarative configuration management by updating a resource's state without needing to delete and recreate it.
+
+Field management:: Users can specify which fields of a resource they want to update, without affecting the other fields. 
+
+Managed fields:: Kubernetes stores metadata about who manages each field of an object in the `managedFields` field within metadata.
+
+Conflicts:: If multiple managers try to modify the same field, a conflict occurs. The applier can choose to overwrite, relinquish control, or share management.
+
+Merge strategy:: Server-Side Apply merges fields based on the actor who manages them. 
+
+.Procedure
+
+. Add a `MonitoringStack` resource using the following configuration:
++
+.Example `MonitoringStack` object
++
+[source,yaml]
+----
+apiVersion: monitoring.rhobs/v1alpha1
+kind: MonitoringStack
+metadata:
+  labels:
+    coo: example
+  name: sample-monitoring-stack
+  namespace: coo-demo
+spec:
+  logLevel: debug
+  retention: 1d
+  resourceSelector:
+    matchLabels:
+      app: demo
+----
+
+. A Prometheus resource named `sample-monitoring-stack` is generated in the `coo-demo` namespace. Retrieve the managed fields of the generated Prometheus resource by running the following command:
++
+[source,terminal]
+----
+$ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
+----
++
+.Example output
+[source,yaml]
+----
+managedFields:
+- apiVersion: monitoring.rhobs/v1
+  fieldsType: FieldsV1
+  fieldsV1:
+    f:metadata:
+      f:labels:
+        f:app.kubernetes.io/managed-by: {}
+        f:app.kubernetes.io/name: {}
+        f:app.kubernetes.io/part-of: {}
+      f:ownerReferences:
+        k:{"uid":"81da0d9a-61aa-4df3-affc-71015bcbde5a"}: {}
+    f:spec:
+      f:additionalScrapeConfigs: {}
+      f:affinity:
+        f:podAntiAffinity:
+          f:requiredDuringSchedulingIgnoredDuringExecution: {}
+      f:alerting:
+        f:alertmanagers: {}
+      f:arbitraryFSAccessThroughSMs: {}
+      f:logLevel: {}
+      f:podMetadata:
+        f:labels:
+          f:app.kubernetes.io/component: {}
+          f:app.kubernetes.io/part-of: {}
+      f:podMonitorSelector: {}
+      f:replicas: {}
+      f:resources:
+        f:limits:
+          f:cpu: {}
+          f:memory: {}
+        f:requests:
+          f:cpu: {}
+          f:memory: {}
+      f:retention: {}
+      f:ruleSelector: {}
+      f:rules:
+        f:alert: {}
+      f:securityContext:
+        f:fsGroup: {}
+        f:runAsNonRoot: {}
+        f:runAsUser: {}
+      f:serviceAccountName: {}
+      f:serviceMonitorSelector: {}
+      f:thanos:
+        f:baseImage: {}
+        f:resources: {}
+        f:version: {}
+      f:tsdb: {}
+  manager: observability-operator
+  operation: Apply
+- apiVersion: monitoring.rhobs/v1
+  fieldsType: FieldsV1
+  fieldsV1:
+    f:status:
+      .: {}
+      f:availableReplicas: {}
+      f:conditions:
+        .: {}
+        k:{"type":"Available"}:
+          .: {}
+          f:lastTransitionTime: {}
+          f:observedGeneration: {}
+          f:status: {}
+          f:type: {}
+        k:{"type":"Reconciled"}:
+          .: {}
+          f:lastTransitionTime: {}
+          f:observedGeneration: {}
+          f:status: {}
+          f:type: {}
+      f:paused: {}
+      f:replicas: {}
+      f:shardStatuses:
+        .: {}
+        k:{"shardID":"0"}:
+          .: {}
+          f:availableReplicas: {}
+          f:replicas: {}
+          f:shardID: {}
+          f:unavailableReplicas: {}
+          f:updatedReplicas: {}
+      f:unavailableReplicas: {}
+      f:updatedReplicas: {}
+  manager: PrometheusOperator
+  operation: Update
+  subresource: status
+----
+
+. Check the `metadata.managedFields` values, and observe that some fields in `metadata` and `spec` are managed by the `MonitoringStack` resource.
+
+. Modify a field that is not controlled by the `MonitoringStack` resource:
+
+.. Change `spec.enforcedSampleLimit`, which is a field not set by the `MonitoringStack` resource. Create the file `prom-spec-edited.yaml`:
++
+.`prom-spec-edited.yaml`
++
+[source,yaml]
+----
+apiVersion: monitoring.rhobs/v1
+kind: Prometheus
+metadata:
+  name: sample-monitoring-stack
+  namespace: coo-demo
+spec:
+  enforcedSampleLimit: 1000
+----
+
+.. Apply the YAML by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f ./prom-spec-edited.yaml --server-side 
+----
++
+[NOTE]
+====
+You must use the `--server-side` flag.
+====
+
+.. Get the changed Prometheus object and note that there is one more section in `managedFields` which has `spec.enforcedSampleLimit`:
++
+[source,terminal]
+----
+$ oc get prometheus -n coo-demo 
+----
++
+.Example output
+[source,yaml]
+----
+managedFields: <1>
+- apiVersion: monitoring.rhobs/v1
+  fieldsType: FieldsV1
+  fieldsV1:
+    f:metadata:
+      f:labels:
+        f:app.kubernetes.io/managed-by: {}
+        f:app.kubernetes.io/name: {}
+        f:app.kubernetes.io/part-of: {}
+    f:spec:
+      f:enforcedSampleLimit: {} <2>
+  manager: kubectl
+  operation: Apply
+----
+<1> `managedFields`
+<2> `spec.enforcedSampleLimit`
+
+. Modify a field that is managed by the `MonitoringStack` resource:
+.. Change `spec.LogLevel`, which is a field managed by the `MonitoringStack` resource, using the following YAML configuration:
++
+[source,yaml]
+----
+# changing the logLevel from debug to info
+apiVersion: monitoring.rhobs/v1
+kind: Prometheus
+metadata:
+  name: sample-monitoring-stack
+  namespace: coo-demo
+spec:
+  logLevel: info <1>
+----
+<1> `spec.logLevel` has been added
+
+.. Apply the YAML by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f ./prom-spec-edited.yaml --server-side 
+----
++
+.Example output
++
+[source,terminal]
+----
+error: Apply failed with 1 conflict: conflict with "observability-operator": .spec.logLevel
+Please review the fields above--they currently have other managers. Here
+are the ways you can resolve this warning:
+* If you intend to manage all of these fields, please re-run the apply
+  command with the `--force-conflicts` flag.
+* If you do not intend to manage all of the fields, please edit your
+  manifest to remove references to the fields that should keep their
+  current managers.
+* You may co-own fields by updating your manifest to match the existing
+  value; in this case, you'll become the manager if the other manager(s)
+  stop managing the field (remove it from their configuration).
+See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts
+----
+
+.. Notice that the field `spec.logLevel` cannot be changed using Server-Side Apply, because it is already managed by `observability-operator`.
+
+.. Use the `--force-conflicts` flag to force the change.
++
+[source,terminal]
+----
+$ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts 
+----
++
+.Example output
++
+[source,terminal]
+----
+prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
+----
++
+With `--force-conflicts` flag, the field can be forced to change, but since the same field is also managed by the `MonitoringStack` resource, the Observability Operator detects the change, and reverts it back to the value set by the `MonitoringStack` resource.
++
+[NOTE]
+====
+Some Prometheus fields generated by the `MonitoringStack` resource are influenced by the fields in the `MonitoringStack` `spec` stanza, for example, `logLevel`. These can be changed by changing the `MonitoringStack` `spec`.
+====
+
+.. To change the `logLevel` in the Prometheus object, apply the following YAML to change the `MonitoringStack` resource:
++
+[source,yaml]
+----
+apiVersion: monitoring.rhobs/v1alpha1
+kind: MonitoringStack
+metadata:
+  name: sample-monitoring-stack
+  labels:
+    coo: example
+spec:
+  logLevel: info
+----
+
+.. To confirm that the change has taken place, query for the log level by running the following command:
++
+[source,terminal]
+----
+$ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
+----
++
+.Example output
++
+[source,terminal]
+----
+info
+----
+
+
+[NOTE]
+====
+. If a new version of an Operator generates a field that was previously generated and controlled by an actor, the value set by the actor will be overridden.
++
+For example, you are managing a field `enforcedSampleLimit` which is not generated by the `MonitoringStack` resource. If the Observability Operator is upgraded, and the new version of the Operator generates a value for `enforcedSampleLimit`, this will overide the value you have previously set.
+
+. The `Prometheus` object generated by the `MonitoringStack` resource may contain some fields which are not explicitly set by the monitoring stack. These fields appear because they have default values.
+====
diff --git a/modules/coo-target-users.adoc b/modules/coo-target-users.adoc
new file mode 100644
index 000000000000..dbd27e5fdc94
--- /dev/null
+++ b/modules/coo-target-users.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-target-users_{context}"]
+= Target users for {coo-short}
+
+{coo-short} is ideal for users who need high customizability, scalability, and long-term data retention, especially in complex, multi-tenant enterprise environments.
+
+[id="coo-target-users-enterprise_{context}"]
+== Enterprise-level users and administrators
+
+Enterprise users require in-depth monitoring capabilities for {product-title} clusters, including advanced performance analysis, long-term data retention, trend forecasting, and historical analysis. These features help enterprises better understand resource usage, prevent performance issues, and optimize resource allocation.
+
+[id="coo-target-users-multi-tenant_{context}"]
+== Operations teams in multi-tenant environments
+
+With multi-tenancy support, {coo-short} allows different teams to configure monitoring views for their projects and applications, making it suitable for teams with flexible monitoring needs.
+
+[id="coo-target-users-devops_{context}"]
+== Development and operations teams
+
+{coo-short} provides fine-grained monitoring and customizable observability views for in-depth troubleshooting, anomaly detection, and performance tuning during development and operations.
\ No newline at end of file
diff --git a/modules/coo-versus-default-ocp-monitoring.adoc b/modules/coo-versus-default-ocp-monitoring.adoc
new file mode 100644
index 000000000000..618ff8413c19
--- /dev/null
+++ b/modules/coo-versus-default-ocp-monitoring.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-versus-default-ocp-monitoring_{context}"]
+= {coo-short} compared to default monitoring stack
+
+The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the {cmo-first}.
+Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the {cmo-short}.
+
+The key differences between {coo-short} and the default in-cluster monitoring stack are shown in the following table:
+
+[cols="1,3,3", options="header"]
+|===
+| Feature      | {coo-short}      | Default monitoring stack
+
+| **Scope and integration**
+| Offers comprehensive monitoring and analytics for enterprise-level needs, covering cluster and workload performance. 
+
+However, it lacks direct integration with {product-title} and typically requires an external Grafana instance for dashboards.
+| Limited to core components within the cluster, for example, API server and etcd, and to OpenShift-specific namespaces. 
+
+There is deep integration into {product-title} including console dashboards and alert management in the console.
+
+| **Configuration and customization**
+| Broader configuration options including data retention periods, storage methods, and collected data types. 
+
+The {coo-short} can delegate ownership of single configurable fields in custom resources to users by using Server-Side Apply (SSA), which enhances customization.
+| Built-in configurations with limited customization options. 
+
+| **Data retention and storage**
+| Long-term data retention, supporting historical analysis and capacity planning
+| Shorter data retention times, focusing on short-term monitoring and real-time detection.
+
+|===
diff --git a/modules/copying-files-pods-and-containers.adoc b/modules/copying-files-pods-and-containers.adoc
index d6f16c2c77c0..025e8994aad5 100644
--- a/modules/copying-files-pods-and-containers.adoc
+++ b/modules/copying-files-pods-and-containers.adoc
@@ -10,12 +10,12 @@ You can copy files to and from a pod to test configuration changes or gather dia
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 
diff --git a/modules/core-user-password.adoc b/modules/core-user-password.adoc
index 34346d250ad6..aa8e498c4409 100644
--- a/modules/core-user-password.adoc
+++ b/modules/core-user-password.adoc
@@ -45,7 +45,7 @@ metadata:
 spec:
   config:
     ignition:
-      version: 3.2.0
+      version: 3.4.0
     passwd:
       users:
       - name: core <1>
diff --git a/modules/coreos-layering-configuring-on-extensions.adoc b/modules/coreos-layering-configuring-on-extensions.adoc
new file mode 100644
index 000000000000..41fab05636e7
--- /dev/null
+++ b/modules/coreos-layering-configuring-on-extensions.adoc
@@ -0,0 +1,116 @@
+// Module included in the following assemblies:
+//
+// * machine_configuration/coreos-layering.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="coreos-layering-configuring-on-extensions_{context}"]
+= Installing extensions into an on-cluster custom layered image
+
+You can install {op-system-first} extensions into your on-cluster custom layered image by creating a machine config that lists the extensions that you want to install. The Machine Config Operator (MCO) installs the extensions onto the nodes associated with a specific machine config pool (MCP).
+
+For a list of the currently supported extensions, see "Adding extensions to RHCOS."
+
+After you make the change, the MCO reboots the nodes associated with the specified machine config pool.
+
+[NOTE]
+====
+include::snippets/coreos-layering-configuring-on-pause.adoc[]
+====
+
+.Prerequisites
+
+* You have opted in to on-cluster layering by creating a `MachineOSConfig` object.
+
+.Procedure
+
+. Create a YAML file for the machine config similar to the following example: 
++
+[source,yaml]
+----
+apiVersion: machineconfiguration.openshift.io/v1 <1>
+kind: MachineConfig
+metadata:
+  labels:
+    machineconfiguration.openshift.io/role: worker <2>
+  name: 80-worker-extensions
+spec:
+  config:
+    ignition:
+      version: 3.2.0
+  extensions: <3>
+    - usbguard
+    - kerberos
+----
+<1> Specifies the `machineconfiguration.openshift.io/v1` API that is required for `MachineConfig` CRs.
+<2> Specifies the machine config pool to apply the `MachineConfig` object to.
+<3> Lists the {op-system-first} extensions that you want to install.
+
+. Create the MCP object:
++
+[source,terminal]
+----
+$ oc create -f <file_name>.yaml
+----
+
+.Verification
+
+. You can watch the build progress by using the following command:
++
+[source,terminal]
+----
+$ oc get machineosbuilds
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                       PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-f8ab2d03a2f87a2acd449177ceda805d   False      True       False       False         False <1>
+----
+<1> The value `True` in the `BUILDING` column indicates that the `MachineOSBuild` object is building. When the `SUCCEEDED` column reports `TRUE`, the build is complete. 
+
+. You can watch as the new machine config is rolled out to the nodes by using the following command:
++
+[source,terminal]
+----
+$ oc get machineconfigpools
+----
++
+.Example output
+[source,terminal]
+----
+NAME      CONFIG                                              UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
+master    rendered-master-a0b404d061a6183cc36d302363422aba    True      False      False      3              3                   3                     0                      3h38m
+worker    rendered-worker-221507009cbcdec0eec8ab3ccd789d18    False     True       False      2              2                   2                     0                      3h38m <1>
+----
+<1> The value `FALSE` in the `UPDATED` column indicates that the `MachineOSBuild` object is building. When the `UPDATED` column reports `FALSE`, the new custom layered image has rolled out to the nodes.
+
+. When the associated machine config pool is updated, check that the extensions were installed:
+
+.. Open an `oc debug` session to the node by running the following command:
++
+[source,terminal]
+----
+$ oc debug node/<node_name>
+----
+
+.. Set `/host` as the root directory within the debug shell by running the following command:
++
+[source,terminal]
+----
+sh-5.1# chroot /host
+----
+
+.. Use an appropriate command to verify that the extensions were installed. The following example shows that the usbguard extension was installed:
++
+[source,terminal]
+----
+sh-5.1# rpm -qa |grep usbguard
+----
++
+.Example output
+[source,terminal]
+----
+usbguard-selinux-1.0.0-15.el9.noarch
+usbguard-1.0.0-15.el9.x86_64
+----
diff --git a/modules/coreos-layering-configuring-on-modifying.adoc b/modules/coreos-layering-configuring-on-modifying.adoc
new file mode 100644
index 000000000000..ea83275db317
--- /dev/null
+++ b/modules/coreos-layering-configuring-on-modifying.adoc
@@ -0,0 +1,138 @@
+// Module included in the following assemblies:
+//
+// * machine_configuration/coreos-layering.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="coreos-layering-configuring-on-modifying_{context}"]
+= Modifying a custom layered image
+
+You can modify an on-cluster custom layered image, as needed. This allows you to install additional packages, remove existing packages, change the pull or push repositories, update secrets, or other similar changes. You can edit the `MachineOSConfig` object, apply changes to the YAML file that created the `MachineOSConfig` object, or create a new YAML file for that purpose.
+
+If you modify and apply the `MachineOSConfig` object YAML or create a new YAML file, the YAML overwrites any changes you made directly to the `MachineOSConfig` object itself.
+
+include::snippets//coreos-layering-configuring-on-pause.adoc[]
+
+.Prerequisites
+
+* You have opted in to on-cluster layering by creating a `MachineOSConfig` object.
+
+.Procedure
+
+* Modify an object to update the associated custom layered image:
+
+.. Edit the `MachineOSConfig` object to modify the custom layered image. The following example adds the `rngd` daemon to nodes that already have the tree package that was installed using a custom layered image.
++
+[source,yaml]
+----
+apiVersion: machineconfiguration.openshift.io/v1alpha1
+kind: MachineOSConfig
+metadata:
+  name: layered
+spec:
+  machineConfigPool:
+    name: worker
+  buildInputs:
+    containerFile:
+    - containerfileArch: noarch
+      content: |- <1>
+        FROM configs AS final
+
+        RUN rpm-ostree install rng-tools && \
+            systemctl enable rngd && \
+            rpm-ostree cleanup -m && \
+            ostree container commit
+
+        RUN rpm-ostree install tree && \
+            ostree container commit
+    imageBuilder:
+      imageBuilderType: PodImageBuilder
+    baseImagePullSecret:
+      name: global-pull-secret-copy <2>
+    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-images:latest <3>
+    renderedImagePushSecret:  <4>
+      name: new-secret-name
+  buildOutputs:
+    currentImagePullSecret:
+      name: new-secret-name <5>
+----
+<1> Optional: Modify the Containerfile, for example to add or remove packages.
+<2> Optional: Update the secret needed to pull the base operating system image from the registry.
+<3> Optional: Modify the image registry to push the newly built custom layered image to.
+<4> Optional: Update the secret needed to push the newly built custom layered image to the registry.
+<5> Optional: Update the secret needed to pull the newly built custom layered image from the registry.
++
+When you save the changes, the MCO drains, cordons, and reboots the nodes. After the reboot, the node uses the cluster base {op-system-first} image. If your changes modify a secret only, no new build is triggered and no reboot is performed.
+
+.Verification
+
+. Verify that the new `MachineOSBuild` object was created by using the following command:
++
+[source,terminal]
+----
+$ oc get machineosbuild
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                       PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-a5457b883f5239cdcb71b57e1a30b6ef   False      False      True        False         False
+layered-f91f0f5593dd337d89bf4d38c877590b   False      True       False       False         False <1>
+----
+<1> The value `True` in the `BUILDING` column indicates that the `MachineOSBuild` object is building. When the `SUCCEEDED` column reports `True`, the build is complete.
+
+. You can watch as the new machine config is rolled out to the nodes by using the following command:
++
+[source,terminal]
+----
+$ oc get machineconfigpools
+----
++
+.Example output
+[source,terminal]
+----
+NAME      CONFIG                                              UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
+master    rendered-master-a0b404d061a6183cc36d302363422aba    True      False      False      3              3                   3                     0                      3h38m
+worker    rendered-worker-221507009cbcdec0eec8ab3ccd789d18    False     True       False      2              2                   2                     0                      3h38m <1>
+----
+<1> The value `FALSE` in the `UPDATED` column indicates that the `MachineOSBuild` object is building. When the `UPDATED` column reports `FALSE`, the new custom layered image has rolled out to the nodes.
+
+. When the node is back in the `Ready` state, check that the changes were applied:
+
+.. Open an `oc debug` session to the node by running the following command:
++
+[source,terminal]
+----
+$ oc debug node/<node_name>
+----
+
+.. Set `/host` as the root directory within the debug shell by running the following command:
++
+[source,terminal]
+----
+sh-5.1# chroot /host
+----
+
+.. Use an appropriate command to verify that change was applied. The following examples shows that the `rngd` daemon was installed:
++
+[source,terminal]
+----
+sh-5.1# rpm -qa |grep rng-tools
+----
++
+.Example output
+[source,terminal]
+----
+rng-tools-6.17-3.fc41.x86_64
+----
++
+[source,terminal]
+----
+sh-5.1# rngd -v
+----
++
+.Example output
+[source,terminal]
+----
+rngd 6.16
+----
diff --git a/modules/coreos-layering-configuring-on-revert.adoc b/modules/coreos-layering-configuring-on-revert.adoc
new file mode 100644
index 000000000000..29b0470b42ab
--- /dev/null
+++ b/modules/coreos-layering-configuring-on-revert.adoc
@@ -0,0 +1,104 @@
+// Module included in the following assemblies:
+//
+// * machine_configuration/coreos-layering.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="coreos-layering-configuring-on-revert_{context}"]
+= Reverting an on-cluster custom layered image
+
+You can revert an on-cluster custom layered image from nodes by removing the label for the machine config pool (MCP) that you specified in the `MachineOSConfig` object. After you remove the label, the Machine Config Operator (MCO) reboots the nodes in that MCP with the cluster base {op-system-first} image, along with any previously-made machine config changes, overriding the custom layered image. 
+
+[IMPORTANT]
+====
+If the node where the custom layered image is deployed uses a custom machine config pool, before you remove the label, make sure the node is associated with a second MCP.
+====
+
+You can reapply the custom layered image to the node by using the `oc label node/<node_name> 'node-role.kubernetes.io/<mcp_name>='` label.
+
+.Prerequisites
+
+* You have opted in to on-cluster layering by creating a `MachineOSConfig` object.
+
+.Procedure
+
+* Remove the label from the node by using the following command:
++
+[source,terminal]
+----
+$ oc label node/<node_name> node-role.kubernetes.io/<mcp_name>-
+----
++
+When you save the changes, the MCO drains, cordons, and reboots the nodes. After the reboot, the node uses the cluster base {op-system-first} image.
+
+.Verification
+
+You can verify that the custom layered image is removed by performing the following checks:
+
+. Check that the worker machine config pool is updating with the previous machine config:
++
+[source,terminal]
+----
+$ oc get mcp
+----
++
+.Sample output
+[source,terminal]
+----
+NAME      CONFIG                                              UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
+master    rendered-master-8332482204e0b76002f15ecad15b6c2d    True      False      False      3              3                   3                     0                      5h26m
+worker    rendered-worker-bde4e4206442c0a48b1a1fb35ba56e85    False     True       False      3              2                   2                     0                      5h26m <1>
+----
+<1> The value `FALSE` in the `UPDATED` column indicates that the `MachineOSBuild` object is building. When the `UPDATED` column reports `FALSE`, the base image has rolled out to the nodes.
+
+. Check the nodes to see that scheduling on the nodes is disabled. This indicates that the change is being applied:
++
+[source,terminal]
+----
+$ oc get nodes
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                         STATUS                     ROLES                  AGE   VERSION
+ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.31.3
+ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.31.3
+ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.31.3
+ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.31.3
+ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.31.3
+ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.31.3
+----
+
+. When the node is back in the `Ready` state, check that the node is using the base image:
+
+.. Open an `oc debug` session to the node. For example:
++
+[source,terminal]
+----
+$ oc debug node/<node_name>
+----
+
+.. Set `/host` as the root directory within the debug shell:
++
+[source,terminal]
+----
+sh-5.1# chroot /host
+----
+
+.. Run an `rpm-ostree status` command to view that the base image is in use:
++
+[source,terminal]
+----
+sh-5.1# rpm-ostree status
+----
++
+.Example output
++
+[source,terminal]
+----
+State: idle
+Deployments:
+* ostree-unverified-image:containers-storage:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:76721c875a2b79688be46b1dca654c2c6619a6be28b29a2822cd86c3f9d8e3c1
+                   Digest: sha256:76721c875a2b79688be46b1dca654c2c6619a6be28b29a2822cd86c3f9d8e3c1
+                  Version: 418.94.202501300706-0 (2025-01-30T07:10:58Z)
+----
diff --git a/modules/coreos-layering-configuring-on.adoc b/modules/coreos-layering-configuring-on.adoc
index e3aed758608d..0c2dbee4de8c 100644
--- a/modules/coreos-layering-configuring-on.adoc
+++ b/modules/coreos-layering-configuring-on.adoc
@@ -6,11 +6,35 @@
 [id="coreos-layering-configuring-on_{context}"]
 = Using on-cluster layering to apply a custom layered image
 
-To apply a custom layered image to your cluster by using the on-cluster build process, make a `MachineOSConfig` custom resource that includes a Containerfile, a machine config pool reference, repository push and pull secrets, and other parameters as described in the prerequisites.
+To apply a custom layered image to your cluster by using the on-cluster build process, make a `MachineOSConfig` custom resource (CR) that specifies the following parameters: 
 
-When you create the object, the Machine Config Operator (MCO) creates a `MachineOSBuild` object and a `machine-os-builder` pod. The build process also creates transient objects, such as config maps, which are cleaned up after the build is complete. 
+* the Containerfile to build
+* the machine config pool to associate the build
+* where the final image should be pushed and pulled from
+* the push and pull secrets to use
 
-When the build is complete, the MCO pushes the new custom layered image to your repository for use when deploying new nodes. You can see the digested image pull spec for the new custom layered image in the `MachineOSBuild` object and `machine-os-builder` pod.
+When you create the object, the Machine Config Operator (MCO) creates a `MachineOSBuild` object and a builder pod. The build process also creates transient objects, such as config maps, which are cleaned up after the build is complete. The `MachineOSBuild` object and the associated `builder-*` pod use the same naming scheme, `<MachineOSConfig_CR_name>-<hash>`, for example:
+
+.Example `MachineOSBuild` object
+[source,terminal]
+----
+NAME                                       PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-c8765e26ebc87e1e17a7d6e0a78e8bae   False      False      True        False         False
+----
+
+.Example builder pod
+[source,terminal]
+----
+NAME                                                READY   STATUS      RESTARTS        AGE
+build-layered-c8765e26ebc87e1e17a7d6e0a78e8bae      2/2     Running     0               11m
+----
+
+When the build is complete, the MCO pushes the new custom layered image to your repository and rolled out to the nodes in the associated machine config pool. You can see the digested image pull spec for the new custom layered image in the `MachineOSBuild` object and `machine-os-builder` pod.
+
+[TIP]
+====
+You can test a `MachineOSBuild` object to make sure it builds correctly without rolling out the custom layered image to active nodes by using a custom machine config pool that contains non-production nodes. Alternatively, you can use a custom machine config pool that has no nodes. The `MachineOSBuild` object builds even if there are no nodes for the MCO to deploy the custom layered image onto.
+====
 
 You should not need to interact with these new objects or the `machine-os-builder` pod. However, you can use all of these resources for troubleshooting, if necessary.
 
@@ -18,14 +42,47 @@ You need a separate `MachineOSConfig` CR for each machine config pool where you
 
 :FeatureName: On-cluster image layering
 include::snippets/technology-preview.adoc[]
+include::snippets//coreos-layering-configuring-on-pause.adoc[]
+
+In the case of a build failure, for example due to network issues or an invalid secret, the MCO retries the build three additional times before the job fails. The MCO creates a different build pod for each build attempt. You can use the build pod logs to troubleshoot any build failures. However, the MCO automatically removes these build pods after a short period of time. 
+
+.Example failed `MachineOSBuild` object
+[source,terminal]
+----
+NAME                                       PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-c8765e26ebc87e1e17a7d6e0a78e8bae   False      False      False        False        True
+----
+
+// Not in 4.18; maybe 4.19
+// You can manually rebuild your custom layered image by either modifying your `MachineOSConfig` object or applying an annotation to the `MachineOSConfig` object as discussed in the following section.
+
+[discrete]
+[id="coreos-layering-configuring-on-limitations_{context}"]
+== On-cluster layering Technology Preview known limitations
+
+Note the following limitations when working with the on-cluster layering feature:
+
+* On-cluster layering is supported only for {product-title} clusters on the AMD64 architecture.
+* On-cluster layering is not supported on multi-architecture compute machines, {sno}, or disconnected clusters.
+* If you scale up a machine set that uses a custom layered image, the nodes reboot two times. The first, when the node is initially created with the base image and a second time when the custom layered image is applied.
+* Node disruption policies are not supported on nodes with a custom layered image. As a result the following configuration changes cause a node reboot:
+** Modifying the configuration files in the `/var` or `/etc` directory
+** Adding or modifying a systemd service
+** Changing SSH keys
+** Removing mirroring rules from `ICSP`, `ITMS`, and `IDMS` objects
+** Changing the trusted CA, by updating the `user-ca-bundle` configmap in the `openshift-config` namespace
+* The images used in creating custom layered images take up space in your push registry. Always be aware of the free space in your registry and prune the images as needed.
 
 .Prerequisites
 
-* You have enabled the `TechPreviewNoUpgrade` feature set by using the feature gates. For more information, see "Enabling features using feature gates".
+* You have enabled the `TechPreviewNoUpgrade` feature set by using the feature gates. For more information, see "Enabling features using feature gates". 
 
-* You have the pull secret in the `openshift-machine-config-operator` namespace that the MCO needs to pull the base operating system image.
+* You have a copy of the pull secret in the `openshift-machine-config-operator` namespace that the MCO needs to pull the base operating system image. 
 
-* You have the push secret that the MCO needs to push the new custom layered image to your registry.
+// Not in 4.18; maybe in 4.19
+// If you are using the global pull secret, the MCO automatically creates a copy when you first create a `MachineOSconfig` object.
+
+* You have the push secret of the registry that the MCO needs to push the new custom layered image to.
 
 * You have a pull secret that your nodes need to pull the new custom layered image from your registry. This should be a different secret than the one used to push the image to the repository.
 
@@ -35,45 +92,48 @@ include::snippets/technology-preview.adoc[]
 
 .Procedure
 
-. Create a `machineOSconfig` object:
+. Create a `MachineOSconfig` object:
 
 .. Create a YAML file similar to the following:
 +
-[source,terminal]
+[source,yaml]
 ----
-apiVersion: machineconfiguration.openshift.io/v1alpha1
+apiVersion: machineconfiguration.openshift.io/v1aplha1 <1>
 kind: MachineOSConfig
 metadata:
-  name: layered
+  name: layered <2>
 spec:
   machineConfigPool:
-    name: <mcp_name> <1>
+    name: worker <3>
   buildInputs:
-    containerFile: # <2>
+    containerFile: <4>
     - containerfileArch: noarch
       content: |-
         FROM configs AS final
-        RUN dnf install -y cowsay && \
-         dnf clean all && \
-         ostree container commit
-    imageBuilder: # <3>
+        RUN rpm-ostree install tree && \
+            ostree container commit
+    imageBuilder: <5>
       imageBuilderType: PodImageBuilder
-    baseImagePullSecret: # <4>
+    baseImagePullSecret: <6>
       name: global-pull-secret-copy
-    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest  # <5>
-    renderedImagePushSecret: # <6>
+    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest <7>
+    renderedImagePushSecret: <8>
       name: builder-dockercfg-7lzwl
-  buildOutputs: # <7>
+  buildOutputs: <9>
     currentImagePullSecret:
       name: builder-dockercfg-7lzwl
 ----
-<1> Specifies the name of the machine config pool associated with the nodes where you want to deploy the custom layered image.
-<2> Specifies the Containerfile to configure the custom layered image.
-<3> Specifies the name of the image builder to use. This must be `PodImageBuilder`.
-<4> Specifies the name of the pull secret that the MCO needs to pull the base operating system image from the registry.
-<5> Specifies the image registry to push the newly-built custom layered image to. This can be any registry that your cluster has access to. This example uses the internal {product-title} registry.
-<6> Specifies the name of the push secret that the MCO needs to push the newly-built custom layered image to that registry.
-<7> Specifies the secret required by the image registry that the nodes need to pull the newly-built custom layered image. This should be a different secret than the one used to push the image to your repository.
+<1> Specifies the `machineconfiguration.openshift.io/v1` API that is required for `MachineConfig` CRs.
+<2> Specifies a name for the `MachineOSConfig` object. This name is used with other on-cluster layering resources. The examples in this documentation use the name `layered`. 
+<3> Specifies the name of the machine config pool associated with the nodes where you want to deploy the custom layered image. The examples in this documentation use the `worker` machine config pool.
+<4> Specifies the Containerfile to configure the custom layered image.
+<5> Specifies the name of the image builder to use. This must be `PodImageBuilder`.
+<6> Specifies the name of the pull secret that the MCO needs in order to pull the base operating system image from the registry.
+<7> Specifies the image registry to push the newly built custom layered image to. This can be any registry that your cluster has access to. This example uses the internal {product-title} registry.
+<8> Specifies the name of the push secret that the MCO needs in order to push the newly built custom layered image to that registry.
+<9> Specifies the secret required by the image registry that the nodes need in order to pull the newly built custom layered image. This should be a different secret than the one used to push the image to your repository.
+// +
+// https://github.com/openshift/openshift-docs/pull/87486/files has the v1 api versions
 
 .. Create the `MachineOSConfig` object:
 +
@@ -94,8 +154,8 @@ $ oc get machineosbuild
 .Example output showing that the `MachineOSBuild` object is ready
 [source,terminal]
 ----
-NAME                                                                PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
-layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False
+NAME                                               PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False
 ----
 
 .. Edit the nodes where you want to deploy the custom layered image by adding a label for the machine config pool you specified in the `MachineOSConfig` object:
@@ -115,86 +175,68 @@ When you save the changes, the MCO drains, cordons, and reboots the nodes. After
 
 .Verification
 
-. Verify that the new pods are running by using the following command:
+. Verify that the new pods are ready by running the following command:
 +
 [source,terminal]
 ----
-$ oc get pods -n <machineosbuilds_namespace>
+$ oc get pods -n openshift-machine-config-operator
 ----
 +
+.Example output
 [source,terminal]
 ----
 NAME                                                              READY   STATUS    RESTARTS   AGE
-build-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0           2/2     Running   0          2m40s # <1>
+build-layered-ad5a3cad36303c363cf458ab0524e7c0-hxrws              2/2     Running   0          2m40s # <1>
 # ...
 machine-os-builder-6fb66cfb99-zcpvq                               1/1     Running   0          2m42s # <2>
 ----
-<1> This is the build pod where the custom layered image is building.
+<1> This is the build pod where the custom layered image is building, named in the `build-<MachineOSConfig_CR_name>-<hash>` format.
 <2> This pod can be used for troubleshooting.
 
-. Verify that the `MachineOSConfig` object contains a reference to the new custom layered image:
+. Verify that the `MachineOSConfig` object contains a reference to the new custom layered image by running the following command:
 +
 [source,terminal]
 ----
-$ oc describe MachineOSConfig <object_name>
+$ oc get machineosbuilds
 ----
 +
-[source,yaml]
+.Example output
+[source,terminal]
 ----
-apiVersion: machineconfiguration.openshift.io/v1alpha1
-kind: MachineOSConfig
-metadata:
-  name: layered
-spec:
-  buildInputs:
-    baseImagePullSecret:
-      name: global-pull-secret-copy
-    containerFile:
-    - containerfileArch: noarch
-      content: ""
-    imageBuilder:
-      imageBuilderType: PodImageBuilder
-    renderedImagePushSecret:
-      name: builder-dockercfg-ng82t-canonical
-    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
-  buildOutputs:
-    currentImagePullSecret:
-      name: global-pull-secret-copy
-  machineConfigPool:
-    name: layered
-status:
-  currentImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd # <1>
+NAME                                       PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
+layered-ad5a3cad36303c363cf458ab0524e7c0   False      True       False       False         False <1>
 ----
-<1> Digested image pull spec for the new custom layered image.
+<1> The `MachineOSBuild` is named in the `<MachineOSConfig_CR_name>-<hash>` format.
 
-. Verify that the `MachineOSBuild` object contains a reference to the new custom layered image.
+. Verify that the `MachineOSBuild` object contains a reference to the new custom layered image by running the following command:
 +
 [source,terminal]
 ----
 $ oc describe machineosbuild <object_name>
 ----
 +
+.Example output
 [source,yaml]
 ----
-apiVersion: machineconfiguration.openshift.io/v1alpha1
-kind: MachineOSBuild
-metadata:
-  name: layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder
-spec:
-  desiredConfig:
-    name: rendered-layered-ad5a3cad36303c363cf458ab0524e7c0
-  machineOSConfig:
-    name: layered
-  renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
+Name:         layered-ad5a3cad36303c363cf458ab0524e7c0
+# ...
+API Version:  machineconfiguration.openshift.io/v1alpha1
+Kind:         MachineOSBuild
+# ...
+Spec:
+  Config Generation:  1
+  Desired Config:
+    Name:  rendered-layered-ad5a3cad36303c363cf458ab0524e7c0
+  Machine OS Config:
+    Name:                   layered
+  Rendered Image Pushspec:  image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-images:layered-ad5a3cad36303c363cf458ab0524e7c0
 # ...
-status:
-  conditions:
-    - lastTransitionTime: "2024-05-21T20:25:06Z"
-      message: Build Ready
-      reason: Ready
-      status: "True"
-      type: Succeeded
-  finalImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd # <1>
+    Last Transition Time:  2025-02-12T19:21:28Z
+    Message:               Build Ready
+    Reason:                Ready
+    Status:                True
+    Type:                  Succeeded
+  Final Image Pullspec:    image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-images@sha256:312e48825e074b01a913deedd6de68abd44894ede50b2d14f99d722f13cda04b <1>
 ----
 <1> Digested image pull spec for the new custom layered image.
 
@@ -226,8 +268,8 @@ sh-5.1# rpm-ostree status
 ----
 # ...
 Deployments:
-* ostree-unverified-registry:quay.io/openshift-release-dev/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd # <1>
-                   Digest: sha256:bcea2546295b2a55e0a9bf6dd4789433a9867e378661093b6fdee0031ed1e8a4
-                  Version: 416.94.202405141654-0 (2024-05-14T16:58:43Z)
+* ostree-unverified-registry:image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-images@sha256:312e48825e074b01a913deedd6de68abd44894ede50b2d14f99d722f13cda04b
+                   Digest: sha256:312e48825e074b01a913deedd6de68abd44894ede50b2d14f99d722f13cda04b <1>
+                  Version: 418.94.202502100215-0 (2025-02-12T19:20:44Z)
 ----
 <1> Digested image pull spec for the new custom layered image.
diff --git a/modules/coreos-layering-configuring.adoc b/modules/coreos-layering-configuring.adoc
index a714204dd30d..1406ca9448aa 100644
--- a/modules/coreos-layering-configuring.adoc
+++ b/modules/coreos-layering-configuring.adoc
@@ -65,7 +65,7 @@ metadata:
 spec:
   osImageURL: quay.io/my-registry/custom-image@sha256... <2>
 ----
-<1> Specifies the machine config pool to apply the custom layered image.
+<1> Specifies the machine config pool to deploy the custom layered image.
 <2> Specifies the path to the custom layered image in the repository.
 
 .. Create the `MachineConfig` object:
@@ -97,20 +97,20 @@ $ oc get mc
 [source,terminal]
 ----
 NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
-00-master                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-00-worker                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-01-master-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-01-master-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-01-worker-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-01-worker-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-99-master-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
+00-master                                          5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+00-worker                                          5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+01-master-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+01-master-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+01-worker-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+01-worker-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+99-master-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
 99-master-ssh                                                                                 3.2.0             98m
-99-worker-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
+99-worker-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
 99-worker-ssh                                                                                 3.2.0             98m
 os-layer-custom                                                                                                 10s <1>
-rendered-master-15961f1da260f7be141006404d17d39b   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-rendered-worker-5aff604cb1381a4fe07feaf1595a797e   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
-rendered-worker-5de4837625b1cbc237de6b22bc0bc873   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             4s  <2>
+rendered-master-15961f1da260f7be141006404d17d39b   5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+rendered-worker-5aff604cb1381a4fe07feaf1595a797e   5bdb57489b720096ef912f738b46330a8f577803   3.4.0             95m
+rendered-worker-5de4837625b1cbc237de6b22bc0bc873   5bdb57489b720096ef912f738b46330a8f577803   3.4.0             4s  <2>
 ----
 <1> New machine config
 <2> New rendered machine config
diff --git a/modules/coreos-layering-removing.adoc b/modules/coreos-layering-removing.adoc
index 79c4bae49d88..3006f40cee13 100644
--- a/modules/coreos-layering-removing.adoc
+++ b/modules/coreos-layering-removing.adoc
@@ -4,15 +4,15 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="coreos-layering-removing_{context}"]
-= Removing a {op-system} custom layered image
+= Reverting an out-of-cluster node
 
-You can easily revert {op-system-first} image layering from the nodes in specific machine config pools. The Machine Config Operator (MCO) reboots those nodes with the cluster base {op-system-first} image, overriding the custom layered image.
+You can revert an out-of-cluster custom layered image from the nodes in specific machine config pools. The Machine Config Operator (MCO) reboots those nodes with the cluster base {op-system-first} image, overriding the custom layered image.
 
 To remove a {op-system-first} custom layered image from your cluster, you need to delete the machine config that applied the image.
 
 .Procedure
 
-. Delete the machine config that applied the custom layered image.
+* Delete the machine config that applied the custom layered image.
 +
 [source,terminal]
 ----
@@ -62,25 +62,25 @@ ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker
 
 . When the node is back in the `Ready` state, check that the node is using the base image:
 
-.. Open an `oc debug` session to the node. For example:
+.. Open an `oc debug` session to the node by running the following command:
 +
 [source,terminal]
 ----
-$ oc debug node/ip-10-0-155-125.us-west-1.compute.internal
+$ oc debug node/<node_name>
 ----
 
-.. Set `/host` as the root directory within the debug shell:
+.. Set `/host` as the root directory within the debug shell by running the following command:
 +
 [source,terminal]
 ----
-sh-4.4# chroot /host
+sh-5.1# chroot /host
 ----
 
 .. Run the `rpm-ostree status` command to view that the custom layered image is in use:
 +
 [source,terminal]
 ----
-sh-4.4# sudo rpm-ostree status
+sh-5.1# sudo rpm-ostree status
 ----
 +
 .Example output
diff --git a/modules/cpmso-openstack-with-az-config.adoc b/modules/cpmso-openstack-with-az-config.adoc
index bff22f5c59e5..5e1c70c57fa1 100644
--- a/modules/cpmso-openstack-with-az-config.adoc
+++ b/modules/cpmso-openstack-with-az-config.adoc
@@ -32,7 +32,7 @@ where:
 . For the `master-1` and `master-2` control plane machines, edit the value of the `serverGroupName` property in their provider specs to match that of the machine `master-0`.
 +
 .An example {rh-openstack} provider spec
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 providerSpec:
   value:
@@ -43,7 +43,7 @@ providerSpec:
       name: openstack-cloud-credentials
       namespace: openshift-machine-api
     flavor: m1.xlarge
-    image: rhcos-4.17
+    image: rhcos-{product-version}
     kind: OpenstackProviderSpec
     metadata:
       creationTimestamp: null
diff --git a/modules/cpmso-yaml-failure-domain-vsphere.adoc b/modules/cpmso-yaml-failure-domain-vsphere.adoc
index 02b3c87f5d76..ece36c79abb5 100644
--- a/modules/cpmso-yaml-failure-domain-vsphere.adoc
+++ b/modules/cpmso-yaml-failure-domain-vsphere.adoc
@@ -34,8 +34,8 @@ spec:
       failureDomains: # <1>
         platform: VSphere
         vsphere: # <2>
-        - name: <failure_domain_name1>
-        - name: <failure_domain_name2>
+        - name: <failure_domain_name_1>
+        - name: <failure_domain_name_2>
 # ...
 ----
 <1> Specifies the vCenter location for {product-title} cluster nodes.
diff --git a/modules/cpmso-yaml-provider-spec-nutanix.adoc b/modules/cpmso-yaml-provider-spec-nutanix.adoc
index a01b5fdea0fa..813c122acfb4 100644
--- a/modules/cpmso-yaml-provider-spec-nutanix.adoc
+++ b/modules/cpmso-yaml-provider-spec-nutanix.adoc
@@ -78,7 +78,7 @@ You must use the `Legacy` boot type in {product-title} {product-version}.
 ====
 Clusters that use {product-title} version 4.15 or later can use failure domain configurations.
 
-If the cluster is configured to use a failure domain, this parameter is configured in the failure domain.
+If the cluster uses a failure domain, configure this parameter in the failure domain.
 If you specify this value in the provider specification when using failure domains, the Control Plane Machine Set Operator ignores it.
 ====
 <4> Specifies the secret name for the cluster. Do not change this value.
@@ -86,13 +86,32 @@ If you specify this value in the provider specification when using failure domai
 <6> Specifies the cloud provider platform type. Do not change this value.
 <7> Specifies the memory allocated for the control plane machines.
 <8> Specifies the Nutanix project that you use for your cluster. In this example, the project type is `name`, so there is a `name` stanza.
-<9> Specifies a subnet configuration. In this example, the subnet type is `uuid`, so there is a `uuid` stanza.
+<9> Specify one or more Prism Element subnet objects.
+In this example, the subnet type is `uuid`, so there is a `uuid` stanza.
+A maximum of 32 subnets for each Prism Element failure domain in the cluster is supported.
++
+[IMPORTANT]
+====
+The following known issues with configuring multiple subnets for an existing Nutanix cluster by using a control plane machine set exist in {product-title} version 4.18:
+
+* Adding subnets above the existing subnet in the `subnets` stanza causes a control plane node to become stuck in the `Deleting` state.
+As a workaround, only add subnets below the existing subnet in the `subnets` stanza.
+
+* Sometimes, after adding a subnet, the updated control plane machines appear in the Nutanix console but the {product-title} cluster is unreachable.
+There is no workaround for this issue.
+
+These issues occur on clusters that use a control plane machine set to configure subnets regardless of whether subnets are specified in a failure domain or the provider specification.
+For more information, see link:https://issues.redhat.com/browse/OCPBUGS-50904[*OCPBUGS-50904*].
+====
++
+The CIDR IP address prefix for one of the specified subnets must contain the virtual IP addresses that the {product-title} cluster uses. 
+All subnet UUID values must be unique.
 +
 [NOTE]
 ====
 Clusters that use {product-title} version 4.15 or later can use failure domain configurations.
 
-If the cluster is configured to use a failure domain, this parameter is configured in the failure domain.
+If the cluster uses a failure domain, configure this parameter in the failure domain.
 If you specify this value in the provider specification when using failure domains, the Control Plane Machine Set Operator ignores it.
 ====
 <10> Specifies the VM disk size for the control plane machines.
diff --git a/modules/create-a-containerruntimeconfig-crd.adoc b/modules/create-a-containerruntimeconfig-crd.adoc
index 3534d91ad0f4..640ff1552eeb 100644
--- a/modules/create-a-containerruntimeconfig-crd.adoc
+++ b/modules/create-a-containerruntimeconfig-crd.adoc
@@ -15,16 +15,8 @@ To revert the changes implemented by using a `ContainerRuntimeConfig` CR, you mu
 
 You can modify the following settings by using a `ContainerRuntimeConfig` CR:
 
-* **PIDs limit**: Setting the PIDs limit in the `ContainerRuntimeConfig` is expected to be deprecated. If PIDs limits are required, it is recommended to use the `podPidsLimit` field in the `KubeletConfig` CR instead. The default `podPidsLimit` value is `4096` and the default `pids_limit` value is `0`. If `podPidsLimit` is lower than `pids_limit` then the effective container PIDs limit is defined by the value set in `podPidsLimit`.
-+
-[NOTE]
-====
-The CRI-O flag is applied on the cgroup of the container, while the Kubelet flag is set on the cgroup of the pod. Please adjust the PIDs limit accordingly.
-====
-
 * **Log level**: The `logLevel` parameter sets the CRI-O `log_level` parameter, which is the level of verbosity for log messages. The default is `info` (`log_level = info`). Other options include `fatal`, `panic`, `error`, `warn`, `debug`, and `trace`.
 * **Overlay size**: The `overlaySize` parameter sets the CRI-O Overlay storage driver `size` parameter, which is the maximum size of a container image.
-* **Maximum log size**: Setting the maximum log size in the `ContainerRuntimeConfig` is expected to be deprecated. If a maximum log size is required, it is recommended to use the `containerLogMaxSize` field in the `KubeletConfig` CR instead.
 * **Container runtime**: The `defaultRuntime` parameter sets the container runtime to either `crun` or `runc`. The default is `crun`.
 
 You should have one `ContainerRuntimeConfig` CR for each machine config pool with all the config changes you want for that pool. If you are applying the same content to all the pools, you only need one `ContainerRuntimeConfig` CR for all the pools.
@@ -64,13 +56,13 @@ $ oc get mc | grep container
 [source,terminal]
 ----
 ...
-01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
+01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             57m
 ...
-01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
+01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             57m
 ...
-99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
-99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
-99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
+99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             26m
+99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             17m
+99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             7m26s
 ...
 ----
 
@@ -152,7 +144,7 @@ $ oc get machineconfigs | grep containerrun
 .Example output
 [source,terminal]
 ----
-99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s
+99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.4.0  31s
 ----
 
 . Monitor the machine config pool until all are shown as ready:
diff --git a/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc b/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc
index a572adeb91e4..6d8181bee2ee 100644
--- a/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc
+++ b/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc
@@ -5,7 +5,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="create-a-kubeletconfig-crd-to-edit-kubelet-parameters_{context}"]
-= Creating a KubeletConfig CRD to edit kubelet parameters
+= Creating a KubeletConfig CR to edit kubelet parameters
 
 The kubelet configuration is currently serialized as an Ignition configuration, so it can be directly edited. However, there is also a new `kubelet-config-controller` added to the Machine Config Controller (MCC). This lets you use a `KubeletConfig` custom resource (CR) to edit the kubelet parameters.
 
@@ -57,8 +57,8 @@ $ oc get kubeletconfig
 
 [source,terminal]
 ----
-NAME                AGE
-set-max-pods        15m
+NAME                      AGE
+set-kubelet-config        15m
 ----
 
 .Example showing a `KubeletConfig` machine config
@@ -70,11 +70,11 @@ $ oc get mc | grep kubelet
 [source,terminal]
 ----
 ...
-99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
+99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.4.0             26m
 ...
 ----
 
-The following procedure is an example to show how to configure the maximum number of pods per node on the worker nodes.
+The following procedure is an example to show how to configure the maximum number of pods per node, the maximum PIDs per node, and the maximum container log size size on the worker nodes.
 
 .Prerequisites
 
@@ -104,7 +104,7 @@ metadata:
   creationTimestamp: 2019-02-08T14:52:39Z
   generation: 1
   labels:
-    custom-kubelet: set-max-pods <1>
+    custom-kubelet: set-kubelet-config <1>
 ----
 <1> If a label has been added it appears under `labels`.
 
@@ -112,7 +112,7 @@ metadata:
 +
 [source,terminal]
 ----
-$ oc label machineconfigpool worker custom-kubelet=set-max-pods
+$ oc label machineconfigpool worker custom-kubelet=set-kubelet-config
 ----
 
 .Procedure
@@ -154,7 +154,9 @@ Allocatable:
  pods:                        250
 ----
 
-. Set the maximum pods per node on the worker nodes by creating a custom resource file that contains the kubelet configuration:
+. Configure the worker nodes as needed: 
+
+.. Create a YAML file similar to the following that contains the kubelet configuration:
 +
 [IMPORTANT]
 ====
@@ -166,16 +168,23 @@ Kubelet configurations that target a specific machine config pool also affect an
 apiVersion: machineconfiguration.openshift.io/v1
 kind: KubeletConfig
 metadata:
-  name: set-max-pods
+  name: set-kubelet-config
 spec:
   machineConfigPoolSelector:
     matchLabels:
-      custom-kubelet: set-max-pods <1>
-  kubeletConfig:
-    maxPods: 500 <2>
+      custom-kubelet: set-kubelet-config <1>
+  kubeletConfig: <2>
+      podPidsLimit: 8192
+      containerLogMaxSize: 50Mi
+      maxPods: 500
 ----
 <1> Enter the label from the machine config pool.
-<2> Add the kubelet configuration. In this example, use `maxPods` to set the maximum pods per node.
+<2> Add the kubelet configuration. For example: 
++
+--
+* Use `podPidsLimit` to set the maximum number of PIDs in any pod.
+* Use `containerLogMaxSize` to set the maximum size of the container log file before it is rotated.
+* Use `maxPods` to set the maximum pods per node.
 +
 [NOTE]
 ====
@@ -186,22 +195,25 @@ The rate at which the kubelet talks to the API server depends on queries per sec
 apiVersion: machineconfiguration.openshift.io/v1
 kind: KubeletConfig
 metadata:
-  name: set-max-pods
+  name: set-kubelet-config
 spec:
   machineConfigPoolSelector:
     matchLabels:
-      custom-kubelet: set-max-pods
+      custom-kubelet: set-kubelet-config
   kubeletConfig:
     maxPods: <pod_count>
     kubeAPIBurst: <burst_rate>
     kubeAPIQPS: <QPS>
 ----
 ====
+
+--
+
 .. Update the machine config pool for workers with the label:
 +
 [source,terminal]
 ----
-$ oc label machineconfigpool worker custom-kubelet=set-max-pods
+$ oc label machineconfigpool worker custom-kubelet=set-kubelet-config
 ----
 
 .. Create the `KubeletConfig` object:
@@ -211,7 +223,9 @@ $ oc label machineconfigpool worker custom-kubelet=set-max-pods
 $ oc create -f change-maxPods-cr.yaml
 ----
 
-.. Verify that the `KubeletConfig` object is created:
+.Verification
+
+. Verify that the `KubeletConfig` object is created:
 +
 [source,terminal]
 ----
@@ -221,8 +235,8 @@ $ oc get kubeletconfig
 .Example output
 [source,terminal]
 ----
-NAME                AGE
-set-max-pods        15m
+NAME                      AGE
+set-kubelet-config        15m
 ----
 +
 Depending on the number of worker nodes in the cluster, wait for the worker nodes to be rebooted one by one. For a cluster with 3 worker nodes, this could take about 10 to 15 minutes.
@@ -257,7 +271,7 @@ Allocatable:
 +
 [source,terminal]
 ----
-$ oc get kubeletconfigs set-max-pods -o yaml
+$ oc get kubeletconfigs set-kubelet-config -o yaml
 ----
 +
 This should show a status of `True` and `type:Success`, as shown in the following example:
@@ -266,10 +280,12 @@ This should show a status of `True` and `type:Success`, as shown in the followin
 ----
 spec:
   kubeletConfig:
+    containerLogMaxSize: 50Mi
     maxPods: 500
+    podPidsLimit: 8192
   machineConfigPoolSelector:
     matchLabels:
-      custom-kubelet: set-max-pods
+      custom-kubelet: set-kubelet-config
 status:
   conditions:
   - lastTransitionTime: "2021-06-30T17:04:07Z"
diff --git a/modules/create-crio-default-capabilities.adoc b/modules/create-crio-default-capabilities.adoc
new file mode 100644
index 000000000000..497bdb22481c
--- /dev/null
+++ b/modules/create-crio-default-capabilities.adoc
@@ -0,0 +1,46 @@
+// Module included in the following assemblies:
+//
+// * machine_configuration/machine-configs-custom.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="create-crio-default-capabilities_{context}"]
+= Creating a drop-in file for the default CRI-O capabilities
+
+You can change some of the settings associated with the {product-title} CRI-O runtime for the nodes associated with a specific machine config pool (MCP). By using a controller custom resource (CR), you set the configuration values and add a label to match the MCP. The Machine Config Operator (MCO) then rebuilds the `crio.conf` and `default.conf` configuration files on the associated nodes with the updated values.
+
+Earlier versions of {product-title} included specific machine configs by default. If you updated to a later version of {product-title}, those machine configs were retained to ensure that clusters running on the same {product-title} version have the same machine configs.
+
+You can create multiple `ContainerRuntimeConfig` CRs, as needed, with a limit of 10 per cluster. For the first `ContainerRuntimeConfig` CR, the MCO creates a machine config appended with `containerruntime`. With each subsequent CR, the controller creates a `containerruntime` machine config with a numeric suffix. For example, if you have a `containerruntime` machine config with a `-2` suffix, the next `containerruntime` machine config is appended with `-3`.
+
+If you want to delete the machine configs, delete them in reverse order to avoid exceeding the limit. For example, delete the `containerruntime-3` machine config before you delete the `containerruntime-2` machine config.
+
+[NOTE]
+====
+If you have a machine config with a `containerruntime-9` suffix and you create another `ContainerRuntimeConfig` CR, a new machine config is not created, even if there are fewer than 10 `containerruntime` machine configs.
+====
+
+.Example of multiple ContainerRuntimeConfig CRs
+[source,terminal]
+----
+$ oc get ctrcfg
+----
+
+.Example output
+[source,terminal]
+----
+NAME         AGE
+ctr-overlay  15m
+ctr-level    5m45s
+----
+
+.Example showing multiple containerruntime related system configs
+[source,terminal]
+----
+$ cat /proc/1/status | grep Cap
+----
+
+[source,terminal]
+----
+$ capsh --decode=<decode_CapBnd_value> <1>
+----
+<1> Replace `<decode_CapBnd_value>` with the specific value you want to decode.
diff --git a/modules/create-wif-cluster-cli.adoc b/modules/create-wif-cluster-cli.adoc
index a35fbafcbb55..b1cb443d8551 100644
--- a/modules/create-wif-cluster-cli.adoc
+++ b/modules/create-wif-cluster-cli.adoc
@@ -9,9 +9,16 @@
 
 You can create an {product-title} on {GCP} cluster with Workload Identity Federation (WIF) using the OpenShift Cluster Manager CLI (`ocm`) in interactive or non-interactive mode.
 
+[NOTE]
+====
+Download the latest version of the OpenShift Cluster Manager CLI (`ocm`) for your operating system from the link:https://console.redhat.com/openshift/downloads[Downloads] page on OpenShift Cluster Manager.
+====
+
 [IMPORTANT]
 ====
-To create a WIF-enabled cluster, the OpenShift Cluster Manager CLI (`ocm`) must be version 1.0.2 or greater.
+[subs="attributes+"]
+OpenShift Cluster Manager API command-line interface (`ocm`) is a Developer Preview feature only.
+For more information about the support scope of Red Hat Developer Preview features, see link:https://access.redhat.com/support/offerings/devpreview/[Developer Preview Support Scope].
 ====
 
 Before creating the cluster, you must first create a WIF configuration.
@@ -38,9 +45,11 @@ Alternatively, you can use the `manual` mode. In `manual` mode, you are provided
 ----
 $ ocm gcp create wif-config --name <wif_name> \ <1>
   --project <gcp_project_id> \ <2>
+  --version <osd_version> <3>
 ----
 <1> Replace `<wif_name>` with the name of your WIF configuration.
 <2> Replace `<gcp_project_id>` with the ID of the {GCP} project where the WIF configuration will be implemented.
+<3> Optional: Replace `<osd_version>` with the desired {product-title} version the wif-config will need to support. If you do not specify a version, the wif-config will support the latest {product-title} y-stream version as well as the last three supported {product-title} y-stream versions (beginning with version 4.17).
 +
 --
 .Example output
@@ -59,7 +68,7 @@ $ ocm gcp create wif-config --name <wif_name> \ <1>
 2024/09/26 13:05:52 IAM service account cloud-credential-operator-oeub created
 2024/09/26 13:05:52 IAM service account openshift-cloud-network-c-oeub created
 2024/09/26 13:05:53 IAM service account openshift-ingress-gcp-oeub created
-2024/09/26 13:05:55 Role "osd_deployer_v4.17" updated
+2024/09/26 13:05:55 Role "osd_deployer_v4.18" updated
 ----
 --
 +
@@ -85,7 +94,7 @@ Once the WIF is configured, the following service accounts, roles, and groups ar
 
 
 |osd-deployer
-|osd_deployer_v4.17
+|osd_deployer_v4.18
 
 
 |osd-control-plane
@@ -99,35 +108,35 @@ Once the WIF is configured, the following service accounts, roles, and groups ar
 - compute.viewer
 
 |cloud-credential-operator-gcp-ro-creds
-|cloud_credential_operator_gcp_ro_creds_v4.17
+|cloud_credential_operator_gcp_ro_creds_v{product-version}
 
 |openshift-cloud-network-config-controller-gcp
-|openshift_cloud_network_config_controller_gcp_v4.17
+|openshift_cloud_network_config_controller_gcp_v{product-version}
 
 |openshift-gcp-ccm
-|openshift_gcp_ccm_v4.17
+|openshift_gcp_ccm_v{product-version}
 
 |openshift-gcp-pd-csi-driver-operator
 |- compute.storageAdmin
 - iam.serviceAccountUser
 - resourcemanager.tagUser
-- openshift_gcp_pd_csi_driver_operator_v4.17
+- openshift_gcp_pd_csi_driver_operator_v{product-version}
 
 |openshift-image-registry-gcp
-|openshift_image_registry_gcs_v4.17
+|openshift_image_registry_gcs_v{product-version}
 
 |openshift-ingress-gcp
-|openshift_ingress_gcp_v4.17
+|openshift_ingress_gcp_v{product-version}
 
 |openshift-machine-api-gcp
-|openshift_machine_api_gcp_v4.17
+|openshift_machine_api_gcp_v{product-version}
 
 |Access via SRE group:sd-sre-platform-gcp-access
 |sre_managed_support
 
 |===
 
-For further details about WIF configuration roles and their assigned permissions, see link:https://github.com/openshift/managed-cluster-config/blob/master/resources/wif/4.17/vanilla.yaml[managed-cluster-config].
+For further details about WIF configuration roles and their assigned permissions, see link:https://github.com/openshift/managed-cluster-config/blob/master/resources/wif/4.18/vanilla.yaml[managed-cluster-config].
 
 [id="create-wif-cluster_{context}"]
 == Creating a WIF cluster
@@ -179,13 +188,18 @@ $ ocm create cluster <cluster_name> \ <1>
 <5> Replace `<gcp_region>` with the {GCP} region where the new cluster will be deployed.
 <6> Optional: The subscription billing model for the cluster.
 <7> Optional: If you provided a value of `marketplace-gcp` for the `subscription-type` parameter, `marketplace-gcp-terms` must be equal to `true`.
-<8> Optional: The desired OpenShift version.
+<8> Optional: The desired {product-title} version.
 <9> Optional: Deploy to multiple data centers.
 <10> Optional: Enable autoscaling of compute nodes.
 <11> Optional: Minimum number of compute nodes.
 <12> Optional: Maximum number of compute nodes.
 <13> Optional: Secure Boot enables the use of Shielded VMs in the Google Cloud Platform.
 
+[IMPORTANT]
+====
+If an {product-title} version is specified, the version must also be supported by the assigned WIF configuration. If a version is specified that is not supported by the assigned WIF configuration, cluster creation will fail.  If this occurs, update the assigned WIF configuration to the desired version or create a new WIF configuration with the desired version in the --version <osd_version> field.
+====
+
 [id="ocm-cli-list-wif-commands_{context}"]
 == Listing WIF clusters
 
@@ -209,17 +223,17 @@ $ ocm list clusters --parameter search="gcp.authentication.wif_config_id = '<wif
 ====
 Updating a WIF configuration is only applicable for y-stream updates. For an overview of the update process, including details regarding version semantics, see link:https://www.redhat.com/en/blog/the-ultimate-guide-to-openshift-release-and-upgrade-process-for-cluster-administrators#:~:text=Ongoing%20security%20patches%20and%20bug,is%20the%20dark%20green%20bar.[The Ultimate Guide to OpenShift Release and Upgrade Process for Cluster Administrators].
 ====
-Before updating a WIF-enabled {product-title} cluster to a newer version, you must update the wif-config to that version as well. If you do not update the wif-config version before attempting to update the cluster version, the cluster version update will fail.
+Before upgrading a WIF-enabled {product-title} cluster to a newer version, you must update the wif-config to that version as well. If you do not update the wif-config version before attempting to upgrade the cluster version, the cluster version upgrade will fail.
 
 You can update a wif-config to a specific {product-title} version by running the following command:
 
 [source,terminal]
 ----
-ocm gcp update wif-config --version <version> \ <1>
---name <wif_name> <2>
+ocm gcp update wif-config <wif_name> \ <1>
+--version <version> <2>
 ----
-<1> Replace `<version>` with the {product-title} y-stream version you plan to update the cluster to.
-<2> Replace `<wif_name>` with the name of the WIF configuration you want to update.
+<1> Replace `<wif_name>` with the name of the WIF configuration you want to update.
+<2> Optional: Replace `<version>` with the {product-title} y-stream version you plan to update the cluster to. If you do not specify a version, the wif-config will be updated to support the latest {product-title} y-stream version as well as the last three {product-title} supported y-stream versions (beginning with version 4.17).
 
 [id="ocm-cli-verify-wif-commands_{context}"]
 == Verifying a WIF configuration
diff --git a/modules/create-wif-cluster-ocm.adoc b/modules/create-wif-cluster-ocm.adoc
index 02db88a139cf..b0f29fbc4995 100644
--- a/modules/create-wif-cluster-ocm.adoc
+++ b/modules/create-wif-cluster-ocm.adoc
@@ -55,13 +55,14 @@ Workload Identity Federation (WIF) is only supported on {product-title} version
 .. Select a cloud provider region from the *Region* drop-down menu.
 .. Select a *Single zone* or *Multi-zone* configuration.
 +
-.. Optional: Select *Enable Secure Boot for Shielded VMs* to use Shielded VMs when installing your cluster. For more information, see link:https://cloud.google.com/security/products/shielded-vm[Shielded VMs].
+.. Optional: Select *Enable Secure Boot support for Shielded VMs* to use Shielded VMs when installing your cluster. For more information, see link:https://cloud.google.com/security/products/shielded-vm[Shielded VMs].
 +
 [IMPORTANT]
 ====
 To successfully create a cluster, you must select *Enable Secure Boot support for Shielded VMs* if your organization has the policy constraint `constraints/compute.requireShieldedVm` enabled. For more information regarding GCP organizational policy constraints, see link:https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints[Organization policy constraints].
 ====
 +
+
 .. Leave *Enable user workload monitoring* selected to monitor your own projects in isolation from Red Hat Site Reliability Engineer (SRE) platform metrics. This option is enabled by default.
 
 . Optional: Expand *Advanced Encryption* to make changes to encryption settings.
diff --git a/modules/creating-a-machine-pool-cli.adoc b/modules/creating-a-machine-pool-cli.adoc
index 8a4ce107b3c2..45a9388cc65d 100644
--- a/modules/creating-a-machine-pool-cli.adoc
+++ b/modules/creating-a-machine-pool-cli.adoc
@@ -54,7 +54,7 @@ Your Amazon EC2 Spot Instances might be interrupted at any time. Use Amazon EC2
 ====
 endif::openshift-rosa[]
 `--disk-size=<disk_size>`:: Optional: Specifies the worker node disk size. The value can be in GB, GiB, TB, or TiB. Replace `<disk_size>` with a numeric value and unit, for example `--disk-size=200GiB`.
-`--availability-zone=<availability_zone_name>`:: 
+`--availability-zone=<availability_zone_name>`::
 ifdef::openshift-rosa-hcp[]
 Optional: You can create a machine pool in an availability zone of your choice. Replace `<availability_zone_name>` with an availability zone name.
 endif::openshift-rosa-hcp[]
@@ -196,9 +196,9 @@ I: To view all machine pools, run 'rosa list machinepools -c mycluster'
 ----
 
 //ifdef::openshift-rosa-hcp[] Uncomment this out once HCP split occurs
-* To add a Windows Licence Included enabled machine pool to a {hcp-title} cluster, see link:https://access.redhat.com/articles/7096903[AWS Windows License Included for ROSA with HCP].
+* To add a Windows License Included enabled machine pool to a {hcp-title} cluster, see link:https://access.redhat.com/articles/7096903[AWS Windows License Included for ROSA with HCP].
 +
-Windows Licence Included enabled machine pools can only be created when the following criteria is met:
+Windows License Included enabled machine pools can only be created when the following criteria is met:
 
 ** The host cluster is a {hcp-title} cluster.
 ** The instance type is bare metal EC2.
@@ -277,15 +277,15 @@ Desired replicas:           3-6
 Current replicas:           3
 Instance type:              m5.xlarge
 Labels:                     app=db, tier=backend
-Taints:                                
+Taints:
 Availability zone:          us-east-2a
 Subnet:                     subnet-0cb56f5f41880c413
 Version:                    4.14.34
 Autorepair:                 Yes
-Tuning configs:                        
-Additional security group IDs: 
-Node drain grace period:              
-Message:           
+Tuning configs:
+Additional security group IDs:
+Node drain grace period:
+Message:
 ----
 endif::openshift-rosa-hcp[]
 
diff --git a/modules/creating-an-infra-node.adoc b/modules/creating-an-infra-node.adoc
index 26f598b6a4f6..e90f9cea7aec 100644
--- a/modules/creating-an-infra-node.adoc
+++ b/modules/creating-an-infra-node.adoc
@@ -13,16 +13,20 @@
 See Creating infrastructure machine sets for installer-provisioned infrastructure environments or for any cluster where the control plane nodes are managed by the machine API.
 ====
 
-Requirements of the cluster dictate that infrastructure, also called `infra` nodes, be provisioned. The installer only provides provisions for control plane and worker nodes. Worker nodes can be designated as infrastructure nodes or application, also called `app`, nodes through labeling.
+Requirements of the cluster dictate that infrastructure (infra) nodes, be provisioned. The installation program provisions only control plane and worker nodes. Worker nodes can be designated as infrastructure nodes through labeling. You can then use taints and tolerations to move appropriate workloads to the infrastructure nodes. For more information, see "Moving resources to infrastructure machine sets".
 
-.Procedure
+You can optionally create a default cluster-wide node selector. The default node selector is applied to pods created in all namespaces and creates an intersection with any existing node selectors on a pod, which additionally constrains the pod's selector.
 
-. Add a label to the worker node that you want to act as application node:
-+
-[source,terminal]
-----
-$ oc label node <node-name> node-role.kubernetes.io/app=""
-----
+[IMPORTANT]
+====
+If the default node selector key conflicts with the key of a pod's label, then the default node selector is not applied.
+
+However, do not set a default node selector that might cause a pod to become unschedulable. For example, setting the default node selector to a specific node role, such as `node-role.kubernetes.io/infra=""`, when a pod's label is set to a different node role, such as `node-role.kubernetes.io/master=""`, can cause the pod to become unschedulable. For this reason, use caution when setting the default node selector to specific node roles.
+
+You can alternatively use a project node selector to avoid cluster-wide node selector key conflicts.
+====
+
+.Procedure
 
 . Add a label to the worker nodes that you want to act as infrastructure nodes:
 +
@@ -31,23 +35,14 @@ $ oc label node <node-name> node-role.kubernetes.io/app=""
 $ oc label node <node-name> node-role.kubernetes.io/infra=""
 ----
 
-. Check to see if applicable nodes now have the `infra` role and `app` roles:
+. Check to see if applicable nodes now have the `infra` role:
 +
 [source,terminal]
 ----
 $ oc get nodes
 ----
 
-. Create a default cluster-wide node selector. The default node selector is applied to pods created in all namespaces. This creates an intersection with any existing node selectors on a pod, which additionally constrains the pod's selector.
-+
-[IMPORTANT]
-====
-If the default node selector key conflicts with the key of a pod's label, then the default node selector is not applied.
-
-However, do not set a default node selector that might cause a pod to become unschedulable. For example, setting the default node selector to a specific node role, such as `node-role.kubernetes.io/infra=""`, when a pod's label is set to a different node role, such as `node-role.kubernetes.io/master=""`, can cause the pod to become unschedulable. For this reason, use caution when setting the default node selector to specific node roles.
-
-You can alternatively use a project node selector to avoid cluster-wide node selector key conflicts.
-====
+. Optional: Create a default cluster-wide node selector:
 
 .. Edit the `Scheduler` object:
 +
@@ -72,4 +67,4 @@ spec:
 
 .. Save the file to apply the changes.
 
-You can now move infrastructure resources to the newly labeled `infra` nodes.
+You can now move infrastructure resources to the new infrastructure nodes. Also, remove any workloads that you do not want, or that do not belong, on the new infrastructure node. See the list of workloads supported for use on infrastructure nodes in "{product-title} infrastructure components".
diff --git a/modules/creating-config-files-cluster-install-oci.adoc b/modules/creating-config-files-cluster-install-oci.adoc
index cc3163eb56e9..9b003728127e 100644
--- a/modules/creating-config-files-cluster-install-oci.adoc
+++ b/modules/creating-config-files-cluster-install-oci.adoc
@@ -1,14 +1,40 @@
 // Module included in the following assemblies:
 //
 // * installing/installing_oci/installing-oci-agent-based-installer.adoc
+// * installing/installing_oci/installing-pca-agent-based-installer.adoc
+
+ifeval::["{context}" == "installing-pca-agent-based-installer"]
+:pca:
+endif::[]
+
+
+ifeval::["{context}" == "installing-c3-agent-based-installer"]
+:c3:
+endif::[]
 
 :_mod-docs-content-type: PROCEDURE
+
+ifdef::c3[]
+[id="creating-config-files-cluster-install-c3_{context}"]
+= Creating configuration files for installing a cluster on {oci-c3-short}
+
+You must create the `install-config.yaml` and the `agent-config.yaml` configuration files so that you can use the Agent-based Installer to generate a bootable ISO image. The Agent-based installation comprises a bootable ISO that has the Assisted discovery agent and the Assisted Service. Both of these components are required to perform the cluster installation, but the latter component runs on only one of the hosts.
+endif::c3[]
+
+ifdef::pca[]
+[id="creating-config-files-cluster-install-pca_{context}"]
+= Creating configuration files for installing a cluster on {oci-pca-short}
+
+You must create the `install-config.yaml` and the `agent-config.yaml` configuration files so that you can use the Agent-based Installer to generate a bootable ISO image. The Agent-based installation comprises a bootable ISO that has the Assisted discovery agent and the Assisted Service. Both of these components are required to perform the cluster installation, but the latter component runs on only one of the hosts.
+endif::pca[]
+
+ifndef::pca,c3[]
 [id="creating-config-files-cluster-install-oci_{context}"]
 = Creating configuration files for installing a cluster on {oci}
 
 You must create the `install-config.yaml` and the `agent-config.yaml` configuration files so that you can use the Agent-based Installer to generate a bootable ISO image. The Agent-based installation comprises a bootable ISO that has the Assisted discovery agent and the Assisted Service. Both of these components are required to perform the cluster installation, but the latter component runs on only one of the hosts.
 
-At a later stage, you must follow the steps in the Oracle documentation for uploading your generated agent ISO image to Oracle's default Object Storage bucket, which is the initial step for integrating your {product-title} cluster on {oci-first}.
+endif::pca,c3[]
 
 [NOTE]
 ====
@@ -34,9 +60,9 @@ $ ./openshift-install version
 .Example output for a shared registry binary
 [source,terminal,subs="quotes"]
 ----
-./openshift-install 4.17.0
+./openshift-install 4.18.0
 built from commit ae7977b7d1ca908674a0d45c5c243c766fa4b2ca
-release image registry.ci.openshift.org/origin/release:4.17ocp-release@sha256:0da6316466d60a3a4535d5fed3589feb0391989982fba59d47d4c729912d6363
+release image registry.ci.openshift.org/origin/release:4.18ocp-release@sha256:0da6316466d60a3a4535d5fed3589feb0391989982fba59d47d4c729912d6363
 release architecture amd64
 ----
 ====
@@ -101,15 +127,41 @@ pullSecret: '<pull_secret>' <6>
 Do not move the `install-config.yaml` or `agent-config.yaml` configuration files to the `openshift` directory.
 ====
 
+ifndef::c3,pca[]
 . If you used a stack to provision OCI infrastructure resources: Copy and paste the `dynamic_custom_manifest` output of the OCI stack into a file titled `manifest.yaml` and save the file in the `openshift` directory.
 
 . If you did not use a stack to provision OCI infrastructure resources: Download and prepare custom manifests to create an Agent ISO image:
 
+
 .. Go to link:https://docs.oracle.com/iaas/Content/openshift-on-oci/install-prereq.htm#install-configuration-files[Configuration Files] (Oracle documentation) and follow the link to the custom manifests directory on GitHub.
 
 .. Copy the contents of the `condensed-manifest.yml` file and save it locally to a file in the `openshift` directory.
 
 .. In the `condensed-manifest.yml` file, update the sections marked with `TODO` to specify the compartment {ocid-first}, VCN {ocid}, subnet {ocid} from the load balancer, and the security lists {ocid}.
+endif::c3,pca[]
+
+ifdef::c3[]
+. Configure the Oracle custom manifest files.
+
+.. Go to "Prepare the OpenShift Master Images" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer] (Oracle documentation).
+
+.. Copy and paste the `oci-ccm.yml`, `oci-csi.yml`, and `machineconfig-ccm.yml` files into your `openshift` directory.
+
+.. Edit the `oci-ccm.yml` and `oci-csi.yml` files to specify the compartment {ocid-first}, VCN {ocid}, subnet {ocid} from the load balancer, the security lists {ocid}, and the `c3-cert.pem` section.
+endif::c3[]
+
+ifdef::pca[]
+. Configure the Oracle custom manifest files.
+
+.. Go to "Prepare the OpenShift Master Images" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance] (Oracle documentation).
+
+.. Copy and paste the `oci-ccm.yml`, `oci-csi.yml`, and `machineconfig-ccm.yml` files into your `openshift` directory.
+
+.. Edit the `oci-ccm.yml` and `oci-csi.yml` files to specify the compartment {ocid-first}, VCN {ocid}, subnet {ocid} from the load balancer, the security lists {ocid}, and the `c3-cert.pem` section.
+endif::pca[]
 
 . Configure the `agent-config.yaml` configuration file to meet your organization's requirements.
 +
@@ -164,3 +216,11 @@ The Agent-based Installer also adds the value of the `bootArtifactsBaseURL` to t
 ====
 Consider that the full ISO image, which is in excess of `1` GB, includes the rootfs image. The image is larger than the minimal ISO Image, which is typically less than `150` MB.
 ====
+
+ifeval::["{context}" == "installing-c3-agent-based-installer"]
+:!c3:
+endif::[]
+
+ifeval::["{context}" == "installing-pca-agent-based-installer"]
+:!pca:
+endif::[]
\ No newline at end of file
diff --git a/modules/creating-machines-bare-metal.adoc b/modules/creating-machines-bare-metal.adoc
index 5003efb554e4..a0ed776c6129 100644
--- a/modules/creating-machines-bare-metal.adoc
+++ b/modules/creating-machines-bare-metal.adoc
@@ -26,7 +26,4 @@ You can configure {op-system} during ISO and PXE installations by using the foll
 
 Whether to use an ISO or PXE install depends on your situation. A PXE install requires an available DHCP service and more preparation, but can make the installation process more automated. An ISO install is a more manual process and can be inconvenient if you are setting up more than a few machines.
 
-[NOTE]
-====
-As of {product-title} 4.6, the {op-system} ISO and other installation artifacts provide support for installation on disks with 4K sectors.
-====
+
diff --git a/modules/creating-manifest-file-customized-br-ex-bridge.adoc b/modules/creating-manifest-file-customized-br-ex-bridge.adoc
index 603e9c5d01d2..6b8eae334994 100644
--- a/modules/creating-manifest-file-customized-br-ex-bridge.adoc
+++ b/modules/creating-manifest-file-customized-br-ex-bridge.adoc
@@ -17,20 +17,14 @@ endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="creating-manifest-file-customized-br-ex-bridge_{context}"]
-== Creating a manifest object that includes a customized `br-ex` bridge
+= Creating a manifest object that includes a customized `br-ex` bridge
 
 ifndef::postinstall-bare-metal-ipi,postinstall-bare-metal-upi[]
-As an alternative to using the `configure-ovs.sh` shell script to set a customized `br-ex` bridge on a bare-metal platform, you can create a `MachineConfig` object that includes a customized `br-ex` bridge network configuration.
-
-:FeatureName: Creating a `MachineConfig` object that includes a customized `br-ex` bridge
-include::snippets/technology-preview.adoc[]
+As an alternative to using the `configure-ovs.sh` shell script to set a `br-ex` bridge on a bare-metal platform, you can create a `MachineConfig` object that includes an NMState configuration file. The NMState configuration file creates a customized `br-ex` bridge network configuration on each node in your cluster.
 endif::postinstall-bare-metal-ipi,postinstall-bare-metal-upi[]
 
 ifdef::postinstall-bare-metal-ipi,postinstall-bare-metal-upi[]
-As an alternative to using the `configure-ovs.sh` shell script to set a customized `br-ex` bridge on a bare-metal platform, you can create a `NodeNetworkConfigurationPolicy` custom resource (CR) that includes a customized `br-ex` bridge network configuration.
-
-:FeatureName: Creating a `NodeNetworkConfigurationPolicy` CR that includes a customized `br-ex` bridge
-include::snippets/technology-preview.adoc[]
+As an alternative to using the `configure-ovs.sh` shell script to set a `br-ex` bridge on a bare-metal platform, you can create a `NodeNetworkConfigurationPolicy` custom resource (CR) that includes an NMState configuration file. The NMState configuration file creates a customized `br-ex` bridge network configuration on each node in your cluster.
 
 This feature supports the following tasks:
 
diff --git a/modules/creating-pull-secrets.adoc b/modules/creating-pull-secrets.adoc
new file mode 100644
index 000000000000..b7c0e0fe77d5
--- /dev/null
+++ b/modules/creating-pull-secrets.adoc
@@ -0,0 +1,40 @@
+// Module included in the following assemblies:
+// * openshift_images/using-image-pull-secrets
+// * openshift_images/managing-image-streams.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="creating-pull-secret_{context}"]
+= Creating a pull secret
+
+.Procedure
+
+* Create a secret from an existing authentication file:
+
+** For Docker clients using `.docker/config.json`, enter the following command:
++
+[source,terminal]
+----
+$ oc create secret generic <pull_secret_name> \
+    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
+    --type=kubernetes.io/dockerconfigjson
+----
+
+** For Podman clients using `.config/containers/auth.json`, enter the following command:
++
+[source,terminal]
+----
+$ oc create secret generic <pull_secret_name> \
+     --from-file=<path/to/.config/containers/auth.json> \
+     --type=kubernetes.io/podmanconfigjson
+----
+
+* If you do not already have a Docker credentials file for the secured registry, you can create a secret by running the following command:
++
+[source,terminal]
+----
+$ oc create secret docker-registry <pull_secret_name> \
+    --docker-server=<registry_server> \
+    --docker-username=<user_name> \
+    --docker-password=<password> \
+    --docker-email=<email>
+----
\ No newline at end of file
diff --git a/modules/creating-the-data-protection-application.adoc b/modules/creating-the-data-protection-application.adoc
new file mode 100644
index 000000000000..f9c353576f7a
--- /dev/null
+++ b/modules/creating-the-data-protection-application.adoc
@@ -0,0 +1,65 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="creating-the-data-protection-application_{context}"]
+= Creating the Data Protection Application
+
+You can create a Data Protection Application (DPA) custom resource (CR) for 3scale. For more information on DPA, see "Installing the Data Protection Application".
+
+.Procedure
+
+. Create a YAML file with the following configuration:
++
+.Example `dpa.yaml` file
++
+[source,yaml]
+----
+apiVersion: oadp.openshift.io/v1alpha1
+kind: DataProtectionApplication
+metadata:
+  name: dpa_sample
+  namespace: openshift-adp 
+spec:
+  configuration:
+    velero:
+      defaultPlugins:
+        - openshift 
+        - aws
+        - csi
+      resourceTimeout: 10m 
+    nodeAgent: 
+      enable: true 
+      uploaderType: kopia 
+  backupLocations:
+    - name: default
+      velero:
+        provider: aws
+        default: true
+        objectStorage:
+          bucket: <bucket_name> <1>
+          prefix: <prefix> <2>
+        config:
+          region: <region> <3>
+          profile: "default"
+          s3ForcePathStyle: "true" 
+          s3Url: <s3_url> <4>
+        credential:
+          key: cloud
+          name: cloud-credentials
+----
+<1> Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
+<2> Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
+<3> Specify a region for backup storage location.
+<4> Specify the URL of the object store that you are using to store backups. 
+
+. Create the DPA CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f dpa.yaml
+----
+
+.Next steps
+
+* Back up the 3scale Operator.
\ No newline at end of file
diff --git a/modules/csp-overview.adoc b/modules/csp-overview.adoc
new file mode 100644
index 000000000000..1282dfe2b8be
--- /dev/null
+++ b/modules/csp-overview.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+//
+// * web_console/dynamic-plugin/content-security-policy.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="content-security-policy-overview_{context}"]
+= Content Security Policy (CSP) overview
+
+A Content Security Policy (CSP) is delivered to the browser in the `Content-Security-Policy-Report-Only` response header. The policy is specified as a series of directives and values. Each directive type serves a different purpose, and each directive can have a list of values representing allowed sources.
+
+[id="content-security-policy-key-features_{context}"]
+== Key features of `contentSecurityPolicy`
+
+[discrete]
+=== Directive Types
+
+The supported directive types include `DefaultSrc`, `ScriptSrc`, `StyleSrc`, `ImgSrc`, and `FontSrc`. These directives allow you to specify valid sources for loading different types of content for your plugin. Each directive type serves a different purpose. For example, `ScriptSrc` defines valid JavaScript sources, while `ImgSrc` controls where images can be loaded from.
+
+//backporting the ConnectSrc directive, but that is tbd - openshift/console#14701 and https://github.com/openshift/api/pull/2164
+
+
+[discrete]
+=== Values
+
+Each directive can have a list of values representing allowed sources. For example, `ScriptSrc` can specify multiple external scripts. These values are restricted to 1024 characters and cannot include whitespace, commas, or semicolons. Additionally, single-quoted strings and wildcard characters (`*`) are disallowed.
+
+[discrete]
+=== Unified Policy
+
+The {product-title} web console aggregates the CSP directives across all enabled `ConsolePlugin` custom resources (CRs) and merges them with its own default policy. The combined policy is then applied with the `Content-Security-Policy-Report-Only` HTTP response header.
+
+[discrete]
+=== Validation Rules
+* Each directive can have up to 16 unique values.
+* The total size of all values across directives must not exceed 8192 bytes (8KB).
+* Each value must be unique, and additional validation rules are in place to ensure no quotes, spaces, commas, or wildcard symbols are used.
\ No newline at end of file
diff --git a/modules/cudn-status-conditions.adoc b/modules/cudn-status-conditions.adoc
new file mode 100644
index 000000000000..943840f36b4b
--- /dev/null
+++ b/modules/cudn-status-conditions.adoc
@@ -0,0 +1,82 @@
+//module included in the following assembly:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="cudn-status-conditions_{context}"]
+= User-defined network status condition types
+
+The following tables explain the status condition types returned for `ClusterUserDefinedNetwork` and `UserDefinedNetwork` CRs when describing the resource. These conditions can be used to troubleshoot your deployment.
+
+.NetworkCreated condition types (`ClusterDefinedNetwork` and `UserDefinedNetwork` CRs)
+[cols="2a,2a,3a,6a",options="header"]
+|===
+
+|Condition type
+|Status
+2+|Reason and Message
+
+.3+|`NetworkCreated`
+.3+| `True`
+2+|When `True`, the following reason and message is returned:
+h|Reason
+h|Message
+
+|`NetworkAttachmentDefinitionCreated`
+|'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]'`
+
+.9+|`NetworkCreated`
+.9+| `False`
+2+|When `False`, one of the following messages is returned:
+h|Reason
+h|Message
+
+|`SyncError`
+|`failed to generate NetworkAttachmentDefinition`
+
+|`SyncError`
+|`failed to update NetworkAttachmentDefinition`
+
+|`SyncError`
+|`primary network already exist in namespace "<namespace_name>": "<primary_network_name>"`
+
+|`SyncError`
+|`failed to create NetworkAttachmentDefinition: create NAD error`
+
+|`SyncError`
+|`foreign NetworkAttachmentDefinition with the desired name already exist`
+
+|`SyncError`
+|`failed to add finalizer to UserDefinedNetwork`
+
+|`NetworkAttachmentDefinitionDeleted`
+|`NetworkAttachmentDefinition is being deleted: [<namespace>/<nad_name>]`
+|===
+
+.NetworkAllocationSucceeded condition types (`UserDefinedNetwork` CRs)
+[cols="2a,2a,3a,6a",options="header"]
+|===
+
+|Condition type
+|Status
+2+|Reason and Message
+
+.3+|`NetworkAllocationSucceeded`
+.3+| `True`
+2+|When `True`, the following reason and message is returned:
+h|Reason
+h|Message
+
+|`NetworkAllocationSucceeded`
+|`Network allocation succeeded for all synced nodes.`
+
+.3+|`NetworkAllocationSucceeded`
+.3+| `False`
+2+|When `False`, the following message is returned:
+h|Reason
+h|Message
+
+|`InternalError`
+|`Network allocation failed for at least one node: [<node_name>], check UDN events for more info.`
+
+|===
diff --git a/modules/customize-certificates-api-add-named.adoc b/modules/customize-certificates-api-add-named.adoc
index 3984d11e721d..53e5e4f6dc44 100644
--- a/modules/customize-certificates-api-add-named.adoc
+++ b/modules/customize-certificates-api-add-named.adoc
@@ -69,7 +69,7 @@ $ oc patch apiserver cluster \
      [{"names": ["<FQDN>"], //<1>
      "servingCertificate": {"name": "<secret>"}}]}}}' <2>
 ----
-<1> Replace `<FQDN>` with the FQDN that the API server should provide the certificate for.
+<1> Replace `<FQDN>` with the FQDN that the API server should provide the certificate for. Do not include the port number.
 <2> Replace `<secret>` with the name used for the secret in the previous step.
 
 . Examine the `apiserver/cluster` object and confirm the secret is now
diff --git a/modules/customize-certificates-understanding-service-serving.adoc b/modules/customize-certificates-understanding-service-serving.adoc
index df6a2ee63bd3..93529d3c5730 100644
--- a/modules/customize-certificates-understanding-service-serving.adoc
+++ b/modules/customize-certificates-understanding-service-serving.adoc
@@ -32,3 +32,8 @@ $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {en
       done
 ----
 ====
+
+[WARNING]
+====
+After you create the service, if you re-create the service, the secret will no longer have a matching service UID. A mismatched service UID will lead to an automatic certificate renewal failure.
+====
\ No newline at end of file
diff --git a/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc b/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc
index 3da569f90618..cf3373e7fb29 100644
--- a/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc
+++ b/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc
@@ -32,6 +32,7 @@ quick and clear output if a connection can be established:
 
 .. Create a temporary pod using the `busybox` image, which cleans up after itself:
 +
+[source,terminal]
 ----
 $ oc run netcat-test \
     --image=busybox -i -t \
@@ -44,6 +45,7 @@ $ oc run netcat-test \
 --
 * Example successful connection results:
 +
+[source,terminal]
 ----
 / nc -zvv 192.168.1.1 8080
 10.181.3.180 (10.181.3.180:8080) open
@@ -52,6 +54,7 @@ sent 0, rcvd 0
 
 * Example failed connection results:
 +
+[source,terminal]
 ----
 / nc -zvv 192.168.1.2 8080
 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused
@@ -61,6 +64,7 @@ sent 0, rcvd 0
 
 .. Exit the container, which automatically deletes the Pod:
 +
+[source,terminal]
 ----
 / exit
 ----
diff --git a/modules/dedicated-aws-vpn-verifying.adoc b/modules/dedicated-aws-vpn-verifying.adoc
index 0e798d0352ca..06ba4e32d943 100644
--- a/modules/dedicated-aws-vpn-verifying.adoc
+++ b/modules/dedicated-aws-vpn-verifying.adoc
@@ -30,6 +30,7 @@ quick and clear output if a connection can be established:
 
 .. Create a temporary pod using the `busybox` image, which cleans up after itself:
 +
+[source,terminal]
 ----
 $ oc run netcat-test \
     --image=busybox -i -t \
@@ -42,6 +43,7 @@ $ oc run netcat-test \
 --
 * Example successful connection results:
 +
+[source,terminal]
 ----
 / nc -zvv 192.168.1.1 8080
 10.181.3.180 (10.181.3.180:8080) open
@@ -50,6 +52,7 @@ sent 0, rcvd 0
 
 * Example failed connection results:
 +
+[source,terminal]
 ----
 / nc -zvv 192.168.1.2 8080
 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused
@@ -59,6 +62,7 @@ sent 0, rcvd 0
 
 .. Exit the container, which automatically deletes the Pod:
 +
+[source,terminal]
 ----
 / exit
 ----
diff --git a/modules/defer-application-tuning-proc.adoc b/modules/defer-application-tuning-proc.adoc
new file mode 100644
index 000000000000..453710ffd4f7
--- /dev/null
+++ b/modules/defer-application-tuning-proc.adoc
@@ -0,0 +1,221 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/using-node-tuning-operator.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="defer-application-of-tuning-changes-example_{context}"]
+= Deferring application of tuning changes: An example
+
+The following worked example describes how to defer the application of tuning changes by using the Node Tuning Operator.
+
+.Prerequisites
+* You have `cluster-admin` role access.
+* You have applied a performance profile to your cluster.
+* A `MachineConfigPool` resource, for example, `worker-cnf` is configured to ensure that the profile is only applied to the designated nodes.
+
+.Procedure
+
+. Check what profiles are currently applied to your cluster by running the following command: 
++
+[source,shell]
+----
+$ oc -n openshift-cluster-node-tuning-operator get tuned
+----
++
+.Example output
+[source,shell]
+----
+NAME                                     AGE
+default                                  63m
+openshift-node-performance-performance   21m
+----
+
+. Check the machine config pools in your cluster by running the following command:
++
+[source,shell]
+----
+$ oc get mcp
+----
++
+.Example output
+[source,shell]
+----
+NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
+master       rendered-master-79a26af9f78ced61fa8ccd309d3c859c       True      False      False      3              3                   3                     0                      157m
+worker       rendered-worker-d9352e91a1b14de7ef453fa54480ce0e       True      False      False      2              2                   2                     0                      157m
+worker-cnf   rendered-worker-cnf-f398fc4fcb2b20104a51e744b8247272   True      False      False      1              1                   1                     0                      92m
+----
+
+. Describe the current applied performance profile by running the following command:
++
+[source,shell]
+----
+$ oc describe performanceprofile performance | grep Tuned
+----
++
+.Example output
+[source,shell]
+----
+Tuned:                   openshift-cluster-node-tuning-operator/openshift-node-performance-performance
+----
+
+. Verify the existing value of the `kernel.shmmni` sysctl parameter:
+
+.. Run the following command to display the node names:
++
+[source,shell]
+----
+$ oc get nodes 
+----
++
+.Example output
+[source,shell]
+----
+NAME                          STATUS   ROLES                  AGE    VERSION
+ip-10-0-26-151.ec2.internal   Ready    worker,worker-cnf      116m   v1.30.6
+ip-10-0-46-60.ec2.internal    Ready    worker                 115m   v1.30.6
+ip-10-0-52-141.ec2.internal   Ready    control-plane,master   123m   v1.30.6
+ip-10-0-6-97.ec2.internal     Ready    control-plane,master   121m   v1.30.6
+ip-10-0-86-145.ec2.internal   Ready    worker                 117m   v1.30.6
+ip-10-0-92-228.ec2.internal   Ready    control-plane,master   123m   v1.30.6
+----
+
+.. Run the following command to display the current value of the `kernel.shmmni` sysctl parameters on the node `ip-10-0-32-74.ec2.internal`:
++
+[source,shell]
+----
+$ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni
+----
++
+.Example output
+[source,shell]
+----
+kernel.shmmni = 4096
+----
+
+. Create a profile patch, for example, `perf-patch.yaml` that changes the `kernel.shmmni` sysctl parameter to `8192`. Defer the application of the change to a new manual restart by using the `always` method by applying the following configuration:
++
+[source,yaml]
+----
+apiVersion: tuned.openshift.io/v1
+kind: Tuned
+metadata:
+  name: performance-patch
+  namespace: openshift-cluster-node-tuning-operator
+  annotations:
+    tuned.openshift.io/deferred: "always"
+spec:
+  profile:
+    - name: performance-patch
+      data: |
+        [main]
+        summary=Configuration changes profile inherited from performance created tuned
+        include=openshift-node-performance-performance <1>
+        [sysctl]
+        kernel.shmmni=8192 <2> 
+  recommend:
+    - machineConfigLabels:
+        machineconfiguration.openshift.io/role: worker-cnf <3>
+      priority: 19
+      profile: performance-patch
+----
++
+<1> The `include` directive is used to inherit the `openshift-node-performance-performance` profile. This is a best practice to ensure that the profile is not missing any required settings.
+<2> The `kernel.shmmni` sysctl parameter is being changed to `8192`.
+<3> The `machineConfigLabels` field is used to target the `worker-cnf` role.
+
+. Apply the profile patch by running the following command:
++
+[source,shell]
+----
+$ oc apply -f perf-patch.yaml
+----
+
+. Run the following command to verify that the profile patch is waiting for the next node restart:
++
+[source,shell]
+----
+$ oc -n openshift-cluster-node-tuning-operator get profile
+----
++
+.Example output
+[source,shell]
+----
+NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
+ip-10-0-26-151.ec2.internal   performance-patch         False     True       The TuneD daemon profile is waiting for the next node restart: performance-patch   126m
+ip-10-0-46-60.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             125m
+ip-10-0-52-141.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m
+ip-10-0-6-97.ec2.internal     openshift-control-plane   True      False      TuneD profile applied.                                                             130m
+ip-10-0-86-145.ec2.internal   openshift-node            True      False      TuneD profile applied.                                                             126m
+ip-10-0-92-228.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m
+----
+
+. Confirm the value of the `kernel.shmmni` sysctl parameter remain unchanged before a restart:
+
+.. Run the following command to confirm that the application of the `performance-patch` change to the `kernel.shmmni` sysctl parameter on the node `ip-10-0-26-151.ec2.internal` is not applied:
++
+[source,shell]
+----
+$ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni
+----
++
+.Example output
+[source,shell]
+----
+kernel.shmmni = 4096
+----
+
+. Restart the node `ip-10-0-26-151.ec2.internal` to apply the required changes by running the following command:
++
+[source,shell]
+----
+$ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host reboot&
+----
+
+. In another terminal window, run the following command to verify that the node has restarted:
++
+[source,shell]
+----
+$ watch oc get nodes
+----
++
+Wait for the node `ip-10-0-26-151.ec2.internal` to transition back to the `Ready` state.
+
+. Run the following command to verify that the profile patch is waiting for the next node restart:
++
+[source,shell]
+----
+$ oc -n openshift-cluster-node-tuning-operator get profile
+----
++
+.Example output
+[source,shell]
+----
+NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
+ip-10-0-20-251.ec2.internal   performance-patch         True      False      TuneD profile applied.                                                             3h3m
+ip-10-0-30-148.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
+ip-10-0-32-74.ec2.internal    openshift-node            True      True       TuneD profile applied.                                                             179m
+ip-10-0-33-49.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
+ip-10-0-84-72.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
+ip-10-0-93-89.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             179m
+----
+
+. Check that the value of the `kernel.shmmni` sysctl parameter have changed after the restart:
+
+.. Run the following command to verify that the `kernel.shmmni` sysctl parameter change has been applied on the node `ip-10-0-32-74.ec2.internal`:
++
+[source,shell]
+----
+$ oc debug node/ip-10-0-32-74.ec2.internal  -q -- chroot host sysctl kernel.shmmni
+----
++
+.Example output
+[source,shell]
+----
+kernel.shmmni = 8192
+----
+
+[NOTE]
+====
+An additional restart results in the restoration of the original value of the `kernel.shmmni` sysctl parameter.
+====
\ No newline at end of file
diff --git a/modules/defer-applicaton-tuning-example.adoc b/modules/defer-applicaton-tuning-example.adoc
new file mode 100644
index 000000000000..2f7f14ede4dc
--- /dev/null
+++ b/modules/defer-applicaton-tuning-example.adoc
@@ -0,0 +1,58 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/using-node-tuning-operator.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="defer-application-of-tuning-changes_{context}"]
+= Deferring application of tuning changes
+
+As an administrator, use the Node Tuning Operator (NTO) to update custom resources (CRs) on a running system and make tuning changes. For example, they can update or add a sysctl parameter to the [sysctl] section of the tuned object. When administrators apply a tuning change, the NTO prompts TuneD to reprocess all configurations, causing the tuned process to roll back all tuning and then reapply it.
+
+Latency-sensitive applications may not tolerate the removal and reapplication of the tuned profile, as it can briefly disrupt performance. This is particularly critical for configurations that partition CPUs and manage process or interrupt affinity using the performance profile. To avoid this issue, {product-title} introduced new methods for applying tuning changes. Before {product-title} 4.17, the only available method, immediate, applied changes instantly, often triggering a tuned restart.
+
+The following additional methods are supported:
+ 
+ * `always`: Every change is applied at the next node restart.
+ * `update`: When a tuning change modifies a tuned profile, it is applied immediately by default and takes effect as soon as possible. When a tuning change does not cause a tuned profile to change and its values are modified in place, it is treated as always.
+
+Enable this feature by adding the annotation `tuned.openshift.io/deferred`. The following table summarizes the possible values for the annotation:
+
+[cols="3,3",options="header"]
+|===
+|Annotation value | Description 
+|missing          | The change is applied immediately. 
+|always           | The change is applied at the next node restart.
+|update           | The change is applied immediately if it causes a profile change, otherwise at the next node restart. 
+|===
+
+The following example demonstrates how to apply a change to the `kernel.shmmni` sysctl parameter by using the `always` method:
+
+.Example
+[source,yaml]
+----
+apiVersion: tuned.openshift.io/v1
+kind: Tuned
+metadata:
+  name: performance-patch
+  namespace: openshift-cluster-node-tuning-operator
+  annotations:
+    tuned.openshift.io/deferred: "always"
+spec:
+  profile:
+    - name: performance-patch
+      data: |
+        [main]
+        summary=Configuration changes profile inherited from performance created tuned
+        include=openshift-node-performance-performance <1>
+        [sysctl]
+        kernel.shmmni=8192 <2>
+  recommend:
+    - machineConfigLabels:
+        machineconfiguration.openshift.io/role: worker-cnf <3>
+      priority: 19
+      profile: performance-patch
+----
+
+<1> The `include` directive is used to inherit the `openshift-node-performance-performance` profile. This is a best practice to ensure that the profile is not missing any required settings.
+<2> The `kernel.shmmni` sysctl parameter is being changed to `8192`.
+<3> The `machineConfigLabels` field is used to target the `worker-cnf` role. Configure a `MachineConfigPool` resource to ensure the profile is applied only to the correct nodes.
\ No newline at end of file
diff --git a/modules/destroy-hc-ibm-z-cli.adoc b/modules/destroy-hc-ibm-z-cli.adoc
index f29e9deb9351..fedd57ba9a04 100644
--- a/modules/destroy-hc-ibm-z-cli.adoc
+++ b/modules/destroy-hc-ibm-z-cli.adoc
@@ -6,7 +6,7 @@
 [id="destroy-hc-ibmz-cli_{context}"]
 = Destroying a hosted cluster on x86 bare metal with {ibm-z-title} compute nodes
 
-To destroy a hosted cluster and its managed cluster on `x86` bare metal with {ibm-z-title} compute nodes, you can use the command-line interface (CLI).
+To destroy a hosted cluster and its managed cluster on `x86` bare metal with {ibm-z-name} compute nodes, you can use the command-line interface (CLI).
 
 .Procedure
 
@@ -14,7 +14,8 @@ To destroy a hosted cluster and its managed cluster on `x86` bare metal with {ib
 +
 [source,terminal]
 ----
-$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 0
+$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> \
+  --replicas 0
 ----
 +
 After the `NodePool` object is scaled to `0`, the compute nodes are detached from the hosted cluster. In {product-title} version 4.17, this function is applicable only for {ibm-z-title} with KVM. For z/VM and LPAR, you must delete the compute nodes manually.
@@ -26,9 +27,11 @@ If you want to re-attach compute nodes to the cluster, you can scale up the `Nod
 If the compute nodes are not detached from the hosted cluster or are stuck in the `Notready` state, delete the compute nodes manually by running the following command:
 [source,terminal]
 ----
-$ oc --kubeconfig <hosted_cluster_name>.kubeconfig delete node <compute_node_name>
+$ oc --kubeconfig <hosted_cluster_name>.kubeconfig delete \
+  node <compute_node_name>
 ----
 ====
+If you are using an OSA network device in Processor Resource/Systems Manager (PR/SM) mode, auto scaling is not supported. You must delete the old agent manually and scale up the node pool because the new agent joins during the scale down process. 
 
 . Verify the status of the compute nodes by entering the following command:
 +
@@ -55,5 +58,6 @@ You can delete the virtual machines that you created as agents after you delete
 +
 [source,terminal]
 ----
-$ hcp destroy cluster agent --name <hosted_cluster_name> --namespace <hosted_cluster_namespace>
+$ hcp destroy cluster agent --name <hosted_cluster_name> \
+  --namespace <hosted_cluster_namespace>
 ----
diff --git a/modules/distr-tracing-architecture.adoc b/modules/distr-tracing-architecture.adoc
index cefe1d703843..0eb88e1e0b85 100644
--- a/modules/distr-tracing-architecture.adoc
+++ b/modules/distr-tracing-architecture.adoc
@@ -28,8 +28,25 @@
 ** *OpenTelemetry Collector* - The OpenTelemetry Collector is a vendor-agnostic way to receive, process, and export telemetry data. The OpenTelemetry Collector supports open-source observability data formats, for example, Jaeger and Prometheus, sending to one or more open-source or commercial back-ends. The Collector is the default location instrumentation libraries export their telemetry data.
 
 * *{JaegerName}* - This component is based on the open source link:https://www.jaegertracing.io/[Jaeger project].
++
+:FeatureName: The {JaegerName}
+[IMPORTANT]
+====
+[subs="attributes+"]
+{FeatureName} is a deprecated feature. Deprecated functionality is still included in {product-title} and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.
 
-** *Client* (Jaeger client, Tracer, Reporter, instrumented application, client libraries)- The {JaegerShortName} clients are language-specific implementations of the OpenTracing API. They can be used to instrument applications for distributed tracing either manually or with a variety of existing open source frameworks, such as Camel (Fuse), Spring Boot (RHOAR), MicroProfile (RHOAR/Thorntail), Wildfly (EAP), and many more, that are already integrated with OpenTracing.
+The {JaegerOperator} Operator (Jaeger) will be removed from the `redhat-operators` catalog in a future release. For more information, see the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift].
+
+Users must migrate to the {TempoOperator} and the {OTELName} for distributed tracing collection and storage.
+
+ifndef::openshift-rosa,openshift-dedicated[]
+For the most recent list of major functionality that has been deprecated or removed within {product-title}, refer to the _Deprecated and removed features_ section of the {product-title} release notes.
+endif::openshift-rosa,openshift-dedicated[]
+====
+// Undefine {FeatureName} attribute, so that any mistakes are easily spotted
+:!FeatureName:
+
+** *Client* (Jaeger client, Tracer, Reporter, instrumented application, client libraries)- The {JaegerShortName} clients are language-specific implementations of the OpenTracing API. They might be used to instrument applications for distributed tracing either manually or with a variety of existing open source frameworks, such as Camel (Fuse), Spring Boot (RHOAR), MicroProfile (RHOAR/Thorntail), Wildfly (EAP), and many more, that are already integrated with OpenTracing.
 
 ** *Agent* (Jaeger agent, Server Queue, Processor Workers) - The {JaegerShortName} agent is a network daemon that listens for spans sent over User Datagram Protocol (UDP), which it batches and sends to the Collector. The agent is meant to be placed on the same host as the instrumented application. This is typically accomplished by having a sidecar in container environments such as Kubernetes.
 
diff --git a/modules/distr-tracing-config-storage.adoc b/modules/distr-tracing-config-storage.adoc
index ab773101da77..16dd7969421f 100644
--- a/modules/distr-tracing-config-storage.adoc
+++ b/modules/distr-tracing-config-storage.adoc
@@ -645,7 +645,7 @@ spec:
 <3> Secret which defines environment variables ES_PASSWORD and ES_USERNAME. Created by kubectl create secret generic tracing-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic
 <4> Volume mounts and volumes which are mounted into all storage components.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [id="distr-tracing-manage-es-certificates_{context}"]
 = Managing certificates with Elasticsearch
 
@@ -722,4 +722,4 @@ spec:
 The {JaegerName} Operator sets the Elasticsearch custom resource `name` to the value of `spec.storage.elasticsearch.name` from the Jaeger custom resource when provisioning Elasticsearch.
 
 The certificates are provisioned by the {es-op} and the {JaegerName} Operator injects the certificates.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/modules/distr-tracing-tempo-config-spanmetrics.adoc b/modules/distr-tracing-tempo-config-spanmetrics.adoc
index dc43c3a41ffa..48237824660e 100644
--- a/modules/distr-tracing-tempo-config-spanmetrics.adoc
+++ b/modules/distr-tracing-tempo-config-spanmetrics.adoc
@@ -96,11 +96,13 @@ spec:
         monitorTab:
           enabled: true # <1>
           prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 # <2>
+          redMetricsNamespace: "" <3>
         ingress:
           type: route
 ----
 <1> Enables the monitoring tab in the Jaeger console.
 <2> The service name for Thanos Querier from user-workload monitoring.
+<3> Optional: The metrics namespace on which the Jaeger query retrieves the Prometheus metrics. Include this line only if you are using an OpenTelemetry Collector version earlier than 0.109.0. If you are using an OpenTelemetry Collector version 0.109.0 or later, omit this line.
 
 [id="distr-tracing-tempo-config-spanmetrics_span-red-metrics-and-alerting-rules_{context}"]
 == Span RED metrics and alerting rules
diff --git a/modules/distr-tracing-tempo-object-storage-setup-ibm-storage.adoc b/modules/distr-tracing-tempo-object-storage-setup-ibm-storage.adoc
new file mode 100644
index 000000000000..bda371e42a77
--- /dev/null
+++ b/modules/distr-tracing-tempo-object-storage-setup-ibm-storage.adoc
@@ -0,0 +1,77 @@
+// Module included in the following assemblies:
+//
+//* observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="distr-tracing-tempo-object-storage-setup-ibm-storage_{context}"]
+= Setting up {ibm-cloud-title} Object Storage
+
+You can set up {ibm-cloud-title} Object Storage by using the {oc-first}.
+
+.Prerequisites
+
+* You have installed the latest version of {oc-first}. For more information, see "Getting started with the OpenShift CLI" in _Configure: CLI tools_.
+
+* You have installed the latest version of {ibm-cloud-title} Command Line Interface (`ibmcloud`). For more information, see "Getting started with the {ibm-cloud-title} CLI" in _{ibm-cloud-title} Docs_.
+
+* You have configured {ibm-cloud-title} Object Storage. For more information, see "Choosing a plan and creating an instance" in _{ibm-cloud-title} Docs_.
+
+** You have an {ibm-cloud-title} Platform account.
+** You have ordered an {ibm-cloud-title} Object Storage plan.
+** You have created an instance of {ibm-cloud-title} Object Storage.
+
+.Procedure
+
+. On {ibm-cloud-title}, create an object store bucket.
+
+. On {ibm-cloud-title}, create a service key for connecting to the object store bucket by running the following command:
++
+[source,terminal]
+----
+$ ibmcloud resource service-key-create <tempo_bucket> Writer \
+--instance-name <tempo_bucket> --parameters '{"HMAC":true}'
+----
+
+. On {ibm-cloud-title}, create a secret with the bucket credentials by running the following command:
++
+[source,terminal]
+----
+$ oc -n <namespace> create secret generic <ibm_cos_secret> \
+  --from-literal=bucket="<tempo_bucket>" \
+  --from-literal=endpoint="<ibm_bucket_endpoint>" \
+  --from-literal=access_key_id="<ibm_bucket_access_key>" \
+  --from-literal=access_key_secret="<ibm_bucket_secret_key>"
+----
+
+. On {product-title}, create an object storage secret with keys as follows:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Secret
+metadata:
+  name: <ibm_cos_secret>
+stringData:
+  bucket: <tempo_bucket>
+  endpoint: <ibm_bucket_endpoint>
+  access_key_id: <ibm_bucket_access_key>
+  access_key_secret: <ibm_bucket_secret_key>
+type: Opaque
+----
+
+. On {product-title}, set the storage section in the `TempoStack` custom resource as follows:
++
+[source,yaml]
+----
+apiVersion: tempo.grafana.com/v1alpha1
+kind: TempoStack
+# ...
+spec:
+# ...
+  storage:
+    secret:
+      name: <ibm_cos_secret> # <1>
+      type: s3
+# ...
+----
+<1> Name of the secret that contains the {ibm-cloud-title} Storage access and secret keys.
diff --git a/modules/dr-hosted-cluster-within-aws-region-backup.adoc b/modules/dr-hosted-cluster-within-aws-region-backup.adoc
index 16dba002e195..eb07655a8ec0 100644
--- a/modules/dr-hosted-cluster-within-aws-region-backup.adoc
+++ b/modules/dr-hosted-cluster-within-aws-region-backup.adoc
@@ -14,7 +14,8 @@ To recover your hosted cluster in your target management cluster, you first need
 +
 [source,terminal]
 ----
-$ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}
+$ oc create configmap mgmt-parent-cluster -n default \
+  --from-literal=from=${MGMT_CLUSTER_NAME}
 ----
 
 . Shut down the reconciliation in the hosted cluster and in the node pools by entering these commands:
@@ -22,16 +23,21 @@ $ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_
 [source,terminal]
 ----
 $ PAUSED_UNTIL="true"
-$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
-$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
+$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} \
+  -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
+$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 \
+  kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
 ----
 +
 [source,terminal]
 ----
 $ PAUSED_UNTIL="true"
-$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
-$ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
-$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
+$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} \
+  -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
+$ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} \
+  -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
+$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 \
+  kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
 ----
 
 . Back up etcd and upload the data to an S3 bucket by running this bash script:
@@ -89,7 +95,8 @@ For more information about backing up etcd, see "Backing up and restoring etcd o
 +
 [source,terminal]
 ----
-$ mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
+$ mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} \
+  ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
 $ chmod 700 ${BACKUP_DIR}/namespaces/
 
 # HostedCluster
diff --git a/modules/dr-restoring-cluster-state-about.adoc b/modules/dr-restoring-cluster-state-about.adoc
index dc29df659949..0390ba4c3f41 100644
--- a/modules/dr-restoring-cluster-state-about.adoc
+++ b/modules/dr-restoring-cluster-state-about.adoc
@@ -18,7 +18,7 @@ Restoring to a previous cluster state is a destructive and destablizing action t
 If you are able to retrieve data using the Kubernetes API server, then etcd is available and you should not restore using an etcd backup.
 ====
 
-Restoring etcd effectively takes a cluster back in time and all clients will experience a conflicting, parallel history. This can impact the behavior of watching components like kubelets, Kubernetes controller managers, persistent volume controllers, and OpenShift operators, including the network operator.
+Restoring etcd effectively takes a cluster back in time and all clients will experience a conflicting, parallel history. This can impact the behavior of watching components like kubelets, Kubernetes controller managers, persistent volume controllers, and {product-title} Operators, including the network Operator.
 
 It can cause Operator churn when the content in etcd does not match the actual content on disk, causing Operators for the Kubernetes API server, Kubernetes controller manager, Kubernetes scheduler, and etcd to get stuck when files on disk conflict with content in etcd. This can require manual actions to resolve the issues.
 
diff --git a/modules/dr-restoring-cluster-state-sno.adoc b/modules/dr-restoring-cluster-state-sno.adoc
new file mode 100644
index 000000000000..ad348c9010c1
--- /dev/null
+++ b/modules/dr-restoring-cluster-state-sno.adoc
@@ -0,0 +1,50 @@
+// Module included in the following assemblies:
+//
+// * disaster_recovery/scenario-2-restoring-cluster-state.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="dr-restoring-cluster-state-sno_{context}"]
+= Restoring to a previous cluster state for a single node
+
+You can use a saved etcd backup to restore a previous cluster state on a single node.
+
+[IMPORTANT]
+====
+When you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} {product-version}.2 cluster must use an etcd backup that was taken from {product-version}.2.
+====
+
+.Prerequisites
+
+* Access to the cluster as a user with the `cluster-admin` role through a certificate-based `kubeconfig` file, like the one that was used during installation.
+* You have SSH access to control plane hosts.
+* A backup directory containing both the etcd snapshot and the resources for the static pods, which were from the same backup. The file names in the directory must be in the following formats: `snapshot_<datetimestamp>.db` and `static_kuberesources_<datetimestamp>.tar.gz`.
+
+.Procedure
+
+. Use SSH to connect to the single node and copy the etcd backup to the `/home/core` directory by running the following command:
++
+[source,terminal]
+----
+$ cp <etcd_backup_directory> /home/core
+----
+
+. Run the following command in the single node to restore the cluster from a previous backup:
++
+[source,terminal]
+----
+$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd_backup_directory>
+----
+
+. Exit the SSH session.
+
+. Monitor the recovery progress of the control plane by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-stable-cluster
+----
++
+[NOTE]
+====
+It can take up to 15 minutes for the control plane to recover.
+====
\ No newline at end of file
diff --git a/modules/dr-restoring-cluster-state.adoc b/modules/dr-restoring-cluster-state.adoc
index 226d74e14234..96ec782f3f69 100644
--- a/modules/dr-restoring-cluster-state.adoc
+++ b/modules/dr-restoring-cluster-state.adoc
@@ -3,6 +3,8 @@
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
 // * post_installation_configuration/cluster-tasks.adoc
 
+// Contributors: The documentation for this section changed drastically for 4.18+.
+
 // Contributors: Some changes for the `etcd` restore procedure are only valid for 4.14+. 
 // In the 4.14+ documentation, OVN-K requires different steps because there is no centralized OVN 
 // control plane to be converted. For more information, see PR #64939. 
@@ -14,23 +16,25 @@
 [id="dr-scenario-2-restoring-cluster-state_{context}"]
 = Restoring to a previous cluster state
 
-You can use a saved `etcd` backup to restore a previous cluster state or restore a cluster that has lost the majority of control plane hosts.
+You can use a saved etcd backup to restore a previous cluster state or restore a cluster that has lost the majority of control plane hosts.
+
+For high availability (HA) clusters, a three-node HA cluster requires you to shutdown etcd on two hosts to avoid a cluster split. Quorum requires a simple majority of nodes. The minimum number of nodes required for quorum on a three-node HA cluster is two. If you start a new cluster from backup on your recovery host, the other etcd members might still be able to form quorum and continue service.
 
 [NOTE]
 ====
-If your cluster uses a control plane machine set, see "Troubleshooting the control plane machine set" for a more simple `etcd` recovery procedure.
+If your cluster uses a control plane machine set, see "Troubleshooting the control plane machine set" for a more simple etcd recovery procedure. For {product-title} on a single node, see "Restoring to a previous cluster state for a single node".
 ====
 
 [IMPORTANT]
 ====
-When you restore your cluster, you must use an `etcd` backup that was taken from the same z-stream release. For example, an {product-title} 4.7.2 cluster must use an `etcd` backup that was taken from 4.7.2.
+When you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} {product-version}.2 cluster must use an etcd backup that was taken from {product-version}.2.
 ====
 
 .Prerequisites
 
 * Access to the cluster as a user with the `cluster-admin` role through a certificate-based `kubeconfig` file, like the one that was used during installation.
 * A healthy control plane host to use as the recovery host.
-* SSH access to control plane hosts.
+* You have SSH access to control plane hosts.
 * A backup directory containing both the `etcd` snapshot and the resources for the static pods, which were from the same backup. The file names in the directory must be in the following formats: `snapshot_<datetimestamp>.db` and `static_kuberesources_<datetimestamp>.tar.gz`.
 
 [IMPORTANT]
@@ -40,7 +44,7 @@ For non-recovery control plane nodes, it is not required to establish SSH connec
 
 .Procedure
 
-. Select a control plane host to use as the recovery host. This is the host that you will run the restore operation on.
+. Select a control plane host to use as the recovery host. This is the host that you run the restore operation on.
 
 . Establish SSH connectivity to each of the control plane nodes, including the recovery host.
 +
@@ -51,641 +55,57 @@ For non-recovery control plane nodes, it is not required to establish SSH connec
 If you do not complete this step, you will not be able to access the control plane hosts to complete the restore procedure, and you will be unable to recover your cluster from this state.
 ====
 
-. Copy the `etcd` backup directory to the recovery control plane host.
-+
-This procedure assumes that you copied the `backup` directory containing the `etcd` snapshot and the resources for the static pods to the `/home/core/` directory of your recovery control plane host.
-
-. Stop the static pods on any other control plane nodes.
-+
-[NOTE]
-====
-You do not need to stop the static pods on the recovery host.
-====
-
-.. Access a control plane host that is not the recovery host.
-
-.. Move the existing etcd pod file out of the kubelet manifest directory by running:
-+
-[source,terminal]
-----
-$ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp
-----
-
-.. Verify that the `etcd` pods are stopped by using:
-+
-[source,terminal]
-----
-$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
-----
-+
-If the output of this command is not empty, wait a few minutes and check again.
-
-.. Move the existing `kube-apiserver` file out of the kubelet manifest directory by running:
-+
-[source,terminal]
-----
-$ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
-----
-
-.. Verify that the `kube-apiserver` containers are stopped by running:
-+
-[source,terminal]
-----
-$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
-----
-+
-If the output of this command is not empty, wait a few minutes and check again.
-
-.. Move the existing `kube-controller-manager` file out of the kubelet manifest directory by using:
-+
-[source,terminal]
-----
-$ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
-----
-
-.. Verify that the `kube-controller-manager` containers are stopped by running:
-+
-[source,terminal]
-----
-$ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
-----
-If the output of this command is not empty, wait a few minutes and check again.
-
-.. Move the existing `kube-scheduler` file out of the kubelet manifest directory by using:
-+
-[source,terminal]
-----
-$ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
-----
-
-.. Verify that the `kube-scheduler` containers are stopped by using:
-+
-[source,terminal]
-----
-$ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
----- 
-If the output of this command is not empty, wait a few minutes and check again.
-
-.. Move the `etcd` data directory to a different location with the following example:
-+
-[source,terminal]
-----
-$ sudo mv -v /var/lib/etcd/ /tmp
-----
-
-.. If the `/etc/kubernetes/manifests/keepalived.yaml` file exists and the node is deleted, follow these steps:
-
-... Move the `/etc/kubernetes/manifests/keepalived.yaml` file out of the kubelet manifest directory:
-+
-[source,terminal]
-----
-$ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
-----
-
-... Verify that any containers managed by the `keepalived` daemon are stopped:
-+
-[source,terminal]
-----
-$ sudo crictl ps --name keepalived
-----
-+
-The output of this command should be empty. If it is not empty, wait a few minutes and check again.
-
-... Check if the control plane has any Virtual IPs (VIPs) assigned to it:
-+
-[source,terminal]
-----
-$ ip -o address | egrep '<api_vip>|<ingress_vip>'
-----
-
-... For each reported VIP, run the following command to remove it:
-+
-[source,terminal]
-----
-$ sudo ip address del <reported_vip> dev <reported_vip_device>
-----
-
-.. Repeat this step on each of the other control plane hosts that is not the recovery host.
-
-. Access the recovery control plane host.
-
-. If the `keepalived` daemon is in use, verify that the recovery control plane node owns the VIP:
-+
-[source,terminal]
-----
-$ ip -o address | grep <api_vip>
-----
-+
-The address of the VIP is highlighted in the output if it exists. This command returns an empty string if the VIP is not set or configured incorrectly.
-
-. If the cluster-wide proxy is enabled, be sure that you have exported the `NO_PROXY`, `HTTP_PROXY`, and `HTTPS_PROXY` environment variables.
-+
-[TIP]
-====
-You can check whether the proxy is enabled by reviewing the output of `oc get proxy cluster -o yaml`. The proxy is enabled if the `httpProxy`, `httpsProxy`, and `noProxy` fields have values set.
-====
-
-. Run the restore script on the recovery control plane host and pass in the path to the `etcd` backup directory:
-+
-[source,terminal]
-----
-$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup
-----
-+
-.Example script output
-[source,terminal]
-----
-...stopping kube-scheduler-pod.yaml
-...stopping kube-controller-manager-pod.yaml
-...stopping etcd-pod.yaml
-...stopping kube-apiserver-pod.yaml
-Waiting for container etcd to stop
-.complete
-Waiting for container etcdctl to stop
-.............................complete
-Waiting for container etcd-metrics to stop
-complete
-Waiting for container kube-controller-manager to stop
-complete
-Waiting for container kube-apiserver to stop
-..........................................................................................complete
-Waiting for container kube-scheduler to stop
-complete
-Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
-starting restore-etcd static pod
-starting kube-apiserver-pod.yaml
-static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
-starting kube-controller-manager-pod.yaml
-static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
-starting kube-scheduler-pod.yaml
-static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml
-----
-+
-
-The cluster-restore.sh script must show that `etcd`, `kube-apiserver`, `kube-controller-manager`, and `kube-scheduler` pods are stopped and then started at the end of the restore process.
-+
-[NOTE]
-====
-The restore process can cause nodes to enter the `NotReady` state if the node certificates were updated after the last `etcd` backup.
-====
-
-. Check the nodes to ensure they are in the `Ready` state.
-.. Run the following command:
-+
-[source,terminal]
-----
-$ oc get nodes -w
-----
-+
-.Sample output
-[source,terminal]
-----
-NAME                STATUS  ROLES          AGE     VERSION
-host-172-25-75-28   Ready   master         3d20h   v1.31.3
-host-172-25-75-38   Ready   infra,worker   3d20h   v1.31.3
-host-172-25-75-40   Ready   master         3d20h   v1.31.3
-host-172-25-75-65   Ready   master         3d20h   v1.31.3
-host-172-25-75-74   Ready   infra,worker   3d20h   v1.31.3
-host-172-25-75-79   Ready   worker         3d20h   v1.31.3
-host-172-25-75-86   Ready   worker         3d20h   v1.31.3
-host-172-25-75-98   Ready   infra,worker   3d20h   v1.31.3
-----
-+
-It can take several minutes for all nodes to report their state.
-
-.. If any nodes are in the `NotReady` state, log in to the nodes and remove all of the PEM files from the `/var/lib/kubelet/pki` directory on each node. You can SSH into the nodes or use the terminal window in the web console.
-+
-[source,terminal]
-----
-$  ssh -i <ssh-key-path> core@<master-hostname>
-----
-+
-.Sample `pki` directory
-[source,terminal]
-----
-sh-4.4# pwd
-/var/lib/kubelet/pki
-sh-4.4# ls
-kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
-kubelet-client-current.pem              kubelet-server-current.pem
-----
-
-. Restart the kubelet service on all control plane hosts.
-
-.. From the recovery host, run:
-+
-[source,terminal]
-----
-$ sudo systemctl restart kubelet.service
-----
-
-.. Repeat this step on all other control plane hosts.
-
-. Approve the pending Certificate Signing Requests (CSRs):
-+
-[NOTE]
-====
-Clusters with no worker nodes, such as single-node clusters or clusters consisting of three schedulable control plane nodes, will not have any pending CSRs to approve. You can skip all the commands listed in this step.
-====
-
-.. Get the list of current CSRs by running:
-+
-[source,terminal]
-----
-$ oc get csr
-----
-+
-.Example output
-----
-NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
-csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending <1>
-csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending <1>
-csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending <2>
-csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending <2>
-...
-----
-<1> A pending kubelet serving CSR, requested by the node for the kubelet serving endpoint.
-<2> A pending kubelet client CSR, requested with the `node-bootstrapper` node bootstrap credentials.
-
-.. Review the details of a CSR to verify that it is valid by running:
-+
-[source,terminal]
-----
-$ oc describe csr <csr_name> <1>
-----
-<1> `<csr_name>` is the name of a CSR from the list of current CSRs.
-
-.. Approve each valid `node-bootstrapper` CSR by running:
-+
-[source,terminal]
-----
-$ oc adm certificate approve <csr_name>
-----
-
-.. For user-provisioned installations, approve each valid kubelet service CSR by running:
-+
-[source,terminal]
-----
-$ oc adm certificate approve <csr_name>
-----
-
-. Verify that the single member control plane has started successfully.
-
-.. From the recovery host, verify that the `etcd` container is running by using:
-+
-[source,terminal]
-----
-$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
-----
-+
-.Example output
-[source,terminal]
-----
-3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
-----
-
-.. From the recovery host, verify that the `etcd` pod is running by using:
-+
-[source,terminal]
-----
-$ oc -n openshift-etcd get pods -l k8s-app=etcd
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                             READY   STATUS      RESTARTS   AGE
-etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
-----
-+
-If the status is `Pending`, or the output lists more than one running `etcd` pod, wait a few minutes and check again.
-
-. If you are using the `OVNKubernetes` network plugin, you must restart `ovnkube-controlplane` pods.
-.. Delete all of the `ovnkube-controlplane` pods by running:
+. Using SSH, connect to each control plane node and run the following command to disable etcd:
 +
 [source,terminal]
 ----
-$ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
-----
-.. Verify that all of the `ovnkube-controlplane` pods were redeployed by using:
-+
-[source,terminal]
-----
-$ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
+$ sudo -E /usr/local/bin/disable-etcd.sh
 ----
 
-. If you are using the OVN-Kubernetes network plugin, restart the Open Virtual Network (OVN) Kubernetes pods on all the nodes one by one. Use the following steps to restart OVN-Kubernetes pods on each node:
-+
-[IMPORTANT]
-====
-.Restart OVN-Kubernetes pods in the following order
-. The recovery control plane host
-. The other control plane hosts (if available)
-. The other nodes
-====
+. Copy the etcd backup directory to the recovery control plane host.
 +
-[NOTE]
-====
-Validating and mutating admission webhooks can reject pods. If you add any additional webhooks with the `failurePolicy` set to `Fail`, then they can reject pods and the restoration process can fail. You can avoid this by saving and deleting webhooks while restoring the cluster state. After the cluster state is restored successfully, you can enable the webhooks again.
+This procedure assumes that you copied the `backup` directory containing the etcd snapshot and the resources for the static pods to the `/home/core/` directory of your recovery control plane host.
 
-Alternatively, you can temporarily set the `failurePolicy` to `Ignore` while restoring the cluster state. After the cluster state is restored successfully, you can set the `failurePolicy` to `Fail`.
-====
-
-.. Remove the northbound database (nbdb) and southbound database (sbdb). Access the recovery host and the remaining control plane nodes by using Secure Shell (SSH) and run:
+. Use SSH to connect to the recovery host and restore the cluster from a previous backup by running the following command:
 +
 [source,terminal]
 ----
-$ sudo rm -f /var/lib/ovn-ic/etc/*.db
+$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
 ----
 
-.. Restart the OpenVSwitch services. Access the node by using Secure Shell (SSH) and run the following command:
-+
-[source,terminal]
-----
-$ sudo systemctl restart ovs-vswitchd ovsdb-server
-----
+. Exit the SSH session.
 
-.. Delete the `ovnkube-node` pod on the node by running the following command, replacing `<node>` with the name of the node that you are restarting:
+. Once the API responds, turn off the etcd Operator quorum guard by runnning the following command:
 +
 [source,terminal]
 ----
-$ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
+$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
 ----
-+
 
-.. Verify that the `ovnkube-node` pod is running again with:
+. Monitor the recovery progress of the control plane by running the following command:
 +
 [source,terminal]
 ----
-$ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
+$ oc adm wait-for-stable-cluster
 ----
 +
 [NOTE]
 ====
-It might take several minutes for the pods to restart.
-====
-
-. Delete and re-create other non-recovery, control plane machines, one by one. After the machines are re-created, a new revision is forced and `etcd` automatically scales up.
-+
-** If you use a user-provisioned bare metal installation, you can re-create a control plane machine by using the same method that you used to originally create it. For more information, see "Installing a user-provisioned cluster on bare metal".
-+
-[WARNING]
-====
-Do not delete and re-create the machine for the recovery host.
-====
-+
-** If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps:
-+
-[WARNING]
-====
-Do not delete and re-create the machine for the recovery host.
-
-For bare metal installations on installer-provisioned infrastructure, control plane machines are not re-created. For more information, see "Replacing a bare-metal control plane node".
+It can take up to 15 minutes for the control plane to recover.
 ====
-.. Obtain the machine for one of the lost control plane hosts.
-+
-In a terminal that has access to the cluster as a cluster-admin user, run the following command:
-+
-[source,terminal]
-----
-$ oc get machines -n openshift-machine-api -o wide
-----
-+
-Example output:
-+
-[source,terminal]
-----
-NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
-clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped <1>
-clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
-clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
-clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
-clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
-clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
-----
-<1> This is the control plane machine for the lost control plane host, `ip-10-0-131-183.ec2.internal`.
-
-.. Delete the machine of the lost control plane host by running:
-+
-[source,terminal]
-----
-$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 <1>
-----
-<1> Specify the name of the control plane machine for the lost control plane host.
-+
-A new machine is automatically provisioned after deleting the machine of the lost control plane host.
-
-.. Verify that a new machine has been created by running:
-+
-[source,terminal]
-----
-$ oc get machines -n openshift-machine-api -o wide
-----
-+
-Example output:
-+
-[source,terminal]
-----
-NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
-clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
-clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
-clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running <1>
-clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
-clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
-clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
-----
-<1> The new machine, `clustername-8qw5l-master-3` is being created and is ready after the phase changes from `Provisioning` to `Running`.
-+
-It might take a few minutes for the new machine to be created. The `etcd` cluster Operator will automatically sync when the machine or node returns to a healthy state.
-
-.. Repeat these steps for each lost control plane host that is not the recovery host.
-
-. Turn off the quorum guard by entering:
-+
-[source,terminal]
-----
-$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
-----
-+
-This command ensures that you can successfully re-create secrets and roll out the static pods.
-
-. In a separate terminal window within the recovery host, export the recovery `kubeconfig` file by running:
-+
-[source,terminal]
-----
-$ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
-----
-
-. Force `etcd` redeployment.
-+
-In the same terminal window where you exported the recovery `kubeconfig` file, run:
-+
-[source,terminal]
-----
-$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge <1>
-----
-<1> The `forceRedeploymentReason` value must be unique, which is why a timestamp is appended.
-+
-The `etcd` redeployment starts.
-+
-When the `etcd` cluster Operator performs a redeployment, the existing nodes are started with new pods similar to the initial bootstrap scale up.
 
-. Turn the quorum guard back on by entering:
+. Once recovered, enable the quorum guard by running the following command:
 +
 [source,terminal]
 ----
 $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
 ----
 
-. You can verify that the `unsupportedConfigOverrides` section is removed from the object by running:
-+
-[source,terminal]
-----
-$ oc get etcd/cluster -oyaml
-----
+.Troubleshooting
 
-. Verify all nodes are updated to the latest revision.
-+
-In a terminal that has access to the cluster as a `cluster-admin` user, run:
-+
-[source,terminal]
-----
-$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
-----
-+
-Review the `NodeInstallerProgressing` status condition for `etcd` to verify that all nodes are at the latest revision. The output shows `AllNodesAtLatestRevision` upon successful update:
-+
-[source,terminal]
-----
-AllNodesAtLatestRevision
-3 nodes are at revision 7 <1>
-----
-<1> In this example, the latest revision number is `7`.
-+
-If the output includes multiple revision numbers, such as `2 nodes are at revision 6; 1 nodes are at revision 7`, this means that the update is still in progress. Wait a few minutes and try again.
-
-. After `etcd` is redeployed, force new rollouts for the control plane. `kube-apiserver` will reinstall itself on the other nodes because the kubelet is connected to API servers using an internal load balancer.
-+
-In a terminal that has access to the cluster as a `cluster-admin` user, run:
-
-.. Force a new rollout for `kube-apiserver`:
-+
-[source,terminal]
-----
-$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
-----
-+
-Verify all nodes are updated to the latest revision.
-+
-[source,terminal]
-----
-$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
-----
-+
-Review the `NodeInstallerProgressing` status condition to verify that all nodes are at the latest revision. The output shows `AllNodesAtLatestRevision` upon successful update:
-+
-[source,terminal]
-----
-AllNodesAtLatestRevision
-3 nodes are at revision 7 <1>
-----
-<1> In this example, the latest revision number is `7`.
-+
-If the output includes multiple revision numbers, such as `2 nodes are at revision 6; 1 nodes are at revision 7`, this means that the update is still in progress. Wait a few minutes and try again.
-
-.. Force a new rollout for the Kubernetes controller manager by running the following command:
-+
-[source,terminal]
-----
-$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
-----
-+
-Verify all nodes are updated to the latest revision by running:
-+
-[source,terminal]
-----
-$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
-----
-+
-Review the `NodeInstallerProgressing` status condition to verify that all nodes are at the latest revision. The output shows `AllNodesAtLatestRevision` upon successful update:
-+
-[source,terminal]
-----
-AllNodesAtLatestRevision
-3 nodes are at revision 7 <1>
-----
-<1> In this example, the latest revision number is `7`.
-+
-If the output includes multiple revision numbers, such as `2 nodes are at revision 6; 1 nodes are at revision 7`, this means that the update is still in progress. Wait a few minutes and try again.
+If you see no progress rolling out the etcd static pods, you can force redeployment from the `cluster-etcd-operator` by running the following command:
 
-.. Force a new rollout for the `kube-scheduler` by running:
-+
 [source,terminal]
 ----
-$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
-----
-+
-Verify all nodes are updated to the latest revision by using:
-+
-[source,terminal]
-----
-$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
-----
-+
-Review the `NodeInstallerProgressing` status condition to verify that all nodes are at the latest revision. The output shows `AllNodesAtLatestRevision` upon successful update:
-+
-[source,terminal]
-----
-AllNodesAtLatestRevision
-3 nodes are at revision 7 <1>
-----
-<1> In this example, the latest revision number is `7`.
-+
-If the output includes multiple revision numbers, such as `2 nodes are at revision 6; 1 nodes are at revision 7`, this means that the update is still in progress. Wait a few minutes and try again.
-
-. Monitor the platform Operators by running:
-+
-[source,terminal]
-----
-$ oc adm wait-for-stable-cluster
-----
-+
-This process can take up to 15 minutes.
-
-. Verify that all control plane hosts have started and joined the cluster.
-+
-In a terminal that has access to the cluster as a `cluster-admin` user, run the following command:
-+
-[source,terminal]
-----
-$ oc -n openshift-etcd get pods -l k8s-app=etcd
-----
-+
-.Example output
-[source,terminal]
-----
-etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
-etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
-etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h
-----
-
-To ensure that all workloads return to normal operation following a recovery procedure, restart all control plane nodes.
-
-[NOTE]
-====
-On completion of the previous procedural steps, you might need to wait a few minutes for all services to return to their restored state. For example, authentication by using `oc login` might not immediately work until the OAuth server pods are restarted.
-
-Consider using the `system:admin` `kubeconfig` file for immediate authentication. This method basis its authentication on SSL/TLS client certificates as against OAuth tokens. You can authenticate with this file by issuing the following command:
-
-[source,terminal]
-----
-$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
-----
-
-Issue the following command to display your authenticated user name:
-
-[source,terminal]
-----
-$ oc whoami
-----
-====
+$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
+----
\ No newline at end of file
diff --git a/modules/dr-restoring-etcd-quorum-ha.adoc b/modules/dr-restoring-etcd-quorum-ha.adoc
new file mode 100644
index 000000000000..bdac16b83917
--- /dev/null
+++ b/modules/dr-restoring-etcd-quorum-ha.adoc
@@ -0,0 +1,158 @@
+// Module included in the following assemblies:
+//
+// * disaster_recovery/quorum-restoration.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="dr-restoring-etcd-quorum-ha_{context}"]
+= Restoring etcd quorum for high availability clusters
+
+You can use the `quorum-restore.sh` script to instantly bring back a new single-member etcd cluster based on its local data directory and mark all other members as invalid by retiring the previous cluster identifier. No prior backup is required to restore the control plane from.
+
+[WARNING]
+====
+You might experience data loss if the host that runs the restoration does not have all data replicated to it.
+====
+
+[IMPORTANT]
+====
+Quorum restoration should not be used to decrease the number of nodes outside of the restoration process. Decreasing the number of nodes results in an unsupported cluster configuration.
+====
+
+.Prerequisites
+
+* You have SSH access to the node used to restore quorum.
+
+.Procedure
+
+. Select a control plane host to use as the recovery host. You run the restore operation on this host.
+
+.. List the running etcd pods by running the following command:
++
+[source,terminal]
+----
+$ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"
+----
+
+.. Choose a pod and run the following command to obtain its IP address:
++
+[source,terminal]
+----
+$ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table
+----
++
+Note the IP address of a member that is not a learner and has the highest Raft index.
+
+.. Run the following command and note the node name that corresponds to the IP address of the chosen etcd member:
++
+[source,terminal]
+----
+$ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'
+----
+
+. Using SSH, connect to the chosen recovery node and run the following command to restore etcd quorum:
++
+[source,terminal]
+----
+$ sudo -E /usr/local/bin/quorum-restore.sh
+----
++
+After a few minutes, the nodes that went down are automatically synchronized with the node that the recovery script was run on. Any remaining online nodes automatically rejoin the new etcd cluster created by the `quorum-restore.sh` script. This process takes a few minutes.
+
+. Exit the SSH session.
+
+. Return to a three-node configuration if any nodes are offline. Repeat the following steps for each node that is offline to delete and re-create them. After the machines are re-created, a new revision is forced and etcd automatically scales up.
++
+** If you use a user-provisioned bare-metal installation, you can re-create a control plane machine by using the same method that you used to originally create it. For more information, see "Installing a user-provisioned cluster on bare metal".
++
+[WARNING]
+====
+Do not delete and re-create the machine for the recovery host.
+====
++
+** If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps:
++
+[WARNING]
+====
+Do not delete and re-create the machine for the recovery host.
+
+For bare-metal installations on installer-provisioned infrastructure, control plane machines are not re-created. For more information, see "Replacing a bare-metal control plane node".
+====
+
+.. Obtain the machine for one of the offline nodes.
++
+In a terminal that has access to the cluster as a `cluster-admin` user, run the following command:
++
+[source,terminal]
+----
+$ oc get machines -n openshift-machine-api -o wide
+----
++
+.Example output:
++
+[source,terminal]
+----
+NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
+clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped <1>
+clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
+clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
+clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
+clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
+clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
+----
+<1> This is the control plane machine for the offline node, `ip-10-0-131-183.ec2.internal`.
+
+.. Delete the machine of the offline node by running:
++
+[source,terminal]
+----
+$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 <1>
+----
+<1> Specify the name of the control plane machine for the offline node.
++
+A new machine is automatically provisioned after deleting the machine of the offline node.
+
+. Verify that a new machine has been created by running:
++
+[source,terminal]
+----
+$ oc get machines -n openshift-machine-api -o wide
+----
++
+.Example output:
++
+[source,terminal]
+----
+NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
+clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
+clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
+clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running <1>
+clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
+clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
+clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
+----
+<1> The new machine, `clustername-8qw5l-master-3` is being created and is ready after the phase changes from `Provisioning` to `Running`.
++
+It might take a few minutes for the new machine to be created. The etcd cluster Operator will automatically synchronize when the machine or node returns to a healthy state.
+
+.. Repeat these steps for each node that is offline.
+
+. Wait until the control plane recovers by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-stable-cluster
+----
++
+[NOTE]
+====
+It can take up to 15 minutes for the control plane to recover.
+====
+
+.Troubleshooting
+
+* If you see no progress rolling out the etcd static pods, you can force redeployment from the etcd cluster Operator by running the following command:
++
+[source,terminal]
+----
+$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
+----
\ No newline at end of file
diff --git a/modules/dr-testing-restore-procedures.adoc b/modules/dr-testing-restore-procedures.adoc
new file mode 100644
index 000000000000..c93a101acebc
--- /dev/null
+++ b/modules/dr-testing-restore-procedures.adoc
@@ -0,0 +1,78 @@
+// Module included in the following assemblies:
+//
+// * disaster_recovery/about-disaster-recovery.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="dr-testing-restore-procedures_{context}"]
+= Testing restore procedures
+
+Testing the restore procedure is important to ensure that your automation and workload handle the new cluster state gracefully. Due to the complex nature of etcd quorum and the etcd Operator attempting to mend automatically, it is often difficult to correctly bring your cluster into a broken enough state that it can be restored.
+
+[WARNING]
+====
+You **must** have SSH access to the cluster. Your cluster might be entirely lost without SSH access.
+====
+
+.Prerequisites
+
+* You have SSH access to control plane hosts.
+* You have installed the {oc-first}.
+
+.Procedure
+
+. Use SSH to connect to each of your nonrecovery nodes and run the following commands to disable etcd and the `kubelet` service:
+
+.. Disable etcd by running the following command:
++
+[source,terminal]
+----
+$ sudo /usr/local/bin/disable-etcd.sh
+----
+
+.. Delete variable data for etcd by running the following command:
++
+[source,terminal]
+----
+$ sudo rm -rf /var/lib/etcd
+----
+
+.. Disable the `kubelet` service by running the following command:
++
+[source,terminal]
+----
+$ sudo systemctl disable kubelet.service
+----
+
+. Exit every SSH session.
+
+. Run the following command to ensure that your nonrecovery nodes are in a `NOT READY` state:
++
+[source,terminal]
+----
+$ oc get nodes
+----
+
+. Follow the steps in "Restoring to a previous cluster state" to restore your cluster.
+
+. After you restore the cluster and the API responds, use SSH to connect to each nonrecovery node and enable the `kubelet` service:
++
+[source,terminal]
+----
+$ sudo systemctl enable kubelet.service
+----
+
+. Exit every SSH session.
+
+. Run the following command to observe your nodes coming back into the `READY` state:
++
+[source,terminal]
+----
+$ oc get nodes
+----
+
+. Run the following command to verify that etcd is available:
++
+[source,terminal]
+----
+$ oc get pods -n openshift-etcd
+----
\ No newline at end of file
diff --git a/modules/dynamic-plugin-sdk-extensions.adoc b/modules/dynamic-plugin-sdk-extensions.adoc
index 6bbe4c890181..12f42efd6f01 100644
--- a/modules/dynamic-plugin-sdk-extensions.adoc
+++ b/modules/dynamic-plugin-sdk-extensions.adoc
@@ -269,6 +269,17 @@ Adds a new React context provider to the web console application root.
 |`useValueHook` |`CodeRef<() => T>` |no |Hook for the Context value.
 |===
 
+[discrete]
+== `console.create-project-modal`
+
+This extension can be used to pass a component that will be rendered in place of the standard create project modal.
+
+[cols=",,,",options="header",]
+|===
+|Name |Value Type |Optional |Description
+|`component` |`CodeRef<ModalComponent<CreateProjectModalProps>>` |no |A component to render in place of the create project modal.
+|===
+
 [discrete]
 == `console.dashboards/card`
 
diff --git a/modules/dynamic-provisioning-gce-definition.adoc b/modules/dynamic-provisioning-gce-definition.adoc
index 24b866333322..d8038be4992f 100644
--- a/modules/dynamic-provisioning-gce-definition.adoc
+++ b/modules/dynamic-provisioning-gce-definition.adoc
@@ -14,11 +14,11 @@ metadata:
   name: <storage-class-name> <1>
 provisioner: kubernetes.io/gce-pd
 parameters:
-  type: pd-standard <2>
+  type: pd-ssd <2>
   replication-type: none
 volumeBindingMode: WaitForFirstConsumer
 allowVolumeExpansion: true
 reclaimPolicy: Delete
 ----
 <1> Name of the storage class. The persistent volume claim uses this storage class for provisioning the associated persistent volumes.
-<2> Select either `pd-standard` or `pd-ssd`. The default is `pd-standard`.
+<2> Select `pd-ssd`, `pd-standard`, or `hyperdisk-balanced`. The default is `pd-ssd`.
diff --git a/modules/ephemeral-storage-csi-inline-overview-admin-plugin.adoc b/modules/ephemeral-storage-csi-inline-overview-admin-plugin.adoc
index 755ae1cee9d8..7c58bc37b5ad 100644
--- a/modules/ephemeral-storage-csi-inline-overview-admin-plugin.adoc
+++ b/modules/ephemeral-storage-csi-inline-overview-admin-plugin.adoc
@@ -110,8 +110,6 @@ If the referenced CSI driver for a CSI ephemeral volume does not have the `csi-e
 
 The CSI drivers that ship with {product-title} and support ephemeral volumes have a reasonable default set for the `csi-ephemeral-volume-profile` label:
 
-* Shared Resource CSI driver: restricted
-
 * Azure File CSI driver: privileged
 
 An admin can change the default value of the label if desired.
\ No newline at end of file
diff --git a/modules/ephemeral-storage-csi-inline-overview.adoc b/modules/ephemeral-storage-csi-inline-overview.adoc
index 33f80c4b73e9..05590386d307 100644
--- a/modules/ephemeral-storage-csi-inline-overview.adoc
+++ b/modules/ephemeral-storage-csi-inline-overview.adoc
@@ -14,16 +14,12 @@ This feature allows you to specify CSI volumes directly in the `Pod` specificati
 
 [IMPORTANT]
 ====
-The Shared Resource CSI Driver feature is now generally available in link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.1[{builds-v2title} 1.1]. This feature is now deprecated in {product-title}. To use this feature, ensure you are using {builds-v2title} 1.1 or a more recent version.
+The Shared Resource CSI Driver feature is now generally available in link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.1[{builds-v2title} 1.1]. This feature is now removed in {product-title} 4.18 and later. To use this feature, ensure that you are using {builds-v2title} 1.1 or later.
 ====
 
 By default, {product-title} supports CSI inline ephemeral volumes with these limitations:
 
 * Support is only available for CSI drivers. In-tree and FlexVolumes are not supported.
-* The Shared Resource CSI Driver supports using inline ephemeral volumes only to access `Secrets` or `ConfigMaps` across multiple namespaces as a Technology Preview feature in {product-title}.
 * Community or storage vendors provide other CSI drivers that support these volumes. Follow the installation instructions provided by the CSI driver provider.
 
 CSI drivers might not have implemented the inline volume functionality, including `Ephemeral` capacity. For details, see the CSI driver documentation.
-
-:FeatureName: Shared Resource CSI Driver
-include::snippets/technology-preview.adoc[leveloffset=+0]
diff --git a/modules/example-policy-objects.adoc b/modules/example-policy-objects.adoc
new file mode 100644
index 000000000000..502f6d80ae1d
--- /dev/null
+++ b/modules/example-policy-objects.adoc
@@ -0,0 +1,61 @@
+// Module included in the following assemblies:
+//
+// * networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="example-policy-objects_{context}"]
+= Example policy objects
+
+The examples in this section show different `spec.externalIP.policy` configurations. 
+
+- In the following example, the policy prevents {product-title} from creating any service with a specified external IP address.
++
+.Example policy to reject any value specified for `Service` object `spec.externalIPs[]`
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Network
+metadata:
+  name: cluster
+spec:
+  externalIP:
+    policy: {}
+# ...
+----
+
+- In the following example, both the `allowedCIDRs` and `rejectedCIDRs` fields are set.
++
+.Example policy that includes both allowed and rejected CIDR blocks
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Network
+metadata:
+  name: cluster
+spec:
+  externalIP:
+    policy:
+      allowedCIDRs:
+      - 172.16.66.10/23
+      rejectedCIDRs:
+      - 172.16.66.10/24
+# ...
+----
+
+- In the following example, `policy` is set to `{}`. With this configuration, using the `oc get networks.config.openshift.io -o yaml` command to view the configuration means `policy` parameter does not show on the command output. The same behavior exists for `policy: null`.
++
+.Example policy to allow any value specified for `Service` object `spec.externalIPs[]`
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Network
+metadata:
+  name: cluster
+spec:
+  clusterNetwork:
+  - cidr: 10.128.0.0/14
+    hostPrefix: 23
+  externalIP:
+    policy: {}
+# ...
+----
diff --git a/modules/gathering-data-specific-features.adoc b/modules/gathering-data-specific-features.adoc
index feb0e99f780a..a12afab83f7b 100644
--- a/modules/gathering-data-specific-features.adoc
+++ b/modules/gathering-data-specific-features.adoc
@@ -48,9 +48,6 @@ endif::openshift-rosa,openshift-dedicated[]
 |`quay.io/netobserv/must-gather`
 |Data collection for the Network Observability Operator.
 
-|`registry.redhat.io/openshift4/ose-csi-driver-shared-resource-mustgather-rhel8`
-|Data collection for OpenShift Shared Resource CSI Driver.
-
 ifndef::openshift-rosa,openshift-dedicated[]
 |`registry.redhat.io/openshift4/ose-local-storage-mustgather-rhel9:v<installed_version_LSO>`
 |Data collection for Local Storage Operator.
@@ -71,14 +68,14 @@ endif::openshift-rosa,openshift-dedicated[]
 |`registry.redhat.io/openshift-gitops-1/must-gather-rhel8:v<installed_version_GitOps>`
 |Data collection for {gitops-title}.
 
-|`registry.redhat.io/openshift4/ose-secrets-store-csi-mustgather-rhel8:v<installed_version_secret_store>`
+|`registry.redhat.io/openshift4/ose-secrets-store-csi-mustgather-rhel9:v<installed_version_secret_store>`
 |Data collection for the {secrets-store-operator}.
 
 ifndef::openshift-rosa,openshift-dedicated[]
 |`registry.redhat.io/lvms4/lvms-must-gather-rhel9:v<installed_version_LVMS>`
 |Data collection for the LVM Operator.
 
-|`ghcr.io/complianceascode/must-gather-ocp`
+|`registry.redhat.io/compliance/openshift-compliance-must-gather-rhel8:<digest-version>`
 |Data collection for the Compliance Operator.
 endif::openshift-rosa,openshift-dedicated[]
 
diff --git a/modules/gathering-operator-logs.adoc b/modules/gathering-operator-logs.adoc
index 9ef14db7ec63..5a8799280c89 100644
--- a/modules/gathering-operator-logs.adoc
+++ b/modules/gathering-operator-logs.adoc
@@ -10,12 +10,12 @@ If you experience Operator issues, you can gather detailed diagnostic informatio
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 * You have the fully qualified domain names of the control plane or control plane machines.
@@ -42,7 +42,7 @@ If an Operator pod has multiple containers, the preceding command will produce a
 ----
 $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
 ----
-
+ifndef::openshift-rosa-hcp[]
 . If the API is not functional, review Operator pod and container logs on each control plane node by using SSH instead. Replace `<master-node>.<cluster_name>.<base_domain>` with appropriate values.
 .. List pods on each control plane node:
 +
@@ -83,3 +83,4 @@ $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <conta
 ====
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes by using SSH is not recommended. Before attempting to collect diagnostic data over SSH, review whether the data collected by running `oc adm must gather` and other `oc` commands is sufficient instead. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>`.
 ====
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/modules/getting-started-cli-creating-secret.adoc b/modules/getting-started-cli-creating-secret.adoc
index a8660cc3a6cf..6b6e27c0c7a5 100644
--- a/modules/getting-started-cli-creating-secret.adoc
+++ b/modules/getting-started-cli-creating-secret.adoc
@@ -72,6 +72,5 @@ $ oc rollout status deployment mongodb-nationalparks
 +
 [source,terminal]
 ----
-deployment "nationalparks" successfully rolled out
 deployment "mongodb-nationalparks" successfully rolled out
 ----
diff --git a/modules/graceful-restart.adoc b/modules/graceful-restart.adoc
index f8e24dc3c9d3..c441432763ed 100644
--- a/modules/graceful-restart.adoc
+++ b/modules/graceful-restart.adoc
@@ -105,12 +105,11 @@ $ oc describe csr <csr_name> <1>
 $ oc adm certificate approve <csr_name>
 ----
 
-. After the control plane and worker nodes are ready, mark all the nodes in the cluster as schedulable.
-Run the following command:
+. After the control plane and compute nodes are ready, mark all the nodes in the cluster as schedulable by running the following command:
 +
 [source,terminal]
 ----
-for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
+$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
 ----
 
 . Verify that the cluster started properly.
diff --git a/modules/graceful-shutdown.adoc b/modules/graceful-shutdown.adoc
index 6c9b85449726..5cd7eafff67f 100644
--- a/modules/graceful-shutdown.adoc
+++ b/modules/graceful-shutdown.adoc
@@ -17,6 +17,7 @@ You can shut down a cluster until a year from the installation date and expect i
 
 * You have access to the cluster as a user with the `cluster-admin` role.
 * You have taken an etcd backup.
+* If you are running a {sno} cluster, you must evacuate all workload pods off of the cluster before you shut it down.
 
 .Procedure
 
@@ -77,7 +78,7 @@ Ensure that the control plane node with the API VIP assigned is the last node pr
 $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done <1>
 ----
 +
-<1> `-h 1` indicates how long, in minutes, this process lasts before the control plane nodes are shut down. For large-scale clusters with 10 nodes or more, set to `-h 10` or longer to make sure all the compute nodes have time to shut down first. 
+<1> `-h 1` indicates how long, in minutes, this process lasts before the control plane nodes are shut down. For large-scale clusters with 10 nodes or more, set to `-h 10` or longer to make sure all the compute nodes have time to shut down first.
 +
 .Example output
 [source,terminal]
diff --git a/modules/hcp-access-hc-aws-hcpcli.adoc b/modules/hcp-access-hc-aws-hcpcli.adoc
index 0dd555a40e2e..6a6d00d903a9 100644
--- a/modules/hcp-access-hc-aws-hcpcli.adoc
+++ b/modules/hcp-access-hc-aws-hcpcli.adoc
@@ -14,7 +14,8 @@ You can access the hosted cluster by using the `hcp` command-line interface (CLI
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
+  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After you save the `kubeconfig` file, you can access the hosted cluster by entering the following command:
diff --git a/modules/hcp-access-priv-mgmt-aws.adoc b/modules/hcp-access-priv-mgmt-aws.adoc
index 9bbbc7ca3205..ed3599cbbaf2 100644
--- a/modules/hcp-access-priv-mgmt-aws.adoc
+++ b/modules/hcp-access-priv-mgmt-aws.adoc
@@ -14,7 +14,10 @@ You can access your private management cluster by using the command-line interfa
 +
 [source,terminal]
 ----
-$ aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'
+$ aws ec2 describe-instances \
+  --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" \
+  | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") \
+  | .PrivateIpAddress'
 ----
 
 . Create a `kubeconfig` file for the hosted cluster that you can copy to a node by entering the following command:
@@ -28,7 +31,8 @@ $ hcp create kubeconfig > <hosted_cluster_kubeconfig>
 +
 [source,terminal]
 ----
-$ ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> -W %h:%p" core@<node_ip>
+$ ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> \
+  -W %h:%p" core@<node_ip>
 ----
 
 . From the SSH shell, copy the `kubeconfig` file contents to a file on the node by entering the following command:
diff --git a/modules/hcp-access-pub-hc-aws-cli.adoc b/modules/hcp-access-pub-hc-aws-cli.adoc
index f5a0157b3fc3..2bb04a7decd9 100644
--- a/modules/hcp-access-pub-hc-aws-cli.adoc
+++ b/modules/hcp-access-pub-hc-aws-cli.adoc
@@ -14,7 +14,8 @@ You can access the hosted cluster by using the `hcp` command-line interface (CLI
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
+  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After you save the `kubeconfig` file, access the hosted cluster by entering the following command:
diff --git a/modules/hcp-aws-create-dns-hosted-zone.adoc b/modules/hcp-aws-create-dns-hosted-zone.adoc
index 8cdb4cc27741..115bfd435a92 100644
--- a/modules/hcp-aws-create-dns-hosted-zone.adoc
+++ b/modules/hcp-aws-create-dns-hosted-zone.adoc
@@ -39,7 +39,9 @@ $ dig +short test.user-dest-public.aws.kerberos.com
 +
 [source,terminal]
 ----
-$ hcp create cluster aws --name=<hosted_cluster_name> --endpoint-access=PublicAndPrivate --external-dns-domain=<public_hosted_zone> ... <1>
+$ hcp create cluster aws --name=<hosted_cluster_name> \
+  --endpoint-access=PublicAndPrivate \
+  --external-dns-domain=<public_hosted_zone> ... <1>
 ----
 +
 <1> Replace `<public_hosted_zone>` with the public hosted zone that you created.
@@ -77,7 +79,7 @@ You can configure service-level DNS indirection for public services only. You ca
 The following table shows when it is valid to set `hostname` for a service and endpoint combinations:
 
 .Service and endpoint combinations to set `hostname`
-[cols="4,4",options="header"]
+[cols="4,1,1,1",options="header"]
 |===
 |Service |Public |PublicAndPrivate |Private
 
diff --git a/modules/hcp-aws-create-public-zone.adoc b/modules/hcp-aws-create-public-zone.adoc
index 597632b2d145..ed605f9953da 100644
--- a/modules/hcp-aws-create-public-zone.adoc
+++ b/modules/hcp-aws-create-public-zone.adoc
@@ -14,7 +14,9 @@ To access applications in your hosted clusters, you must configure the routable
 +
 [source,terminal]
 ----
-$ aws route53 create-hosted-zone --name <basedomain> --caller-reference $(whoami)-$(date --rfc-3339=date) <1>
+$ aws route53 create-hosted-zone \
+  --name <basedomain> \// <1>
+  --caller-reference $(whoami)-$(date --rfc-3339=date)
 ----
 +
 <1> Replace `<basedomain>` with your base domain, for example, `www.example.com`.
diff --git a/modules/hcp-aws-create-role-sts-creds.adoc b/modules/hcp-aws-create-role-sts-creds.adoc
index bee86cfeee94..80ba6b814db0 100644
--- a/modules/hcp-aws-create-role-sts-creds.adoc
+++ b/modules/hcp-aws-create-role-sts-creds.adoc
@@ -49,9 +49,9 @@ Use this output as the value for `<arn>` in the next step.
 [source,terminal]
 ----
 $ aws iam create-role \
---role-name <name> \// <1>
---assume-role-policy-document file://<file_name>.json \// <2>
---query "Role.Arn"
+  --role-name <name> \// <1>
+  --assume-role-policy-document file://<file_name>.json \// <2>
+  --query "Role.Arn"
 ----
 <1> Replace `<name>` with the role name, for example, `hcp-cli-role`.
 <2> Replace `<file_name>` with the name of the JSON file you created in the previous step.
@@ -221,11 +221,11 @@ $ aws sts get-session-token --output json > sts-creds.json
 [source,json]
 ----
 {
-              "Credentials": {
-                  "AccessKeyId": "ASIA1443CE0GN2ATHWJU",
-                  "SecretAccessKey": "XFLN7cZ5AP0d66KhyI4gd8Mu0UCQEDN9cfelW1”,
-                  "SessionToken": "IQoJb3JpZ2luX2VjEEAaCXVzLWVhc3QtMiJHMEUCIDyipkM7oPKBHiGeI0pMnXst1gDLfs/TvfskXseKCbshAiEAnl1l/Html7Iq9AEIqf////KQburfkq4A3TuppHMr/9j1TgCj1z83SO261bHqlJUazKoy7vBFR/a6LHt55iMBqtKPEsIWjBgj/jSdRJI3j4Gyk1//luKDytcfF/tb9YrxDTPLrACS1lqAxSIFZ82I/jDhbDs=",
-                  "Expiration": "2025-05-16T04:19:32+00:00"
-              }
-          }
-----
+    "Credentials": {
+        "AccessKeyId": "<access_key_id",
+        "SecretAccessKey": "<secret_access_key>”,
+        "SessionToken": "<session_token>",
+        "Expiration": "<time_stamp>"
+    }
+}
+----
\ No newline at end of file
diff --git a/modules/hcp-aws-create-secret-s3.adoc b/modules/hcp-aws-create-secret-s3.adoc
index 5a07e15fe08a..ef062a731764 100644
--- a/modules/hcp-aws-create-secret-s3.adoc
+++ b/modules/hcp-aws-create-secret-s3.adoc
@@ -48,7 +48,8 @@ $ echo '{
 +
 [source,terminal]
 ----
-$ aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json <1>
+$ aws s3api put-bucket-policy --bucket <bucket_name> \// <1>
+  --policy file://policy.json
 ----
 +
 <1> Replace `<bucket_name>` with the name of the S3 bucket you are creating.
@@ -83,7 +84,11 @@ If you are using a Mac computer, you must export the bucket name in order for th
 +
 [source,terminal]
 ----
-$ oc create secret generic <secret_name> --from-file=credentials=<path>/.aws/credentials --from-literal=bucket=<s3_bucket> --from-literal=region=<region> -n local-cluster
+$ oc create secret generic <secret_name> \
+  --from-file=credentials=<path>/.aws/credentials \
+  --from-literal=bucket=<s3_bucket> \
+  --from-literal=region=<region> \
+  -n local-cluster
 ----
 +
 [NOTE]
@@ -91,6 +96,7 @@ $ oc create secret generic <secret_name> --from-file=credentials=<path>/.aws/cre
 Disaster recovery backup for the secret is not automatically enabled. To add the label that enables the `hypershift-operator-oidc-provider-s3-credentials` secret to be backed up for disaster recovery, run the following command:
 [source,terminal]
 ----
-$ oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
+$ oc label secret hypershift-operator-oidc-provider-s3-credentials \
+  -n local-cluster cluster.open-cluster-management.io/backup=true
 ----
 ====
\ No newline at end of file
diff --git a/modules/hcp-aws-enable-private-link.adoc b/modules/hcp-aws-enable-private-link.adoc
index ec18ebfd2e81..d01d6f706d16 100644
--- a/modules/hcp-aws-enable-private-link.adoc
+++ b/modules/hcp-aws-enable-private-link.adoc
@@ -36,7 +36,10 @@ To create an {aws-short} secret, run the following command:
 
 [source,terminal]
 ----
-$ oc create secret generic <secret_name> --from-literal=aws-access-key-id=<aws_access_key_id> --from-literal=aws-secret-access-key=<aws_secret_access_key> --from-literal=region=<region> -n local-cluster
+$ oc create secret generic <secret_name> \
+  --from-literal=aws-access-key-id=<aws_access_key_id> \
+  --from-literal=aws-secret-access-key=<aws_secret_access_key> \
+  --from-literal=region=<region> -n local-cluster
 ----
 
 [NOTE]
@@ -44,6 +47,8 @@ $ oc create secret generic <secret_name> --from-literal=aws-access-key-id=<aws_a
 Disaster recovery backup for the secret is not automatically enabled. Run the following command to add the label that enables the `hypershift-operator-private-link-credentials` secret to be backed up for disaster recovery:
 [source,terminal]
 ----
-$ oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
+$ oc label secret hypershift-operator-private-link-credentials \
+  -n local-cluster \
+  cluster.open-cluster-management.io/backup=""
 ----
 ====
diff --git a/modules/hcp-aws-hc-ext-dns.adoc b/modules/hcp-aws-hc-ext-dns.adoc
index 58e5c7e5b7a1..fb7185bad3a2 100644
--- a/modules/hcp-aws-hc-ext-dns.adoc
+++ b/modules/hcp-aws-hc-ext-dns.adoc
@@ -64,7 +64,7 @@ $ hcp create cluster aws \
 <5> Specify the public hosted zone that the service consumer owns, for example, `service-consumer-domain.com`.
 <6> Specify the node replica count, for example, `2`.
 <7> Specify the path to your pull secret file.
-<8> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`.
+<8> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`.
 <9> Specify the public hosted zone that the service provider owns, for example, `service-provider-domain.com`.
 <10> Set as `PublicAndPrivate`. You can use external DNS with `Public` or `PublicAndPrivate` configurations only.
 <11> Specify the path to your {aws-short} STS credentials file, for example, `/home/user/sts-creds/sts-creds.json`.
\ No newline at end of file
diff --git a/modules/hcp-aws-set-up-ext-dns.adoc b/modules/hcp-aws-set-up-ext-dns.adoc
index 03fa7aa072bc..3eb707b34e74 100644
--- a/modules/hcp-aws-set-up-ext-dns.adoc
+++ b/modules/hcp-aws-set-up-ext-dns.adoc
@@ -43,7 +43,10 @@ You can provision {hcp} with external DNS or service-level DNS.
 +
 [source,terminal]
 ----
-$ oc create secret generic <secret_name> --from-literal=provider=aws --from-literal=domain-filter=<domain_name> --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster
+$ oc create secret generic <secret_name> \
+  --from-literal=provider=aws \
+  --from-literal=domain-filter=<domain_name> \
+  --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster
 ----
 +
 [NOTE]
@@ -51,6 +54,8 @@ $ oc create secret generic <secret_name> --from-literal=provider=aws --from-lite
 Disaster recovery backup for the secret is not automatically enabled. To back up the secret for disaster recovery, add the `hypershift-operator-external-dns-credentials` by entering the following command:
 [source,terminal]
 ----
-$ oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
+$ oc label secret hypershift-operator-external-dns-credentials \
+  -n local-cluster \
+  cluster.open-cluster-management.io/backup=""
 ----
 ====
diff --git a/modules/hcp-bm-access.adoc b/modules/hcp-bm-access.adoc
index 602d2af9dbe2..2c967acf5d9a 100644
--- a/modules/hcp-bm-access.adoc
+++ b/modules/hcp-bm-access.adoc
@@ -35,7 +35,8 @@ The `kubeadmin` password secret is also Base64-encoded. You can decode it and us
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
+  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After you save the `kubeconfig` file, you can access the hosted cluster by entering the following example command:
diff --git a/modules/hcp-bm-autoscale-disable.adoc b/modules/hcp-bm-autoscale-disable.adoc
index 9155171554ea..a45b912c3fc1 100644
--- a/modules/hcp-bm-autoscale-disable.adoc
+++ b/modules/hcp-bm-autoscale-disable.adoc
@@ -15,7 +15,9 @@ To disable node auto-scaling, complete the following procedure.
 +
 [source,terminal]
 ----
-$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'
+$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
+  --type=json \
+  -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'
 ----
 +
 The command removes `"spec.autoScaling"` from the YAML file, adds `"spec.replicas"`, and sets `"spec.replicas"` to the integer value that you specify.
diff --git a/modules/hcp-bm-autoscale.adoc b/modules/hcp-bm-autoscale.adoc
index 35ee9ecdd9a5..c25dbaf28f9c 100644
--- a/modules/hcp-bm-autoscale.adoc
+++ b/modules/hcp-bm-autoscale.adoc
@@ -15,7 +15,9 @@ When you need more capacity in your hosted cluster and spare agents are availabl
 +
 [source,terminal]
 ----
-$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
+$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
+  --type=json \
+  -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
 ----
 +
 [NOTE]
@@ -71,7 +73,9 @@ $ oc apply -f workload-config.yaml
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm
+$ oc extract -n <hosted_cluster_namespace> \
+  secret/<hosted_cluster_name>-admin-kubeconfig \
+  --to=./hostedcluster-secrets --confirm
 ----
 +
 .Example output
@@ -90,7 +94,8 @@ $ oc --kubeconfig ./hostedcluster-secrets get nodes
 +
 [source,terminal]
 ----
-$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> delete deployment <deployment_name>
+$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
+  delete deployment <deployment_name>
 ----
 
 . Wait for several minutes to pass without requiring the additional capacity. On the Agent platform, the agent is decommissioned and can be reused. You can confirm that the node was removed by entering the following command:
@@ -99,10 +104,8 @@ $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> delete deployment <depl
 ----
 $ oc --kubeconfig ./hostedcluster-secrets get nodes
 ----
-
++
 [NOTE]
 ====
-For {ibm-z-title} agents, compute nodes are detached from the cluster only for {ibm-z-title} with KVM agents. For z/VM and LPAR, you must delete the compute nodes manually.
-
-Agents can be reused only for {ibm-z-title} with KVM. For z/VM and LPAR, re-create the agents to use them as compute nodes.
-====
\ No newline at end of file
+For {ibm-z-name} agents, if you are using an OSA network device in Processor Resource/Systems Manager (PR/SM) mode, auto scaling is not supported. You must delete the old agent manually and scale up the node pool because the new agent joins during the scale down process.
+====
diff --git a/modules/hcp-bm-hc-mirror.adoc b/modules/hcp-bm-hc-mirror.adoc
index 6c5b1515e425..0248b7c692f1 100644
--- a/modules/hcp-bm-hc-mirror.adoc
+++ b/modules/hcp-bm-hc-mirror.adoc
@@ -52,4 +52,4 @@ $ hcp create cluster agent \
 <6> Specify the `icsp.yaml` file that defines ICSP and your mirror registries.
 <7> Specify the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
 <8> Specify your hosted cluster namespace.
-<9> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
\ No newline at end of file
+<9> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
\ No newline at end of file
diff --git a/modules/hcp-bm-hc.adoc b/modules/hcp-bm-hc.adoc
index baac07f253cb..5ab5afcf1837 100644
--- a/modules/hcp-bm-hc.adoc
+++ b/modules/hcp-bm-hc.adoc
@@ -45,7 +45,8 @@ $ hcp create cluster agent \
     --ssh-key  <path_to_ssh_public_key> \// <7>
     --namespace <hosted_cluster_namespace> \// <8>
     --control-plane-availability-policy HighlyAvailable \// <9>
-    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> <10>
+    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \// <10>
+    --node-pool-replicas <node_pool_replica_count> <11>
 ----
 +
 <1> Specify the name of your hosted cluster, for instance, `example`.
@@ -57,7 +58,8 @@ $ hcp create cluster agent \
 <7> Specify the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
 <8> Specify your hosted cluster namespace.
 <9> Specify the availability policy for the hosted control plane components. Supported options are `SingleReplica` and `HighlyAvailable`. The default value is `HighlyAvailable`.
-<10> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
+<10> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
+<11> Specify the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created.
 
 +
 . After a few moments, verify that your hosted control plane pods are up and running by entering the following command:
diff --git a/modules/hcp-bm-ingress.adoc b/modules/hcp-bm-ingress.adoc
index 99614a9887c9..53550963e677 100644
--- a/modules/hcp-bm-ingress.adoc
+++ b/modules/hcp-bm-ingress.adoc
@@ -146,7 +146,7 @@ kind: Service
 apiVersion: v1
 metadata:
   annotations:
-    metallb.universe.tf/address-pool: ingress-public-ip
+   metallb.io/address-pool: ingress-public-ip
   name: metallb-ingress
   namespace: openshift-ingress
 spec:
@@ -204,7 +204,7 @@ clusteroperator.config.openshift.io/console
 clusteroperator.config.openshift.io/ingress                                      4.x.y     True        False         False      53m
 ----
 +
-Replace `<4.x.y>` with the supported {product-title} version that you want to use, for example, `4.17.0-multi`.
+Replace `<4.x.y>` with the supported {product-title} version that you want to use, for example, `4.18.0-multi`.
 
 
 ifeval::["{context}" == "hcp-manage-non-bm"]
diff --git a/modules/hcp-bm-prereqs.adoc b/modules/hcp-bm-prereqs.adoc
index 9fc880ccd26c..28fec8d3423d 100644
--- a/modules/hcp-bm-prereqs.adoc
+++ b/modules/hcp-bm-prereqs.adoc
@@ -15,8 +15,8 @@
 $ oc get managedclusters local-cluster
 ----
 
-* You must add the `topology.kubernetes.io/zone` label to your bare metal hosts on your management cluster. Otherwise, all of the hosted control plane pods are scheduled on a single node, causing single point of failure.
+* You must add the `topology.kubernetes.io/zone` label to your bare-metal hosts on your management cluster. Ensure that each host has a unique value for `topology.kubernetes.io/zone`. Otherwise, all of the hosted control plane pods are scheduled on a single node, causing a single point of failure.
 
 * To provision {hcp} on bare metal, you can use the Agent platform. The Agent platform uses the central infrastructure management service to add worker nodes to a hosted cluster. For more information, see _Enabling the central infrastructure management service_.
 
-* You need to install the hosted control plane command line interface.
\ No newline at end of file
+* You need to install the hosted control plane command line interface.
diff --git a/modules/hcp-bm-scale-np.adoc b/modules/hcp-bm-scale-np.adoc
index a432dfa827cc..1cf1496fff95 100644
--- a/modules/hcp-bm-scale-np.adoc
+++ b/modules/hcp-bm-scale-np.adoc
@@ -51,7 +51,8 @@ da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
 +
 [source,terminal]
 ----
-$ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
+$ oc -n <hosted_control_plane_namespace> get agent \
+  -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
 ----
 +
 .Example output
@@ -66,7 +67,9 @@ BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficien
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=- > kubeconfig-<hosted_cluster_name>
+$ oc extract -n <hosted_cluster_namespace> \
+  secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
+  > kubeconfig-<hosted_cluster_name>
 ----
 
 . After the agents reach the `added-to-existing-cluster` state, verify that you can see the {product-title} nodes in the hosted cluster by entering the following command:
diff --git a/modules/hcp-bm-verify.adoc b/modules/hcp-bm-verify.adoc
index 8f95b8df12e3..e20d19abe58d 100644
--- a/modules/hcp-bm-verify.adoc
+++ b/modules/hcp-bm-verify.adoc
@@ -14,7 +14,8 @@ After the deployment process is complete, you can verify that the hosted cluster
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>
+$ oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig \
+  --to=- > kubeconfig-<hosted-cluster-name>
 ----
 
 . Use the kubeconfig to view the cluster Operators of the hosted cluster. Enter the following command:
diff --git a/modules/hcp-cco-verify-aws-sts.adoc b/modules/hcp-cco-verify-aws-sts.adoc
index 7e260b05251e..8603c0b64201 100644
--- a/modules/hcp-cco-verify-aws-sts.adoc
+++ b/modules/hcp-cco-verify-aws-sts.adoc
@@ -19,7 +19,9 @@ You can verify that the Cloud Credential Operator (CCO) is running correctly in
 +
 [source,terminal]
 ----
-$ oc get cloudcredentials <hosted_cluster_name> -n <hosted_cluster_namespace> -o=jsonpath={.spec.credentialsMode}
+$ oc get cloudcredentials <hosted_cluster_name> \
+  -n <hosted_cluster_namespace> \
+  -o=jsonpath={.spec.credentialsMode}
 ----
 +
 .Expected output
@@ -32,7 +34,8 @@ Manual
 +
 [source,terminal]
 ----
-$ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig -o jsonpath --template '{.spec.serviceAccountIssuer }'
+$ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \
+  -o jsonpath --template '{.spec.serviceAccountIssuer }'
 ----
 +
 .Example output
diff --git a/modules/hcp-create-hc-arm64-aws.adoc b/modules/hcp-create-hc-arm64-aws.adoc
index 4e4ffbb6a8d0..f5fdb290557e 100644
--- a/modules/hcp-create-hc-arm64-aws.adoc
+++ b/modules/hcp-create-hc-arm64-aws.adoc
@@ -17,7 +17,7 @@ If you do not use a multi-architecture release image, the compute nodes in the n
 
 .Procedure
 
-. Create a hosted cluster on an ARM64 {product-title} cluster by entering the following command:
+* Create a hosted cluster on an ARM64 {product-title} cluster by entering the following command:
 +
 [source,terminal]
 ----
@@ -37,18 +37,5 @@ $ hcp create cluster aws \
 <4> Specify the path to your pull secret, for example, `/user/name/pullsecret`.
 <5> Specify the path to your AWS STS credentials file, for example, `/home/user/sts-creds/sts-creds.json`.
 <6> Specify the AWS region name, for example, `us-east-1`.
-<7> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see "Extracting the {product-title} release image digest".
-<8> Specify the Amazon Resource Name (ARN), for example, `arn:aws:iam::820196288204:role/myrole`.
-
-. Add a `NodePool` object to the hosted cluster by running the following command:
-+
-[source,terminal]
-----
-$ hcp create nodepool aws \
-  --cluster-name <hosted_cluster_name> \// <1>
-  --name <nodepool_name> \// <2>
-  --node-count <node_pool_replica_count> <3>
-----
-<1> Specify the name of your hosted cluster, for instance, `example`.
-<2> Specify the node pool name.
-<3> Specify the node pool replica count, for example, `3`.
\ No newline at end of file
+<7> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see "Extracting the {product-title} release image digest".
+<8> Specify the Amazon Resource Name (ARN), for example, `arn:aws:iam::820196288204:role/myrole`.
\ No newline at end of file
diff --git a/modules/hcp-dc-addon.adoc b/modules/hcp-dc-addon.adoc
index a3d50b6ba35f..e42d40946232 100644
--- a/modules/hcp-dc-addon.adoc
+++ b/modules/hcp-dc-addon.adoc
@@ -16,7 +16,8 @@ By default, no node placement preference is specified for the `hypershift-addon`
 +
 [source,terminal]
 ----
-$ oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
+$ oc edit addondeploymentconfig hypershift-addon-deploy-config \
+  -n multicluster-engine
 ----
 
 . Add the `nodePlacement` field to the specification, as shown in the following example:
diff --git a/modules/hcp-dc-hypervisor.adoc b/modules/hcp-dc-hypervisor.adoc
index 88ef593a41b2..4100dc9b8fef 100644
--- a/modules/hcp-dc-hypervisor.adoc
+++ b/modules/hcp-dc-hypervisor.adoc
@@ -14,7 +14,8 @@ The following information applies to virtual machine environments only.
 +
 [source,terminal]
 ----
-$ sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
+$ sudo dnf install dnsmasq radvd vim golang podman bind-utils \
+  net-tools httpd-tools tree htop strace tmux -y
 ----
 
 . Enable and start the Podman service by entering the following command:
@@ -89,7 +90,9 @@ if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
 export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
 cp $BASE_RESOLV_CONF $TMP_FILE
 chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
-sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE <2>
+sed -i -e "s/dns.base.domain.name//" \
+       -e "s/search /& dns.base.domain.name /" \
+       -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE <2>
 mv $TMP_FILE /etc/resolv.conf
 fi
 echo "ok"
@@ -147,7 +150,8 @@ If you are working in a production environment, you must establish proper rules
 +
 [source,terminal]
 ----
-$ sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
+$ sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; \
+  setenforce 0
 ----
 
 * For `firewalld`, enter the following command:
diff --git a/modules/hcp-dc-image-mirror.adoc b/modules/hcp-dc-image-mirror.adoc
index 70ace3e07e69..a4def21339ae 100644
--- a/modules/hcp-dc-image-mirror.adoc
+++ b/modules/hcp-dc-image-mirror.adoc
@@ -17,7 +17,7 @@ In the following procedures, the `oc-mirror` tool is used, which is a binary tha
 
 .Prerequisites
 
-Ensure that the registry server is running before you start the mirroring process.
+* Ensure that the registry server is running before you start the mirroring process.
 
 .Procedure
 
@@ -27,23 +27,20 @@ To configure image mirroring, complete the following steps:
 
 . By using the following example, create an `ImageSetConfiguration` object to use for mirroring. Replace values as needed to match your environment:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
-apiVersion: mirror.openshift.io/v1alpha2
+apiVersion: mirror.openshift.io/v2alpha1
 kind: ImageSetConfiguration
-storageConfig:
-  registry:
-    imageURL: registry.<dns.base.domain.name>:5000/openshift/release/metadata:latest <1>
 mirror:
   platform:
     channels:
-    - name: candidate-4.17
-      minVersion: 4.x.y-build  <2>
-      maxVersion: 4.x.y-build <2>
+    - name: candidate-{product-version}
+      minVersion: <4.x.y-build>  <1>
+      maxVersion: <4.x.y-build> <1>
       type: ocp
-    kubeVirtContainer: true <3>
+    kubeVirtContainer: true <2>
     graph: true
-  additionalImages:
+  additionalImages: <3>
   - name: quay.io/karmab/origin-keepalived-ipfailover:latest
   - name: quay.io/karmab/kubectl:latest
   - name: quay.io/karmab/haproxy:latest
@@ -52,10 +49,10 @@ mirror:
   - name: quay.io/karmab/curl:latest
   - name: quay.io/karmab/kcli:latest
   - name: quay.io/user-name/trbsht:latest
-  - name: quay.io/user-name/hypershift:BMSelfManage-v4.17
+  - name: quay.io/user-name/hypershift:BMSelfManage-v{product-version}
   - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
   operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
+  - catalog: registry.redhat.io/redhat/redhat-operator-index:v{product-version}
     packages:
     - name: lvms-operator
     - name: local-storage-operator
@@ -67,19 +64,20 @@ mirror:
     - name: kubevirt-hyperconverged <4>
 ----
 +
-<1> Replace `<dns.base.domain.name>` with the DNS base domain name.
-<2> Replace `4.x.y-build` with the supported {product-title} version you want to use.
-<3> Set this optional flag to `true` if you want to also mirror the container disk image for the {op-system-first} boot image for the KubeVirt provider. This flag is available with oc-mirror v2 only.
+<1> Replace `<4.x.y-build>` with the supported {product-title} version you want to use.
+<2> Set this optional flag to `true` if you want to also mirror the container disk image for the {op-system-first} boot image for the KubeVirt provider. This flag is available with oc-mirror v2 only.
+<3> Images specified in the `additionalImages` field are examples only and are not strictly needed.
 <4> For deployments that use the KubeVirt provider, include this line.
 
 . Start the mirroring process by entering the following command:
 +
 [source,terminal]
 ----
-$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
+$ oc-mirror --v2 --config imagesetconfig.yaml \
+  --workspace file://mirror-file docker://<registry>
 ----
 +
-After the mirroring process is finished, you have a new folder named `oc-mirror-workspace/results-XXXXXX/`, which contains the IDMS and the catalog sources to apply on the hosted cluster.
+After the mirroring process is finished, you have a new folder named `mirror-file`, which contains the `ImageDigestMirrorSet` (IDMS), `ImageTagMirrorSet` (ITMS), and the catalog sources to apply on the hosted cluster.
 
 . Mirror the nightly or CI versions of {product-title} by configuring the `imagesetconfig.yaml` file as follows:
 +
@@ -90,19 +88,41 @@ kind: ImageSetConfiguration
 mirror:
   platform:
     graph: true
-    release: registry.ci.openshift.org/ocp/release:4.x.y-build <1>
+    release: registry.ci.openshift.org/ocp/release:<4.x.y-build> <1>
     kubeVirtContainer: true <2>
 # ...
 ----
 +
-<1> Replace `4.x.y-build` with the supported {product-title} version you want to use.
+<1> Replace `<4.x.y-build>` with the supported {product-title} version you want to use.
 <2> Set this optional flag to `true` if you want to also mirror the container disk image for the {op-system-first} boot image for the KubeVirt provider. This flag is available with oc-mirror v2 only.
 
-. Apply the changes to the file by entering the following command:
+. If you have a partially disconnected environment, mirror the images from the image set configuration to a registry by entering the following command:
++
+[source,terminal]
+----
+$ oc mirror -c imagesetconfig.yaml \
+  --workspace file://<file_path> docker://<mirror_registry_url> --v2
+----
++
+For more information, see "Mirroring an image set in a partially disconnected environment".
+
+. If you have a fully disconnected environment, perform the following steps:
+
+.. Mirror the images from the specified image set configuration to the disk by entering the following command:
++
+[source,terminal]
+----
+$ oc mirror -c imagesetconfig.yaml file://<file_path> --v2
+----
++
+For more information, see "Mirroring an image set in a fully disconnected environment".
+
+.. Process the image set file on the disk and mirror the contents to a target mirror registry by entering the following command:
 +
 [source,terminal]
 ----
-$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
+$ oc mirror -c imagesetconfig.yaml \
+  --from file://<file_path> docker://<mirror_registry_url> --v2
 ----
 
-. Mirror the latest {mce-short} images by following the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#install-on-disconnected-networks[Install on disconnected networks].
\ No newline at end of file
+. Mirror the latest {mce-short} images by following the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#install-on-disconnected-networks[Install on disconnected networks].
diff --git a/modules/hcp-dc-mgmt-cluster.adoc b/modules/hcp-dc-mgmt-cluster.adoc
index f53e1486436e..62fc88df4413 100644
--- a/modules/hcp-dc-mgmt-cluster.adoc
+++ b/modules/hcp-dc-mgmt-cluster.adoc
@@ -14,7 +14,8 @@ To set up an {product-title} management cluster, you can use dev-scripts, or if
 +
 [source,terminal]
 ----
-$ kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual
+$ kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false \
+  -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual
 ----
 +
 where:
@@ -66,7 +67,7 @@ type: routed
 plan: hub-dual
 force: true
 version: stable
-tag: "4.x.y-x86_64" <1>
+tag: "<4.x.y>-x86_64" <1>
 cluster: "hub-dual"
 dualstack: true
 domain: dns.base.domain.name
@@ -133,7 +134,7 @@ vmrules:
       mac: aa:aa:aa:aa:10:03
 ----
 +
-<1> Replace `4.x.y` with the supported {product-title} version you want to use.
+<1> Replace `<4.x.y>` with the supported {product-title} version you want to use.
 
 . To provision the management cluster, enter the following command:
 +
@@ -144,4 +145,4 @@ $ kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml
 
 .Next steps
 
-Next, configure the web server.
\ No newline at end of file
+Next, configure the web server.
diff --git a/modules/hcp-dc-scale-np.adoc b/modules/hcp-dc-scale-np.adoc
index c85d81e73b71..c1a6398ccaa4 100644
--- a/modules/hcp-dc-scale-np.adoc
+++ b/modules/hcp-dc-scale-np.adoc
@@ -14,7 +14,8 @@ After you create the bare metal hosts, their statuses change from `Registering`
 +
 [source,terminal]
 ----
-$ oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> --replicas 3
+$ oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> \
+  --replicas 3
 ----
 +
 where:
@@ -39,9 +40,9 @@ clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       au
 [source,terminal]
 ----
 NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION       UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
-clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                     Minimum availability requires 3 replicas, current 0 available
+clusters    hosted   hosted    3                               False         False        <4.x.y>-x86_64                                     Minimum availability requires 3 replicas, current 0 available
 ----
 +
-Replace `4.x.y` with the supported {product-title} version that you want to use.
+Replace `<4.x.y>` with the supported {product-title} version that you want to use.
 
-. Wait until the nodes join the cluster. During the process, the agents provide updates on their stage and status.
\ No newline at end of file
+. Wait until the nodes join the cluster. During the process, the agents provide updates on their stage and status.
diff --git a/modules/hcp-dc-verify.adoc b/modules/hcp-dc-verify.adoc
index 7924eababeb2..c73d26ee5edd 100644
--- a/modules/hcp-dc-verify.adoc
+++ b/modules/hcp-dc-verify.adoc
@@ -14,7 +14,8 @@ The hosted control plane feature is enabled by default.
 +
 [source,terminal]
 ----
-$ oc patch mce <multiclusterengine> --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'
+$ oc patch mce <multiclusterengine> --type=merge -p \
+  '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'
 ----
 +
 When you enable the feature, the `hypershift-addon` managed cluster add-on is installed in the `local-cluster` managed cluster, and the add-on agent installs the HyperShift Operator on the {mce-short} hub cluster.
@@ -36,12 +37,14 @@ hypershift-addon   True        False
 +
 [source,terminal]
 ----
-$ oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
+$ oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon \
+  -n local-cluster --timeout=5m
 ----
 +
 [source,terminal]
 ----
-$ oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
+$ oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon \
+  -n local-cluster --timeout=5m
 ----
 +
 When the process is complete, the `hypershift-addon` managed cluster add-on and the HyperShift Operator are installed, and the `local-cluster` managed cluster is available to host and manage hosted clusters.
\ No newline at end of file
diff --git a/modules/hcp-dc-web-server.adoc b/modules/hcp-dc-web-server.adoc
index 0098500d2b5e..6c91d77cf858 100644
--- a/modules/hcp-dc-web-server.adoc
+++ b/modules/hcp-dc-web-server.adoc
@@ -16,7 +16,8 @@ To configure the web server, complete the following steps:
 +
 [source,terminal]
 ----
-$ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
+$ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install \
+  "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
 ----
 
 . Run the following script. The script creates a folder in the `/opt/srv` directory. The folder contains the {op-system} images to provision the worker nodes.
diff --git a/modules/hcp-disable-feature.adoc b/modules/hcp-disable-feature.adoc
index bd06e35fe538..7280b75a9c80 100644
--- a/modules/hcp-disable-feature.adoc
+++ b/modules/hcp-disable-feature.adoc
@@ -17,7 +17,8 @@ To disable the {hcp} feature, complete the following steps.
 +
 [source,terminal]
 ----
-$ oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}' <1>
+$ oc patch mce multiclusterengine --type=merge -p \// <1>
+  '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'
 ----
 +
 <1> The default `MultiClusterEngine` resource instance name is `multiclusterengine`, but you can get the `MultiClusterEngine` name from your cluster by running the following command: `$ oc get mce`.
diff --git a/modules/hcp-disable-metrics.adoc b/modules/hcp-disable-metrics.adoc
index b05abab6924b..aa66bb2491de 100644
--- a/modules/hcp-disable-metrics.adoc
+++ b/modules/hcp-disable-metrics.adoc
@@ -23,7 +23,8 @@ $ oc login
 +
 [source,terminal]
 ----
-$ oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
+$ oc edit addondeploymentconfig hypershift-addon-deploy-config \
+  -n multicluster-engine
 ----
 
 . Add the `disableMetrics=true` customized variable to the specification, as shown in the following example:
diff --git a/modules/hcp-dr-oadp-backup-cp-workload.adoc b/modules/hcp-dr-oadp-backup-cp-workload.adoc
index 0df86a90ba14..6ba217c24cb5 100644
--- a/modules/hcp-dr-oadp-backup-cp-workload.adoc
+++ b/modules/hcp-dr-oadp-backup-cp-workload.adoc
@@ -34,7 +34,8 @@ Note the infrastructure ID to use in the next step.
 +
 [source,terminal]
 ----
-$ oc patch cluster.cluster.x-k8s.io \
+$ oc --kubeconfig <management_cluster_kubeconfig_file> \
+  patch cluster.cluster.x-k8s.io \
   -n local-cluster-<hosted_cluster_name> <hosted_cluster_infra_id> \
   --type json -p '[{"op": "add", "path": "/spec/paused", "value": true}]'
 ----
@@ -154,7 +155,8 @@ $ oc apply -f backup-control-plane.yaml
 +
 [source,terminal]
 ----
-$ oc get backups.velero.io <backup_resource_name> -n openshift-adp -o jsonpath='{.status.phase}'
+$ oc get backups.velero.io <backup_resource_name> -n openshift-adp \
+  -o jsonpath='{.status.phase}'
 ----
 
 .Next steps
diff --git a/modules/hcp-dr-oadp-restore.adoc b/modules/hcp-dr-oadp-restore.adoc
index 16af9daa5909..3281fd4e77a4 100644
--- a/modules/hcp-dr-oadp-restore.adoc
+++ b/modules/hcp-dr-oadp-restore.adoc
@@ -18,8 +18,8 @@ After you back up your hosted cluster, you must destroy it to initiate the resto
 
 .Prerequisites
 
-* You completed the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#remove-a-cluster-by-using-the-console[Removing a cluster by using the console] to delete your hosted cluster.
-* You completed the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#removing-a-cluster-from-management-in-special-cases[Removing remaining resources after removing a cluster].
+* You completed the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#remove-a-cluster-by-using-the-console[Removing a cluster by using the console] to delete your hosted cluster.
+* You completed the steps in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#removing-a-cluster-from-management-in-special-cases[Removing remaining resources after removing a cluster].
 
 To monitor and observe the backup process, see "Observing the backup and restore process".
 
@@ -81,7 +81,8 @@ $ oc apply -f restore-hosted-cluster.yaml
 +
 [source,terminal]
 ----
-$ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> -o jsonpath='{.status.phase}'
+$ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \
+  -o jsonpath='{.status.phase}'
 ----
 
 . After the restore process is complete, start the reconciliation of the `HostedCluster` and `NodePool` resources that you paused during backing up of the control plane workload:
@@ -92,7 +93,8 @@ $ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> -o js
 ----
 $ oc --kubeconfig <management_cluster_kubeconfig_file> \
   patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
-  --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
+  --type json \
+  -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
 ----
 
 .. Start the reconciliation of the `NodePool` resource by running the following command:
@@ -101,7 +103,8 @@ $ oc --kubeconfig <management_cluster_kubeconfig_file> \
 ----
 $ oc --kubeconfig <management_cluster_kubeconfig_file> \
   patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
-  --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
+  --type json \
+  -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
 ----
 
 . Start the reconciliation of the Agent provider resources that you paused during backing up of the control plane workload:
diff --git a/modules/hcp-enable-manual.adoc b/modules/hcp-enable-manual.adoc
index 164e907e8d8f..0a5a934380b1 100644
--- a/modules/hcp-enable-manual.adoc
+++ b/modules/hcp-enable-manual.adoc
@@ -13,7 +13,8 @@ If you need to manually enable {hcp}, complete the following steps.
 +
 [source,terminal]
 ----
-$ oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' <1>
+$ oc patch mce multiclusterengine --type=merge -p \
+  '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' <1>
 ----
 <1> The default `MultiClusterEngine` resource instance name is `multiclusterengine`, but you can get the `MultiClusterEngine` name from your cluster by running the following command: `$ oc get mce`.
 
diff --git a/modules/hcp-fips.adoc b/modules/hcp-fips.adoc
new file mode 100644
index 000000000000..4fd9c0a78fb9
--- /dev/null
+++ b/modules/hcp-fips.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * hosted-control-planes/hcp-prepare/hcp-requirements.adoc
+
+
+:_mod-docs-content-type: CONCEPT
+[id="hcp-fips_{context}"]
+= FIPS-enabled hosted clusters
+
+The binaries for {hcp} are FIPs-compliant, with the exception of the {hcp} command-line interface, `hcp`.
+
+If you want to deploy a FIPS-enabled hosted cluster, you must use a FIPS-enabled management cluster. To enable FIPS mode for your management cluster, you must run the installation program from a {op-system-base-full} computer configured to operate in FIPS mode. For more information about configuring FIPS mode on {op-system-base}, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening[Switching {op-system-base} to FIPS mode].
+
+When running {op-system-base} or {op-system-first} booted in FIPS mode, {product-title} core components use the {op-system-base} cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures.
+
+After you set up your management cluster in FIPS mode, the hosted cluster creation process runs on that management cluster.
\ No newline at end of file
diff --git a/modules/hcp-hc-objects.adoc b/modules/hcp-hc-objects.adoc
index 92007cc45fa2..afd937ff2d9a 100644
--- a/modules/hcp-hc-objects.adoc
+++ b/modules/hcp-hc-objects.adoc
@@ -154,7 +154,7 @@ spec:
   pullSecret:
     name: <hosted_cluster_name>-pull-secret <1>
   release:
-    image: registry.<dns.base.domain.name>:5000/openshift/release-images:4.x.y-x86_64 <4> <5>
+    image: registry.<dns.base.domain.name>:5000/openshift/release-images:<4.x.y>-x86_64 <4> <5>
   secretEncryption:
     aescbc:
       activeKey:
@@ -188,7 +188,7 @@ status:
 <2> Replace `<hosted_cluster_namespace>` with the name of your hosted cluster namespace.
 <3> The `imageContentSources` section contains mirror references for user workloads within the hosted cluster.
 <4> Replace `<dns.base.domain.name>` with the DNS base domain name.
-<5> Replace `4.x.y` with the supported {product-title} version you want to use.
+<5> Replace `<4.x.y>` with the supported {product-title} version you want to use.
 
 . Add an annotation in the `HostedCluster` object that points to the HyperShift Operator release in the {product-title} release:
 
@@ -196,10 +196,12 @@ status:
 +
 [source,terminal]
 ----
-$ oc adm release info registry.<dns.base.domain.name>:5000/openshift-release-dev/ocp-release:4.x.y-x86_64 | grep hypershift
+$ oc adm release info \
+  registry.<dns.base.domain.name>:5000/openshift-release-dev/ocp-release:<4.x.y>-x86_64 \
+  | grep hypershift
 ----
 +
-where `<dns.base.domain.name>` is the DNS base domain name and `4.x.y` is the supported {product-title} version you want to use.
+where `<dns.base.domain.name>` is the DNS base domain name and `<4.x.y>` is the supported {product-title} version you want to use.
 +
 .Example output
 [source,terminal]
@@ -287,4 +289,4 @@ When the hosted cluster is available, the output looks like the following exampl
 ----
 NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
 clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
-----
\ No newline at end of file
+----
diff --git a/modules/hcp-ibm-power-infraenv.adoc b/modules/hcp-ibm-power-infraenv.adoc
index 3200ab19b13a..2607047d2e4c 100644
--- a/modules/hcp-ibm-power-infraenv.adoc
+++ b/modules/hcp-ibm-power-infraenv.adoc
@@ -45,5 +45,6 @@ $ oc apply -f infraenv-config.yaml
 +
 [source,terminal]
 ----
-$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
+$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> \
+  -o json
 ----
diff --git a/modules/hcp-ibm-power-scale-np.adoc b/modules/hcp-ibm-power-scale-np.adoc
index c0b06bb0a62e..1e2f29da871a 100644
--- a/modules/hcp-ibm-power-scale-np.adoc
+++ b/modules/hcp-ibm-power-scale-np.adoc
@@ -30,7 +30,8 @@ The Cluster API agent provider randomly picks two agents that are then assigned
 +
 [source,terminal]
 ----
-$ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
+$ oc -n <hosted_control_plane_namespace> get agent \
+  -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
 ----
 +
 .Example output
@@ -60,7 +61,8 @@ da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true           auto-as
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
+  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After the agents reach the `added-to-existing-cluster` state, verify that you can see the {product-title} nodes by entering the following command:
diff --git a/modules/hcp-ibm-z-adding-credentials-registry.adoc b/modules/hcp-ibm-z-adding-credentials-registry.adoc
index 3110462d98d3..9f719d8bc21f 100644
--- a/modules/hcp-ibm-z-adding-credentials-registry.adoc
+++ b/modules/hcp-ibm-z-adding-credentials-registry.adoc
@@ -41,7 +41,9 @@ spec:
 +
 [source,terminal]
 ----
-$ oc get secret/pull-secret -n openshift-config -o json | jq -r '.data.".dockerconfigjson"' | base64 -d > authfile
+$ oc get secret/pull-secret -n openshift-config -o json \
+  | jq -r '.data.".dockerconfigjson"' \
+  | base64 -d > authfile
 ----
 .. Edit the fetched secret JSON file to include a section with the credentials of the certificate authority:
 +
@@ -61,5 +63,6 @@ $ oc get secret/pull-secret -n openshift-config -o json | jq -r '.data.".dockerc
 +
 [source,terminal]
 ----
-$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=authfile
+$ oc set data secret/pull-secret -n openshift-config \
+  --from-file=.dockerconfigjson=authfile
 ----
\ No newline at end of file
diff --git a/modules/hcp-ibm-z-adding-reg-ca-hostedcluster.adoc b/modules/hcp-ibm-z-adding-reg-ca-hostedcluster.adoc
index 9736b400b3f4..1fe8647721bc 100644
--- a/modules/hcp-ibm-z-adding-reg-ca-hostedcluster.adoc
+++ b/modules/hcp-ibm-z-adding-reg-ca-hostedcluster.adoc
@@ -44,5 +44,5 @@ $ hcp create cluster agent \
 <4> Replace the name with your base domain, for example, `example.com`.
 <5> Replace the etcd storage class name, for example, `lvm-storageclass`.
 <6> Replace the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
-<7> Replace with the supported {product-title} version that you want to use, for example, `4.17.0-multi`.
+<7> Replace with the supported {product-title} version that you want to use, for example, `4.18.0-multi`.
 <8> Replace the path to Certificate Authority of mirror registry.
\ No newline at end of file
diff --git a/modules/hcp-ibm-z-scale-np.adoc b/modules/hcp-ibm-z-scale-np.adoc
index a039e10915db..bdbba2029160 100644
--- a/modules/hcp-ibm-z-scale-np.adoc
+++ b/modules/hcp-ibm-z-scale-np.adoc
@@ -10,8 +10,6 @@ The `NodePool` object is created when you create a hosted cluster. By scaling th
 
 When you scale up a node pool, a machine is created. The Cluster API provider finds an Agent that is approved, is passing validations, is not currently in use, and meets the requirements that are specified in the node pool specification. You can monitor the installation of an Agent by checking its status and conditions.
 
-When you scale down a node pool, Agents are unbound from the corresponding cluster. Before you reuse the clusters, you must boot the clusters by using the PXE image to update the number of nodes.
-
 .Procedure
 
 . Run the following command to scale the `NodePool` object to two nodes:
@@ -66,7 +64,9 @@ da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-ass
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig \
+  --namespace <clusters_namespace> \
+  --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After the agents reach the `added-to-existing-cluster` state, verify that you can see the {product-title} nodes by entering the following command:
diff --git a/modules/hcp-import-disable.adoc b/modules/hcp-import-disable.adoc
index 46392d479035..c7a5400a3d08 100644
--- a/modules/hcp-import-disable.adoc
+++ b/modules/hcp-import-disable.adoc
@@ -25,7 +25,8 @@ To disable the automatic import of hosted clusters, complete the following steps
 +
 [source,terminal]
 ----
-$ oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
+$ oc edit addondeploymentconfig hypershift-addon-deploy-config \
+  -n multicluster-engine
 ----
 
 . In the `spec.customizedVariables` section, add the `autoImportDisabled` variable with value of `"true"`, as shown in the following example:
diff --git a/modules/hcp-kubeconf-nodepool.adoc b/modules/hcp-kubeconf-nodepool.adoc
new file mode 100644
index 000000000000..870199baf8bc
--- /dev/null
+++ b/modules/hcp-kubeconf-nodepool.adoc
@@ -0,0 +1,62 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-machine-config.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="hcp-kubeconf-nodepool_{context}"]
+= Referencing the kubelet configuration in node pools
+
+To reference your kubelet configuration in node pools, you add the kubelet configuration in a config map and then apply the config map in the `NodePool` resource.
+
+.Procedure
+
+. Add the kubelet configuration inside of a config map in the management cluster by entering the following information:
++
+.Example `ConfigMap` object with the kubelet configuration
+[source,yaml]
+----
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: <configmap_name> <1>
+  namespace: clusters
+data:
+  config: |
+    apiVersion: machineconfiguration.openshift.io/v1
+    kind: KubeletConfig
+    metadata:
+      name: <kubeletconfig_name> <2>
+    spec:
+      kubeletConfig:
+        registerWithTaints:
+        - key: "example.sh/unregistered"
+          value: "true"
+          effect: "NoExecute"
+----
+<1> Replace `<configmap_name>` with the name of your config map.
+<2> Replace `<kubeletconfig_name>` with the name of the `KubeletConfig` resource.
+
+. Apply the config map to the node pool by entering the following command:
++
+[source,yaml]
+----
+$ oc edit nodepool <nodepool_name> --namespace clusters <1>
+----
+<1> Replace `<nodepool_name>` with the name of your node pool.
++
+.Example `NodePool` resource configuration
+[source,yaml]
+----
+apiVersion: hypershift.openshift.io/v1alpha1
+kind: NodePool
+metadata:
+# ...
+  name: nodepool-1
+  namespace: clusters
+# ...
+spec:
+  config:
+  - name: <configmap_name> <1>
+# ...
+----
+<1> Replace `<configmap_name>` with the name of your config map.
diff --git a/modules/hcp-labels-taints.adoc b/modules/hcp-labels-taints.adoc
index a61120918baf..63bc99cde104 100644
--- a/modules/hcp-labels-taints.adoc
+++ b/modules/hcp-labels-taints.adoc
@@ -40,7 +40,7 @@ To enable a hosted cluster to require its pods to be scheduled into infrastructu
 ----
   spec:
     nodeSelector:
-      role.kubernetes.io/infra: ""
+      node-role.kubernetes.io/infra: ""
 ----
 
 This way, {hcp} for each hosted cluster are eligible infrastructure node workloads, and you do not need to entitle the underlying {product-title} nodes.
diff --git a/modules/hcp-load-based-limit.adoc b/modules/hcp-load-based-limit.adoc
index 949d0163118a..81808157af3d 100644
--- a/modules/hcp-load-based-limit.adoc
+++ b/modules/hcp-load-based-limit.adoc
@@ -28,23 +28,6 @@ For general sizing purposes, consider the 1000 QPS API rate that is a _medium_ h
 This test provides an estimation factor to increase the compute resource utilization based on the expected API load. Exact utilization rates can vary based on the type and pace of the cluster workload.
 ====
 
-.Load table
-|===
-| Hosted control plane resource utilization scaling | vCPUs | Memory (GiB)
-
-| Resource utilization with no load 
-| 2.9
-| 11.1
-
-| Resource utilization with 1000 QPS
-| 9.0
-| 2.5
-|===
-
-As the load increases by 1000 QPS, the hosted control plane resource utilization increases by 9 vCPUs and 2.5 GB memory. 
-
-For general sizing purposes, consider a 1000 QPS API rate to be a medium hosted cluster load and a 2000 QPS API to be a heavy hosted cluster load.
-
 The following example shows hosted control plane resource scaling for the workload and API rate definitions:
 
 .API rate table
diff --git a/modules/hcp-migrate-aws-multiarch-nodepools.adoc b/modules/hcp-migrate-aws-multiarch-nodepools.adoc
index ce739c8b7c35..f4d817a93bff 100644
--- a/modules/hcp-migrate-aws-multiarch-nodepools.adoc
+++ b/modules/hcp-migrate-aws-multiarch-nodepools.adoc
@@ -15,10 +15,10 @@ After transitioning your hosted cluster from single-architecture to multi-archit
 [source,terminal]
 ----
 $ hcp create nodepool aws \
---cluster-name <hosted_cluster_name> \// <1>
---name <nodepool_name> \// <2>
---node-count=<node_count> \// <3>
---arch arm64
+  --cluster-name <hosted_cluster_name> \// <1>
+  --name <nodepool_name> \// <2>
+  --node-count=<node_count> \// <3>
+  --arch arm64
 ----
 <1> Replace `<hosted_cluster_name>` with your hosted cluster name.
 <2> Replace `<nodepool_name>` with your node pool name.
@@ -29,10 +29,10 @@ $ hcp create nodepool aws \
 [source,terminal]
 ----
 $ hcp create nodepool aws \
---cluster-name <hosted_cluster_name> \// <1>
---name <nodepool_name> \// <2>
---node-count=<node_count> \// <3>
---arch amd64
+  --cluster-name <hosted_cluster_name> \// <1>
+  --name <nodepool_name> \// <2>
+  --node-count=<node_count> \// <3>
+  --arch amd64
 ----
 <1> Replace `<hosted_cluster_name>` with your hosted cluster name.
 <2> Replace `<nodepool_name>` with your node pool name.
diff --git a/modules/hcp-migrate-aws-single-to-multiarch.adoc b/modules/hcp-migrate-aws-single-to-multiarch.adoc
index 9758c0bb4769..e2274ef60c2c 100644
--- a/modules/hcp-migrate-aws-single-to-multiarch.adoc
+++ b/modules/hcp-migrate-aws-single-to-multiarch.adoc
@@ -28,7 +28,8 @@ A single-architecture hosted cluster can manage node pools of only one particula
 +
 [source,terminal]
 ----
-$ oc get hostedcluster/<hosted_cluster_name> -o jsonpath='{.spec.release.image}' <1>
+$ oc get hostedcluster/<hosted_cluster_name> \// <1>
+  -o jsonpath='{.spec.release.image}'
 ----
 +
 <1> Replace `<hosted_cluster_name>` with your hosted cluster name.
@@ -46,14 +47,17 @@ quay.io/openshift-release-dev/ocp-release:<4.y.z>-x86_64 <1>
 +
 [source,terminal]
 ----
-$ OCP_VERSION=$(oc image info quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e -o jsonpath='{.config.config.Labels["io.openshift.release"]}')
+$ OCP_VERSION=$(oc image info quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \
+  -o jsonpath='{.config.config.Labels["io.openshift.release"]}')
 ----
 
 .. Set the `MULTI_ARCH_TAG` environment variable for the multi-architecture tag version of your release image by running the following command:
 +
 [source,terminal]
 ----
-$ MULTI_ARCH_TAG=$(skopeo inspect docker://quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e | jq -r '.RepoTags' | sed 's/"//g' | sed 's/,//g' | grep -w "$OCP_VERSION-multi$" | xargs)
+$ MULTI_ARCH_TAG=$(skopeo inspect docker://quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \
+  | jq -r '.RepoTags' | sed 's/"//g' | sed 's/,//g' \
+  | grep -w "$OCP_VERSION-multi$" | xargs)
 ----
 
 .. Set the `IMAGE` environment variable for the multi-architecture release image name by running the following command:
@@ -86,7 +90,9 @@ linux/arm64   sha256:7b046404572ac96202d82b6cb029b421dddd40e88c73bbf35f602ffc130
 +
 [source,terminal]
 ----
-$ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p '{"spec":{"release":{"image":"quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi"}}}' --type=merge <1>
+$ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p \
+  '{"spec":{"release":{"image":"quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi"}}}' \// <1>
+  --type=merge
 ----
 <1> Replace `<4.y.z>` with the supported {product-title} version that you use.
 
@@ -94,7 +100,8 @@ $ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p '{"spec":{"releas
 +
 [source,terminal]
 ----
-$ oc get hostedcluster/<hosted_cluster_name> -o jsonpath='{.spec.release.image}'
+$ oc get hostedcluster/<hosted_cluster_name> \
+  -o jsonpath='{.spec.release.image}'
 ----
 
 . Check that the status of the `HostedControlPlane` resource is `Progressing` by running the following command:
@@ -121,7 +128,8 @@ $ oc get hostedcontrolplane -n <hosted_control_plane_namespace> -oyaml
 +
 [source,terminal]
 ----
-$ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> -oyaml
+$ oc get hostedcluster <hosted_cluster_name> \
+  -n <hosted_cluster_namespace> -oyaml
 ----
 
 .Verification
diff --git a/modules/hcp-monitor-cp.adoc b/modules/hcp-monitor-cp.adoc
index 93c49b387793..9c0e970ddab8 100644
--- a/modules/hcp-monitor-cp.adoc
+++ b/modules/hcp-monitor-cp.adoc
@@ -26,5 +26,11 @@ $ export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
 +
 [source,terminal]
 ----
-$ watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
+$ watch "oc get pod -n hypershift;echo;echo;\
+  oc get pod -n clusters-hosted-ipv4;echo;echo;\
+  oc get bmh -A;echo;echo;\
+  oc get agent -A;echo;echo;\
+  oc get infraenv -A;echo;echo;\
+  oc get hostedcluster -A;echo;echo;\
+  oc get nodepool -A;echo;echo;"
 ----
\ No newline at end of file
diff --git a/modules/hcp-monitor-dp.adoc b/modules/hcp-monitor-dp.adoc
index 1308863bb594..5821596171e7 100644
--- a/modules/hcp-monitor-dp.adoc
+++ b/modules/hcp-monitor-dp.adoc
@@ -17,7 +17,8 @@ While the deployment proceeds, you can monitor the data plane by gathering infor
 * Enter the following commands:
 +
 ----
-$ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
+$ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig \
+  -o jsonpath='{.data.kubeconfig}' | base64 -d > /root/hc_admin_kubeconfig.yaml
 ----
 +
 ----
diff --git a/modules/hcp-non-bm-dns.adoc b/modules/hcp-non-bm-dns.adoc
index 7e3d7ff0140e..6e3daa1dea2b 100644
--- a/modules/hcp-non-bm-dns.adoc
+++ b/modules/hcp-non-bm-dns.adoc
@@ -14,6 +14,11 @@ The DNS entry can be as simple as a record that points to one of the nodes in th
 +
 [source,text]
 ----
+api.example.krnl.es.        IN A 192.168.122.20
+api.example.krnl.es.        IN A 192.168.122.21
+api.example.krnl.es.        IN A 192.168.122.22
+api-int.example.krnl.es.    IN A 192.168.122.20
+api-int.example.krnl.es.    IN A 192.168.122.21
 api-int.example.krnl.es.    IN A 192.168.122.22
 `*`.apps.example.krnl.es.   IN A 192.168.122.23
 ----
@@ -22,6 +27,11 @@ api-int.example.krnl.es.    IN A 192.168.122.22
 +
 [source,text]
 ----
+api.example.krnl.es.        IN A 2620:52:0:1306::5
+api.example.krnl.es.        IN A 2620:52:0:1306::6
+api.example.krnl.es.        IN A 2620:52:0:1306::7
+api-int.example.krnl.es.    IN A 2620:52:0:1306::5
+api-int.example.krnl.es.    IN A 2620:52:0:1306::6
 api-int.example.krnl.es.    IN A 2620:52:0:1306::7
 `*`.apps.example.krnl.es.   IN A 2620:52:0:1306::10
 ----
@@ -30,7 +40,21 @@ api-int.example.krnl.es.    IN A 2620:52:0:1306::7
 +
 [source,text]
 ----
+host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
+host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
+address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
+dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
+dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
+dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
+dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
+dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26
+
 host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
+host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
 address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
+dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
+dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
+dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
+dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
 ----
diff --git a/modules/hcp-non-bm-hc-mirror.adoc b/modules/hcp-non-bm-hc-mirror.adoc
index 61ec22e3e46e..e57f990c4cbf 100644
--- a/modules/hcp-non-bm-hc-mirror.adoc
+++ b/modules/hcp-non-bm-hc-mirror.adoc
@@ -52,4 +52,4 @@ $ hcp create cluster agent \
 <6> Specify the `icsp.yaml` file that defines ICSP and your mirror registries.
 <7> Specify the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
 <8> Specify your hosted cluster namespace.
-<9> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
+<9> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`. If you are using a disconnected environment, replace `<ocp_release_image>` with the digest image. To extract the {product-title} release image digest, see _Extracting the {product-title} release image digest_.
diff --git a/modules/hcp-non-bm-hc.adoc b/modules/hcp-non-bm-hc.adoc
index aaff76fc467c..de7d24aff0dc 100644
--- a/modules/hcp-non-bm-hc.adoc
+++ b/modules/hcp-non-bm-hc.adoc
@@ -41,7 +41,8 @@ $ hcp create cluster agent \
   --ssh-key  <path_to_ssh_key> \// <7>
   --namespace <hosted_cluster_namespace> \// <8>
   --control-plane-availability-policy HighlyAvailable \// <9>
-  --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> <10>
+  --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> \// <10>
+  --node-pool-replicas <node_pool_replica_count> <11>
 ----
 +
 <1> Specify the name of your hosted cluster, for instance, `example`.
@@ -53,7 +54,8 @@ $ hcp create cluster agent \
 <7> Specify the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
 <8> Specify your hosted cluster namespace.
 <9> Specify the availability policy for the hosted control plane components. Supported options are `SingleReplica` and `HighlyAvailable`. The default value is `HighlyAvailable`.
-<10> Specify the supported {product-title} version that you want to use, for example, `4.17.0-multi`.
+<10> Specify the supported {product-title} version that you want to use, for example, `4.18.0-multi`.
+<11> Specify the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created.
 
 .Verification
 
diff --git a/modules/hcp-non-bm-prereqs.adoc b/modules/hcp-non-bm-prereqs.adoc
index f1f0db5b964a..aa3d4c9bbf24 100644
--- a/modules/hcp-non-bm-prereqs.adoc
+++ b/modules/hcp-non-bm-prereqs.adoc
@@ -10,14 +10,14 @@ Before you deploy {hcp} on non-bare-metal agent machines, ensure you meet the fo
 
 * You must have {mce} 2.5 or later installed on an {product-title} cluster. You can install the {mce-short} as an Operator from the {product-title} OperatorHub.
 
-* You must have at least one managed {product-title} cluster for the {mce-short}. The `local-cluster` management cluster is automatically imported. For more information about the `local-cluster`, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration] in the {rh-rhacm-title} documentation. You can check the status of your management cluster by running the following command:
+* You must have at least one managed {product-title} cluster for the {mce-short}. The `local-cluster` management cluster is automatically imported. For more information about the `local-cluster`, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration] in the {rh-rhacm-title} documentation. You can check the status of your management cluster by running the following command:
 +
 [source,terminal]
 ----
 $ oc get managedclusters local-cluster
 ----
 
-* You have enabled central infrastructure management. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service] in the {rh-rhacm-title} documentation.
+* You have enabled central infrastructure management. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#enable-cim[Enabling the central infrastructure management service] in the {rh-rhacm-title} documentation.
 
 * You have installed the `hcp` command-line interface.
 
diff --git a/modules/hcp-non-bm-verify.adoc b/modules/hcp-non-bm-verify.adoc
index 752e0c18e682..61fd0001bdb6 100644
--- a/modules/hcp-non-bm-verify.adoc
+++ b/modules/hcp-non-bm-verify.adoc
@@ -14,7 +14,9 @@ After the deployment process is complete, you can verify that the hosted cluster
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=- > kubeconfig-<hosted_cluster_name>
+$ oc extract -n <hosted_cluster_namespace> \
+  secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
+  > kubeconfig-<hosted_cluster_name>
 ----
 
 . Use the `kubeconfig` file to view the cluster Operators of the hosted cluster. Enter the following command:
diff --git a/modules/hcp-ocp-differences.adoc b/modules/hcp-ocp-differences.adoc
index 6a1929064f2b..177319058038 100644
--- a/modules/hcp-ocp-differences.adoc
+++ b/modules/hcp-ocp-differences.adoc
@@ -79,7 +79,7 @@
 |{product-title} |{hcp-capital}
 
 |The Cluster Version Operator (CVO) orchestrates the update process and monitors the `ClusterVersion` resource. Administrators and OpenShift components can interact with the CVO through the `ClusterVersion` resource. The `oc adm upgrade` command results in a change to the `ClusterVersion.Spec.DesiredUpdate` field in the `ClusterVersion` resource.
-|The {hcp} update results in a change to the `.spec.release.image` field in the `HostedCluster` and `NodePools` resources. Any changes to the `ClusterVersion` resource are ignored.
+|The {hcp} update results in a change to the `.spec.release.image` field in the `HostedCluster` and `NodePool` resources. Any changes to the `ClusterVersion` resource are ignored.
 
 |After you update an {product-title} cluster, both the control plane and compute machines are updated.
 |After you update the hosted cluster, only the control plane is updated. You perform node pool updates separately.
diff --git a/modules/hcp-override.adoc b/modules/hcp-override.adoc
index fdd8a6c4c21e..cc8cc20b0d7a 100644
--- a/modules/hcp-override.adoc
+++ b/modules/hcp-override.adoc
@@ -38,7 +38,8 @@ data:
 +
 [source,terminal]
 ----
-$ oc delete deployment hypershift-addon-agent -n open-cluster-management-agent-addon
+$ oc delete deployment hypershift-addon-agent \
+  -n open-cluster-management-agent-addon
 ----
 
 .Verification
diff --git a/modules/hcp-proxy-api.adoc b/modules/hcp-proxy-api.adoc
new file mode 100644
index 000000000000..c8ca3f3bbc5c
--- /dev/null
+++ b/modules/hcp-proxy-api.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="hcp-proxy-api_{context}"]
+= Compute nodes that need to access the API server
+
+This use case is relevant to self-managed {hcp}, not to {product-rosa} with {hcp}.
+
+For communication with the control plane, {hcp} uses a local proxy in every compute node that listens on IP address 172.20.0.1 and forwards traffic to the API server. If an external proxy is required to access the API server, that local proxy needs to use the external proxy to send traffic out. When a proxy is not needed, {hcp} uses `haproxy` for the local proxy, which only forwards packets via TCP. When a proxy is needed, {hcp} uses a custom proxy, `control-plane-operator-kubernetes-default-proxy`, to send traffic through the external proxy.
\ No newline at end of file
diff --git a/modules/hcp-proxy-cp-workloads.adoc b/modules/hcp-proxy-cp-workloads.adoc
new file mode 100644
index 000000000000..ce0c68bd447c
--- /dev/null
+++ b/modules/hcp-proxy-cp-workloads.adoc
@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="hcp-proxy-cp-workloads_{context}"]
+= Control plane workloads that need to access external services
+
+Operators that run in the control plane need to access external services through the proxy that is configured for the hosted cluster. The proxy is usually accessible only through the data plane. The control plane workloads are as follows:
+
+* The Control Plane Operator needs to validate and obtain endpoints from certain identity providers when it creates the OAuth server configuration.
+
+* The OAuth server needs non-LDAP identity provider access.
+
+* The OpenShift API server handles image registry metadata import.
+
+* The Ingress Operator needs access to validate external canary routes.
+
+In a hosted cluster, you must send traffic that originates from the Control Plane Operator, Ingress Operator, OAuth server, and OpenShift API server pods through the data plane to the configured proxy and then to its final destination. 
+
+[NOTE]
+====
+Some operations are not possible when a hosted cluster is reduced to zero compute nodes; for example, when you import OpenShift image streams from a registry that requires proxy access.
+====
\ No newline at end of file
diff --git a/modules/hcp-proxy-ignition.adoc b/modules/hcp-proxy-ignition.adoc
new file mode 100644
index 000000000000..bb35880ebfba
--- /dev/null
+++ b/modules/hcp-proxy-ignition.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="hcp-proxy-ignition_{context}"]
+= Compute nodes that need to access an ignition endpoint
+
+When compute nodes need a proxy to access the ignition endpoint, you must configure the proxy in the user-data stub that is configured on the compute node when it is created. For cases where machines need a proxy to access the ignition URL, the proxy configuration is included in the stub.
+
+The stub resembles the following example:
+
+[source,terminal]
+---
+{"ignition":{"config":{"merge":[{"httpHeaders":[{"name":"Authorization","value":"Bearer ..."},{"name":"TargetConfigVersionHash","value":"a4c1b0dd"}],"source":"https://ignition.controlplanehost.example.com/ignition","verification":{}}],"replace":{"verification":{}}},"proxy":{"httpProxy":"http://proxy.example.org:3128", "httpsProxy":"https://proxy.example.org:3129", "noProxy":"host.example.org"},"security":{"tls":{"certificateAuthorities":[{"source":"...","verification":{}}]}},"timeouts":{},"version":"3.2.0"},"passwd":{},"storage":{},"systemd":{}}
+---
\ No newline at end of file
diff --git a/modules/hcp-proxy-mgmt-cluster.adoc b/modules/hcp-proxy-mgmt-cluster.adoc
new file mode 100644
index 000000000000..c429c4ec6680
--- /dev/null
+++ b/modules/hcp-proxy-mgmt-cluster.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="hcp-proxy-mgmt-cluster_{context}"]
+= Management clusters that need external access
+
+The HyperShift Operator has a controller that monitors the OpenShift global proxy configuration of the management cluster and sets the proxy environment variables on its own deployment. Control plane deployments that need external access are configured with the proxy environment variables of the management cluster.
\ No newline at end of file
diff --git a/modules/hcp-support-matrix.adoc b/modules/hcp-support-matrix.adoc
index 5680277a4787..85237fab9090 100644
--- a/modules/hcp-support-matrix.adoc
+++ b/modules/hcp-support-matrix.adoc
@@ -37,6 +37,9 @@ The following table maps {mce-short} versions to the management cluster versions
 
 |4.15 - 4.17
 |2.7
+
+|4.16 - 4.18
+|2.8
 |===
 
 [id="hcp-matrix-hc_{context}"]
@@ -46,44 +49,62 @@ For hosted clusters, no direct relationship exists between the management cluste
 
 [NOTE]
 ====
-Ensure a maximum latency of 200 ms between the management cluster and hosted clusters.
+Ensure a maximum latency of 200 ms between the management cluster and hosted clusters. This requirement is especially important for mixed infrastructure deployments, such as when your management cluster is on {aws-short} and your worker nodes are on-premise.
 ====
 
 The following table maps {mce-short} versions to the hosted cluster versions that you can create by using the HyperShift Operator that is associated with that version of {mce-short}:
 
+[NOTE]
+====
+Although the HyperShift Operator supports the hosted cluster versions in the following table, {mce-short} supports only as far back as 2 versions earlier than the current version. For example, if the current hosted cluster version is 4.18, {mce-short} supports as far back as version 4.16. If you want to use a hosted cluster version that is earlier than one of the versions that {mce-short} supports, you can detach your hosted clusters from {mce-short} to be unmanaged, or you can use an earlier version of {mce-short}. For more information, see link:https://access.redhat.com/articles/7099674[The multicluster engine for Kubernetes operator 2.8 Support Matrix].
+====
+
 .Hosted cluster versions that can be created by {mce-short} versions
-[cols="5",options="header"]
+[cols="6",options="header"]
 |===
-|Hosted cluster version  |{mce-short} 2.4 |{mce-short} 2.5 |{mce-short} 2.6 |{mce-short} 2.7
+|Hosted cluster version |{mce-short} 2.4 |{mce-short} 2.5 |{mce-short} 2.6 |{mce-short} 2.7|{mce-short} 2.8
 
 |4.14
 |Yes
 |Yes
 |Yes
 |Yes
+|Yes
 
 |4.15
 |No
 |Yes
 |Yes
 |Yes
+|Yes
 
 |4.16
 |No
 |No
 |Yes
 |Yes
+|Yes
 
 |4.17
 |No
 |No
 |No
 |Yes
+|Yes
+
+|4.18
+|No
+|No
+|No
+|No
+|Yes
 |===
 
 [id="hcp-matrix-platform_{context}"]
 == Hosted cluster platform support
 
+A hosted cluster supports only one infrastructure platform. For example, you cannot create multiple node pools on different infrastructure platforms.
+
 The following table indicates which {product-title} versions are supported for each platform of {hcp}.
 
 [IMPORTANT]
@@ -91,7 +112,7 @@ The following table indicates which {product-title} versions are supported for e
 For {ibm-power-title} and {ibm-z-title}, you must run the control plane on machine types based on 64-bit x86 architecture, and node pools on {ibm-power-title} or {ibm-z-title}.
 ====
 
-In the following table, Management cluster version refers to the {product-title} version where the {mce-short} is enabled:
+In the following table, the management cluster version is the {product-title} version where the {mce-short} is enabled:
 
 .Required {product-title} versions for platforms
 [cols="3",options="header"]
@@ -99,34 +120,39 @@ In the following table, Management cluster version refers to the {product-title}
 |Hosted cluster platform |Management cluster version |Hosted cluster version
 
 |{aws-full}
-|4.16 - 4.17
-|4.16 - 4.17
+|4.16 - 4.18
+|4.16 - 4.18
 
 |{ibm-power-title}
-|4.17
-|4.17
+|4.17 - 4.18
+|4.17 - 4.18
 
 |{ibm-z-title}
-|4.17
-|4.17
+|4.17 - 4.18
+|4.17 - 4.18
 
 |{VirtProductName}
-|4.14 - 4.17
-|4.14 - 4.17
+|4.14 - 4.18
+|4.14 - 4.18
 
 |Bare metal
-|4.14 - 4.17
-|4.14 - 4.17
+|4.14 - 4.18
+|4.14 - 4.18
 
 |Non-bare-metal agent machines (Technology Preview)
-|4.16 - 4.17
-|4.16 - 4.17
+|4.16 - 4.18
+|4.16 - 4.18
 |===
 
 [id="hcp-matrix-updates_{context}"]
 == Updates of {mce-short}
 
-When you update to another version of the {mce-short}, your hosted cluster can continue to run if the HyperShift Operator that is included in the version of {mce-short} supports the hosted cluster version. The following table shows which hosted cluster versions are supported on which updated {mce-short} versions:
+When you update to another version of the {mce-short}, your hosted cluster can continue to run if the HyperShift Operator that is included in the version of {mce-short} supports the hosted cluster version. The following table shows which hosted cluster versions are supported on which updated {mce-short} versions.
+
+[NOTE]
+====
+Although the HyperShift Operator supports the hosted cluster versions in the following table, {mce-short} supports only as far back as 2 versions earlier than the current version. For example, if the current hosted cluster version is 4.18, {mce-short} supports as far back as version 4.16. If you want to use a hosted cluster version that is earlier than one of the versions that {mce-short} supports, you can detach your hosted clusters from {mce-short} to be unmanaged, or you can use an earlier version of {mce-short}. For more information, see link:https://access.redhat.com/articles/7099674[The multicluster engine for Kubernetes operator 2.8 Support Matrix].
+====
 
 .Updated {mce-short} version support for hosted clusters
 [cols="2",options="header"]
@@ -141,6 +167,9 @@ When you update to another version of the {mce-short}, your hosted cluster can c
 
 |Updated from 2.6 to 2.7
 |{product-title} 4.14 - 4.16
+
+|Updated from 2.7 to 2.8
+|{product-title} 4.14 - 4.17
 |===
 
 For example, if you have an {product-title} 4.14 hosted cluster on the management cluster and you update from {mce-short} 2.4 to 2.5, the hosted cluster can continue to run.
@@ -152,4 +181,4 @@ The following list indicates Technology Preview features for this release:
 
 * {hcp-capital} on {ibm-z-title} in a disconnected environment
 * Custom taints and tolerations for {hcp} on {VirtProductName}
-* NVIDIA GPU devices on {hcp} for {VirtProductName}
+* NVIDIA GPU devices on {hcp} for {VirtProductName}
\ No newline at end of file
diff --git a/modules/hcp-ts-bm-nodes-not-added.adoc b/modules/hcp-ts-bm-nodes-not-added.adoc
new file mode 100644
index 000000000000..cd956654297f
--- /dev/null
+++ b/modules/hcp-ts-bm-nodes-not-added.adoc
@@ -0,0 +1,39 @@
+// Module included in the following assemblies:
+//
+// * hosted_control_planes/hcp-troubleshooting.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="hcp-ts-bm-nodes-not-added_{context}"]
+= Nodes fail to be added to {hcp} on bare metal
+
+When you scale up a {hcp} cluster with nodes that were provisioned by using Assisted Installer, the host fails to pull the ignition with a URL that contains port 22642. That URL is invalid for {hcp} and indicates that an issue exists with the cluster.
+
+.Procedure
+
+. To determine the issue, review the assisted-service logs:
++
+[source,terminal]
+----
+$ oc logs -n multicluster-engine <assisted_service_pod_name> <1>
+----
++
+<1> Specify the Assisted Service pod name.
+
+. In the logs, find errors that resemble these examples:
++
+[source,terminal]
+----
+error="failed to get pull secret for update: invalid pull secret data in secret pull-secret"
+----
++
+[source,terminal]
+----
+pull secret must contain auth for \"registry.redhat.io\"
+----
+
+. To fix this issue, see "Add the pull secret to the namespace" in the {mce} documentation.
++
+[NOTE]
+====
+To use {hcp}, you must have {mce-short} installed, either as a standalone operator or as part of {rh-rhacm-title}. Because the operator has a close association with {rh-rhacm-title}, the documentation for the operator is published within that product's documentation. Even if you do not use {rh-rhacm-title}, the parts of its documentation that cover {mce-short} are relevant to {hcp}.
+====
\ No newline at end of file
diff --git a/modules/hcp-ts-load-balancer-svcs.adoc b/modules/hcp-ts-load-balancer-svcs.adoc
index e76b2653fd08..18d396528769 100644
--- a/modules/hcp-ts-load-balancer-svcs.adoc
+++ b/modules/hcp-ts-load-balancer-svcs.adoc
@@ -16,5 +16,6 @@ If a hosted control plane is not coming fully online because the load balancer s
 +
 [source,terminal]
 ----
-$ oc get pods -n <hosted_control_plane_namespace> -l app=cloud-controller-manager
+$ oc get pods -n <hosted_control_plane_namespace> \
+  -l app=cloud-controller-manager
 ----
\ No newline at end of file
diff --git a/modules/hcp-ts-nodes-stuck.adoc b/modules/hcp-ts-nodes-stuck.adoc
index c9a153d8d3fa..c44ce22f43da 100644
--- a/modules/hcp-ts-nodes-stuck.adoc
+++ b/modules/hcp-ts-nodes-stuck.adoc
@@ -6,22 +6,20 @@
 [id="hcp-ts-nodes-stuck_{context}"]
 = Worker nodes are stuck in the NotReady state
 
-During cluster creation, nodes enter the `NotReady` state temporarily while the networking stack is rolled out. This part of the process is normal. However, if this part of the process takes longer than 15 minutes, an issue might have occurred.
+During cluster creation, nodes enter the `NotReady` state temporarily while the networking stack is rolled out. This part of the process is normal. However, if this part of the process takes longer than 15 minutes, identify the problem by investigating the node object and pods.
 
 .Procedure
 
-Identify the problem by investigating the node object and pods:
-
-* Enter the following command to view the conditions on the node object and determine why the node is not ready:
+. Enter the following command to view the conditions on the node object and determine why the node is not ready:
 +
 [source,terminal]
 ----
 $ oc get nodes -o yaml
 ----
 
-* Enter the following command to look for failing pods within the cluster:
+. Enter the following command to look for failing pods within the cluster:
 +
 [source,terminal]
 ----
 $ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
-----
\ No newline at end of file
+----
diff --git a/modules/hcp-ts-pvcs-not-avail.adoc b/modules/hcp-ts-pvcs-not-avail.adoc
index f5bae0b96d29..10380d83d8d9 100644
--- a/modules/hcp-ts-pvcs-not-avail.adoc
+++ b/modules/hcp-ts-pvcs-not-avail.adoc
@@ -16,7 +16,8 @@ If a hosted control plane is not coming fully online because the persistent volu
 +
 [source,terminal]
 ----
-$ oc get pods -n openshift-cluster-csi-drivers -o wide -l app=kubevirt-csi-driver
+$ oc get pods -n openshift-cluster-csi-drivers -o wide \
+  -l app=kubevirt-csi-driver
 ----
 
 * If a PVC cannot bind to a persistent volume (PV), view the logs of the kubevirt-csi-controller component within the hosted control plane namespace. To identify the kubevirt-csi-controller pod within the hosted control plane namespace, enter the following command:
diff --git a/modules/hcp-ts-rhcos.adoc b/modules/hcp-ts-rhcos.adoc
index 003e165a5a99..da869e363696 100644
--- a/modules/hcp-ts-rhcos.adoc
+++ b/modules/hcp-ts-rhcos.adoc
@@ -16,7 +16,8 @@ To resolve this issue, manually mirror the {op-system} image to the internal reg
 +
 [source,terminal]
 ----
-$ oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
+$ oc get imagecontentsourcepolicy -o json \
+  | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
 ----
 
 . Get a payload image by running the following command:
@@ -30,14 +31,17 @@ $ oc get clusterversion version -ojsonpath='{.status.desired.image}'
 +
 [source,terminal]
 ----
-$ oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirm
+$ oc image extract \
+  --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \
+  <payload_image> --confirm
 ----
 
 . Get the {op-system} image by running the following command:
 +
 [source,terminal]
 ----
-$ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
+$ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \
+  | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
 ----
 
 . Mirror the {op-system} image to your internal registry. Replace `<rhcos_image>` with your {op-system} image; for example, `quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdf71bfd93ba229141d134a4a6dd94`. Replace `<internal_registry>` with the name of your internal registry; for example, `virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev`. Run the following command:
diff --git a/modules/hcp-uninstall-operator.adoc b/modules/hcp-uninstall-operator.adoc
index cfd6bd9bb70b..dabd66a268c1 100644
--- a/modules/hcp-uninstall-operator.adoc
+++ b/modules/hcp-uninstall-operator.adoc
@@ -25,7 +25,8 @@ If a hosted cluster is running, the HyperShift Operator does not uninstall, even
 +
 [source,terminal]
 ----
-$ oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}' <1>
+$ oc patch mce multiclusterengine --type=merge -p \// <1>
+  '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'
 ----
 +
 <1> The default `MultiClusterEngine` resource instance name is `multiclusterengine`, but you can get the `MultiClusterEngine` name from your cluster by running the following command: `$ oc get mce`.
diff --git a/modules/hcp-update-node-pools.adoc b/modules/hcp-update-node-pools.adoc
index ac9bc58b37b2..57b6a707cf45 100644
--- a/modules/hcp-update-node-pools.adoc
+++ b/modules/hcp-update-node-pools.adoc
@@ -16,7 +16,9 @@ The `.spec.release` field in the `NodePool` custom resource (CR) shows the versi
 +
 [source,terminal]
 ----
-$ oc patch nodepool <node_pool_name> -n <hosted_cluster_namespace> --type=merge -p '{"spec":{"nodeDrainTimeout":"60s","release":{"image":"<openshift_release_image>"}}}' <1> <2>
+$ oc patch nodepool <node_pool_name> -n <hosted_cluster_namespace> \// <1>
+  --type=merge \
+  -p '{"spec":{"nodeDrainTimeout":"60s","release":{"image":"<openshift_release_image>"}}}' <2>
 ----
 +
 <1> Replace `<node_pool_name>` and `<hosted_cluster_namespace>` with your node pool name and hosted cluster namespace, respectively.
diff --git a/modules/hcp-update-ocp-hc.adoc b/modules/hcp-update-ocp-hc.adoc
index ff895979513a..6f71557daed2 100644
--- a/modules/hcp-update-ocp-hc.adoc
+++ b/modules/hcp-update-ocp-hc.adoc
@@ -26,7 +26,10 @@ You can set the `.spec.release` field in the `HostedCluster` CR to update the co
 +
 [source,terminal]
 ----
-$ oc annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" --overwrite <1> <2>
+$ oc annotate hostedcluster \
+  -n <hosted_cluster_namespace> <hosted_cluster_name> \// <1>
+  "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" \// <2>
+  --overwrite
 ----
 +
 <1> Replace `<hosted_cluster_name>` and `<hosted_cluster_namespace>` with your hosted cluster name and hosted cluster namespace, respectively.
@@ -37,7 +40,9 @@ $ oc annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name>
 +
 [source,terminal]
 ----
-$ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> --type=merge -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'
+$ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \
+  --type=merge \
+  -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'
 ----
 
 
@@ -47,7 +52,8 @@ $ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> --t
 +
 [source,terminal]
 ----
-$ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> -o yaml
+$ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> \
+  -o yaml
 ----
 +
 .Example output
diff --git a/modules/hcp-updates-hosted-cluster.adoc b/modules/hcp-updates-hosted-cluster.adoc
index 1d120b53cd12..9fb2168825e6 100644
--- a/modules/hcp-updates-hosted-cluster.adoc
+++ b/modules/hcp-updates-hosted-cluster.adoc
@@ -6,7 +6,7 @@
 [id="hcp-updates-hosted-cluster_{context}"]
 = Updates for the hosted cluster
 
-The `spec.release` value dictates the version of the control plane. The `HostedCluster` object transmits the intended `spec.release` value to the `HostedControlPlane.spec.release` value and runs the appropriate Control Plane Operator version.
+The `spec.release.image` value dictates the version of the control plane. The `HostedCluster` object transmits the intended `spec.release.image` value to the `HostedControlPlane.spec.releaseImage` value and runs the appropriate Control Plane Operator version.
 
 The hosted control plane manages the rollout of the new version of the control plane components along with any {product-title} components through the new version of the Cluster Version Operator (CVO).
 
@@ -17,4 +17,4 @@ In {hcp}, the `NodeHealthCheck` resource cannot detect the status of the CVO. A
 To pause the remediation, enter the array of strings, for example, `pause-test-cluster`, as a value of the `pauseRequests` field in the `NodeHealthCheck` resource. For more information, see link:https://docs.redhat.com/en/documentation/workload_availability_for_red_hat_openshift/24.4/html/remediation_fencing_and_maintenance/node-health-check-operator#about-node-health-check-operator_node-health-check-operator[About the Node Health Check Operator].
 
 After the cluster update is complete, you can edit or delete the remediation. Navigate to the *Compute* -> *NodeHealthCheck* page, click your node health check, and then click *Actions*, which shows a drop-down list.
-====
+====
\ No newline at end of file
diff --git a/modules/hcp-virt-access.adoc b/modules/hcp-virt-access.adoc
index e08345757e4b..2c199a2aa13a 100644
--- a/modules/hcp-virt-access.adoc
+++ b/modules/hcp-virt-access.adoc
@@ -34,7 +34,8 @@ The `kubeadmin` password secret is also Base64-encoded. You can decode it and us
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
+  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After you save the `kubeconfig` file, you can access the hosted cluster by entering the following example command:
diff --git a/modules/hcp-virt-add-node.adoc b/modules/hcp-virt-add-node.adoc
index d7485f96847d..410259b5348a 100644
--- a/modules/hcp-virt-add-node.adoc
+++ b/modules/hcp-virt-add-node.adoc
@@ -40,11 +40,11 @@ $ oc get nodepools --namespace clusters
 [source,terminal]
 ----
 NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
-example                   example         5               5               False         False        4.x.0
+example                   example         5               5               False         False        <4.x.0>
 example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available
 ----
 +
-Replace `4.x.0` with the supported {product-title} version that you want to use.
+Replace `<4.x.0>` with the supported {product-title} version that you want to use.
 
 . After some time, you can check the status of the node pool by entering the following command:
 +
@@ -77,8 +77,8 @@ $ oc get nodepools --namespace clusters
 [source,terminal]
 ----
 NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
-example                   example         5               5               False         False        4.x.0
-example-extra-cpu         example         2               2               False         False        4.x.0
+example                   example         5               5               False         False        <4.x.0>
+example-extra-cpu         example         2               2               False         False        <4.x.0>
 ----
 +
-Replace `4.x.0` with the supported {product-title} version that you want to use.
\ No newline at end of file
+Replace `<4.x.0>` with the supported {product-title} version that you want to use.
diff --git a/modules/hcp-virt-create-hc-cli.adoc b/modules/hcp-virt-create-hc-cli.adoc
index 30952679e8d7..9888aff6d73f 100644
--- a/modules/hcp-virt-create-hc-cli.adoc
+++ b/modules/hcp-virt-create-hc-cli.adoc
@@ -7,25 +7,25 @@
 [id="hcp-virt-create-hc-cli_{context}"]
 = Creating a hosted cluster with the KubeVirt platform by using the CLI
 
-To create a hosted cluster, you can use the hosted control plane command line interface, `hcp`.
+To create a hosted cluster, you can use the hosted control plane command-line interface, `hcp`.
 
 .Procedure
 
-. Enter the following command:
+. Create a hosted cluster with the KubeVirt platform by entering the following command:
 +
 [source,terminal]
 ----
 $ hcp create cluster kubevirt \
-  --name <hosted-cluster-name> \ <1>
-  --node-pool-replicas <worker-count> \ <2>
-  --pull-secret <path-to-pull-secret> \ <3>
-  --memory <value-for-memory> \ <4>
-  --cores <value-for-cpu> \ <5>
-  --etcd-storage-class=<etcd-storage-class> <6>
+  --name <hosted_cluster_name> \// <1>
+  --node-pool-replicas <node_pool_replica_count> \// <2>
+  --pull-secret <path_to_pull_secret> \// <3>
+  --memory <value_for_memory> \// <4>
+  --cores <value_for_cpu> \// <5>
+  --etcd-storage-class=<etcd_storage_class> <6>
 ----
 +
 <1> Specify the name of your hosted cluster, for instance, `example`.
-<2> Specify the worker count, for example, `2`.
+<2> Specify the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created.
 <3> Specify the path to your pull secret, for example, `/user/name/pullsecret`.
 <4> Specify a value for memory, for example, `6Gi`.
 <5> Specify a value for CPU, for example, `2`.
@@ -72,7 +72,7 @@ See the following example output, which illustrates a fully provisioned `HostedC
 +
 ----
 NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
-clusters    example   4.x.0     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
+clusters    example   <4.x.0>     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
 ----
 +
-Replace `4.x.0` with the supported {product-title} version that you want to use.
\ No newline at end of file
+Replace `<4.x.0>` with the supported {product-title} version that you want to use.
diff --git a/modules/hcp-virt-hc-base-domain.adoc b/modules/hcp-virt-hc-base-domain.adoc
index f728f3a0ea47..59656176f283 100644
--- a/modules/hcp-virt-hc-base-domain.adoc
+++ b/modules/hcp-virt-hc-base-domain.adoc
@@ -50,7 +50,8 @@ example                   example-admin-kubeconfig         Partial    True
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
+$ hcp create kubeconfig --name <hosted_cluster_name> \
+  > <hosted_cluster_name>-kubeconfig
 ----
 +
 [source,terminal]
@@ -62,11 +63,11 @@ $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
 [source,terminal]
 ----
 NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
-console                                    4.x.0     False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
-ingress                                    4.x.0     True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
+console                                    <4.x.0>     False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
+ingress                                    <4.x.0>     True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
 ----
 +
-Replace `4.x.0` with the supported {product-title} version that you want to use.
+Replace `<4.x.0>` with the supported {product-title} version that you want to use.
 
 .Next steps
 
@@ -75,4 +76,4 @@ To fix the errors in the output, complete the steps in "Setting up the load bala
 [NOTE]
 ====
 If your hosted cluster is on bare metal, you might need MetalLB to set up load balancer services. For more information, see "Configuring MetalLB".
-====
\ No newline at end of file
+====
diff --git a/modules/hcp-virt-ingress-dns.adoc b/modules/hcp-virt-ingress-dns.adoc
index 9691d11387da..938148146382 100644
--- a/modules/hcp-virt-ingress-dns.adoc
+++ b/modules/hcp-virt-ingress-dns.adoc
@@ -30,7 +30,9 @@ For the default ingress DNS to work properly, the cluster that hosts the KubeVir
 +
 [source,terminal]
 ----
-$ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
+$ oc patch ingresscontroller -n openshift-ingress-operator default \
+  --type=json \
+  -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
 ----
 
 [NOTE]
diff --git a/modules/hcp-virt-load-balancer.adoc b/modules/hcp-virt-load-balancer.adoc
index dd51db7674a5..079993f71602 100644
--- a/modules/hcp-virt-load-balancer.adoc
+++ b/modules/hcp-virt-load-balancer.adoc
@@ -16,7 +16,9 @@ Set up the load balancer service that routes ingress traffic to the KubeVirt VMs
 +
 [source,terminal]
 ----
-$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
+$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
+  -n openshift-ingress router-nodeport-default \
+  -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
 ----
 +
 Note the HTTP node port value to use in the next step.
@@ -25,7 +27,9 @@ Note the HTTP node port value to use in the next step.
 +
 [source,terminal]
 ----
-$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
+$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
+  -n openshift-ingress router-nodeport-default \
+  -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
 ----
 +
 Note the HTTPS node port value to use in the next step.
diff --git a/modules/hcp-virt-prereqs.adoc b/modules/hcp-virt-prereqs.adoc
index 6d06b2a127d8..33a930d64676 100644
--- a/modules/hcp-virt-prereqs.adoc
+++ b/modules/hcp-virt-prereqs.adoc
@@ -13,7 +13,9 @@ You must meet the following prerequisites to create an {product-title} cluster o
 +
 [source,terminal]
 ----
-$ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
+$ oc patch ingresscontroller -n openshift-ingress-operator default \
+  --type=json \
+  -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
 ----
 * The {product-title} management cluster has {VirtProductName}, version 4.14 or later, installed on it. For more information, see "Installing OpenShift Virtualization using the web console".
 * The {product-title} management cluster is on-premise bare metal.
@@ -22,7 +24,8 @@ $ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -
 +
 [source,terminal]
 ----
-$ oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
+$ oc patch storageclass ocs-storagecluster-ceph-rbd \
+  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
 ----
 
 * You have a valid pull secret file for the `quay.io/openshift-release-dev` repository. For more information, see "Install OpenShift on any x86_64 platform with user-provisioned infrastructure".
diff --git a/modules/hcp-virt-scale-nodepool.adoc b/modules/hcp-virt-scale-nodepool.adoc
index 03917083fccd..6be687c08489 100644
--- a/modules/hcp-virt-scale-nodepool.adoc
+++ b/modules/hcp-virt-scale-nodepool.adoc
@@ -17,7 +17,8 @@ You can manually scale a node pool by using the `oc scale` command.
 NODEPOOL_NAME=${CLUSTER_NAME}-work
 NODEPOOL_REPLICAS=5
 
-$ oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
+$ oc scale nodepool/$NODEPOOL_NAME --namespace clusters \
+  --replicas=$NODEPOOL_REPLICAS
 ----
 
 . After a few moments, enter the following command to see the status of the node pool:
diff --git a/modules/hcp-virt-verify-hc.adoc b/modules/hcp-virt-verify-hc.adoc
index 68e577075473..02b3e684c601 100644
--- a/modules/hcp-virt-verify-hc.adoc
+++ b/modules/hcp-virt-verify-hc.adoc
@@ -28,7 +28,8 @@ clusters    example   4.12.2    example-admin-kubeconfig   Completed   True
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
+$ hcp create kubeconfig --name <hosted_cluster_name> \
+  > <hosted_cluster_name>-kubeconfig
 ----
 +
 [source,terminal]
diff --git a/modules/hcp-virt-wildcard-dns.adoc b/modules/hcp-virt-wildcard-dns.adoc
index 27c588676768..f023b93c4891 100644
--- a/modules/hcp-virt-wildcard-dns.adoc
+++ b/modules/hcp-virt-wildcard-dns.adoc
@@ -14,7 +14,8 @@ Set up a wildcard DNS record or CNAME that references the external IP of the loa
 +
 [source,terminal]
 ----
-$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
+$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \
+  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
 ----
 +
 .Example output
@@ -51,7 +52,7 @@ $ oc get --namespace clusters hostedclusters
 [source,terminal]
 ----
 NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
-example         4.x.0     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available
+example         <4.x.0>     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available
 ----
 +
-Replace `4.x.0` with the supported {product-title} version that you want to use.
\ No newline at end of file
+Replace `<4.x.0>` with the supported {product-title} version that you want to use.
diff --git a/modules/hibernating-cluster-about.adoc b/modules/hibernating-cluster-about.adoc
new file mode 100644
index 000000000000..7b88dcc63c33
--- /dev/null
+++ b/modules/hibernating-cluster-about.adoc
@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/hibernating-cluster.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="hibernating-cluster-about_{context}"]
+= About cluster hibernation
+
+{product-title} clusters can be hibernated in order to save money on cloud hosting costs. You can hibernate your {product-title} cluster for up to 90 days and expect it to resume successfully.
+
+You must wait at least 24 hours after cluster installation before hibernating your cluster to allow for the first certification rotation.
+
+[IMPORTANT]
+====
+If you must hibernate your cluster before the 24 hour certificate rotation, use the following procedure instead: link:https://www.redhat.com/en/blog/enabling-openshift-4-clusters-to-stop-and-resume-cluster-vms[Enabling OpenShift 4 Clusters to Stop and Resume Cluster VMs].
+====
+
+When hibernating a cluster, you must hibernate all cluster nodes. It is not supported to suspend only certain nodes.
+
+After resuming, it can take up to 45 minutes for the cluster to become ready.
diff --git a/modules/hibernating-cluster-hibernate.adoc b/modules/hibernating-cluster-hibernate.adoc
new file mode 100644
index 000000000000..cc1a7eb97f38
--- /dev/null
+++ b/modules/hibernating-cluster-hibernate.adoc
@@ -0,0 +1,97 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/hibernating-cluster.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="hibernating-cluster-hibernate_{context}"]
+= Hibernating a cluster
+
+You can hibernate a cluster for up to 90 days. The cluster can recover if certificates expire while the cluster was in hibernation.
+
+.Prerequisites
+
+* The cluster has been running for at least 24 hours to allow the first certificate rotation to complete.
++
+[IMPORTANT]
+====
+If you must hibernate your cluster before the 24 hour certificate rotation, use the following procedure instead: link:https://www.redhat.com/en/blog/enabling-openshift-4-clusters-to-stop-and-resume-cluster-vms[Enabling OpenShift 4 Clusters to Stop and Resume Cluster VMs].
+====
+
+* You have taken an etcd backup.
+
+* You have access to the cluster as a user with the `cluster-admin` role.
+
+.Procedure
+
+. Confirm that your cluster has been installed for at least 24 hours.
+
+. Ensure that all nodes are in a good state by running the following command:
++
+[source,terminal]
+----
+$ oc get nodes
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                      STATUS  ROLES                 AGE   VERSION
+ci-ln-812tb4k-72292-8bcj7-master-0        Ready	  control-plane,master  32m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-master-1        Ready	  control-plane,master  32m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-master-2        Ready	  control-plane,master  32m   v1.31.3
+Ci-ln-812tb4k-72292-8bcj7-worker-a-zhdvk  Ready	  worker                19m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-worker-b-9hrmv  Ready	  worker                19m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2  Ready	  worker                19m   v1.31.3
+----
++
+All nodes should show `Ready` in the `STATUS` column.
+
+. Ensure that all cluster Operators are in a good state by running the following command:
++
+[source,terminal]
+----
+$ oc get clusteroperators
+----
++
+.Example output
+[source,terminal]
+----
+NAME                      VERSION   AVAILABLE  PROGRESSING  DEGRADED  SINCE   MESSAGE
+authentication            4.18.0-0  True       False        False     51m
+baremetal                 4.18.0-0  True       False        False     72m
+cloud-controller-manager  4.18.0-0  True       False        False     75m
+cloud-credential          4.18.0-0  True       False        False     77m
+cluster-api               4.18.0-0  True       False        False     42m
+cluster-autoscaler        4.18.0-0  True       False        False     72m
+config-operator           4.18.0-0  True       False        False     72m
+console                   4.18.0-0  True       False        False     55m
+...
+----
++
+All cluster Operators should show `AVAILABLE`=`True`, `PROGRESSING`=`False`, and `DEGRADED`=`False`.
+
+. Ensure that all machine config pools are in a good state by running the following command:
++
+[source,terminal]
+----
+$ oc get mcp
+----
++
+.Example output
+[source,terminal]
+----
+NAME    CONFIG                                            UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
+master  rendered-master-87871f187930e67233c837e1d07f49c7  True     False     False     3             3                  3                    0                     96m
+worker  rendered-worker-3c4c459dc5d90017983d7e72928b8aed  True     False     False     3             3                  3                    0                     96m
+----
++
+All machine config pools should show `UPDATING`=`False` and `DEGRADED`=`False`.
+
+. Stop the cluster virtual machines:
++
+Use the tools native to your cluster's cloud environment to shut down the cluster's virtual machines.
++
+[IMPORTANT]
+====
+If you use a bastion virtual machine, do not shut down this virtual machine.
+====
diff --git a/modules/hibernating-cluster-resume.adoc b/modules/hibernating-cluster-resume.adoc
new file mode 100644
index 000000000000..8d490adcc3fe
--- /dev/null
+++ b/modules/hibernating-cluster-resume.adoc
@@ -0,0 +1,118 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/hibernating-cluster.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="hibernating-cluster-resume_{context}"]
+= Resuming a hibernated cluster
+
+When you resume a hibernated cluster within 90 days, you might have to approve certificate signing requests (CSRs) for the nodes to become ready.
+
+It can take around 45 minutes for the cluster to resume, depending on the size of your cluster.
+
+.Prerequisites
+
+* You hibernated your cluster less than 90 days ago.
+* You have access to the cluster as a user with the `cluster-admin` role.
+
+.Procedure
+
+. Within 90 days of cluster hibernation, resume the cluster virtual machines:
++
+Use the tools native to your cluster's cloud environment to resume the cluster's virtual machines.
+
+. Wait about 5 minutes, depending on the number of nodes in your cluster.
+
+. Approve CSRs for the nodes:
+
+.. Check that there is a CSR for each node in the `NotReady` state:
++
+[source,terminal]
+----
+$ oc get csr
+----
++
+.Example output
+[source,terminal]
+----
+NAME       AGE  SIGNERNAME                                   REQUESTOR                                                                  REQUESTEDDURATION  CONDITION
+csr-4dwsd  37m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2                       24h                Pending
+csr-4vrbr  49m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             24h                Pending
+csr-4wk5x  51m  kubernetes.io/kubelet-serving                system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             <none>             Pending
+csr-84vb6  51m  kubernetes.io/kube-apiserver-client-kubelet  system:serviceaccount:openshift-machine-config-operator:node-bootstrapper  <none>             Pending
+----
+
+.. Approve each valid CSR by running the following command:
++
+[source,terminal]
+----
+$ oc adm certificate approve <csr_name>
+----
+
+.. Verify that all necessary CSRs were approved by running the following command:
++
+[source,terminal]
+----
+$ oc get csr
+----
++
+.Example output
+[source,terminal]
+----
+NAME       AGE  SIGNERNAME                                   REQUESTOR                                                                  REQUESTEDDURATION  CONDITION
+csr-4dwsd  37m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2                       24h                Approved,Issued
+csr-4vrbr  49m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             24h                Approved,Issued
+csr-4wk5x  51m  kubernetes.io/kubelet-serving                system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             <none>             Approved,Issued
+csr-84vb6  51m  kubernetes.io/kube-apiserver-client-kubelet  system:serviceaccount:openshift-machine-config-operator:node-bootstrapper  <none>             Approved,Issued
+----
++
+CSRs should show `Approved,Issued` in the `CONDITION` column.
+
+. Verify that all nodes now show as ready by running the following command:
++
+[source,terminal]
+----
+$ oc get nodes
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                      STATUS  ROLES                 AGE   VERSION
+ci-ln-812tb4k-72292-8bcj7-master-0        Ready	  control-plane,master  32m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-master-1        Ready	  control-plane,master  32m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-master-2        Ready	  control-plane,master  32m   v1.31.3
+Ci-ln-812tb4k-72292-8bcj7-worker-a-zhdvk  Ready	  worker                19m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-worker-b-9hrmv  Ready	  worker                19m   v1.31.3
+ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2  Ready	  worker                19m   v1.31.3
+----
++
+All nodes should show `Ready` in the `STATUS` column. It might take a few minutes for all nodes to become ready after approving the CSRs.
+
+. Wait for cluster Operators to restart to load the new certificates.
++
+This might take 5 or 10 minutes.
+
+. Verify that all cluster Operators are in a good state by running the following command:
++
+[source,terminal]
+----
+$ oc get clusteroperators
+----
++
+.Example output
+[source,terminal]
+----
+NAME                      VERSION   AVAILABLE  PROGRESSING  DEGRADED  SINCE   MESSAGE
+authentication            4.18.0-0  True       False        False     51m
+baremetal                 4.18.0-0  True       False        False     72m
+cloud-controller-manager  4.18.0-0  True       False        False     75m
+cloud-credential          4.18.0-0  True       False        False     77m
+cluster-api               4.18.0-0  True       False        False     42m
+cluster-autoscaler        4.18.0-0  True       False        False     72m
+config-operator           4.18.0-0  True       False        False     72m
+console                   4.18.0-0  True       False        False     55m
+...
+----
++
+All cluster Operators should show `AVAILABLE`=`True`, `PROGRESSING`=`False`, and `DEGRADED`=`False`.
diff --git a/modules/hosted-cluster-etcd-backup-restore-on-premise.adoc b/modules/hosted-cluster-etcd-backup-restore-on-premise.adoc
index 7d5e6f894f7e..7036dbb9ab49 100644
--- a/modules/hosted-cluster-etcd-backup-restore-on-premise.adoc
+++ b/modules/hosted-cluster-etcd-backup-restore-on-premise.adoc
@@ -19,7 +19,7 @@ This procedure requires API downtime.
 
 .Procedure
 
-. First, set up your environment variables and scale down the API servers:
+. First, set up your environment variables:
 
 .. Set up environment variables for your hosted cluster by entering the following commands, replacing values as necessary:
 +
@@ -42,30 +42,8 @@ $ CONTROL_PLANE_NAMESPACE="${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}"
 +
 [source,terminal]
 ----
-$ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"true"}}' --type=merge
-----
-
-.. Scale down the API servers by entering the following commands:
-+
-... Scale down the `kube-apiserver`:
-+
-[source,terminal]
-----
-$ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/kube-apiserver --replicas=0
-----
-
-... Scale down the `openshift-apiserver`:
-+
-[source,terminal]
-----
-$ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/openshift-apiserver --replicas=0
-----
-
-... Scale down the `openshift-oauth-apiserver`:
-+
-[source,terminal]
-----
-$ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/openshift-oauth-apiserver --replicas=0
+$ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \
+  -p '{"spec":{"pausedUntil":"true"}}' --type=merge
 ----
 
 . Next, take a snapshot of etcd by using one of the following methods:
@@ -89,26 +67,30 @@ $ ETCD_POD=etcd-0
 +
 [source,terminal]
 ----
-$ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- env ETCDCTL_API=3 /usr/bin/etcdctl \
---cacert /etc/etcd/tls/etcd-ca/ca.crt \
---cert /etc/etcd/tls/client/etcd-client.crt \
---key /etc/etcd/tls/client/etcd-client.key \
---endpoints=https://localhost:2379 \
-snapshot save /var/lib/snapshot.db
+$ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \
+  env ETCDCTL_API=3 /usr/bin/etcdctl \
+  --cacert /etc/etcd/tls/etcd-ca/ca.crt \
+  --cert /etc/etcd/tls/client/etcd-client.crt \
+  --key /etc/etcd/tls/client/etcd-client.key \
+  --endpoints=https://localhost:2379 \
+  snapshot save /var/lib/snapshot.db
 ----
 
 ... Verify that the snapshot is successful by entering the following command:
 +
 [source,terminal]
 ----
-$ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/snapshot.db
+$ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \
+  env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \
+  /var/lib/snapshot.db
 ----
 
 .. Make a local copy of the snapshot by entering the following command:
 +
 [source,terminal]
 ----
-$ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db /tmp/etcd.snapshot.db
+$ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db \
+  /tmp/etcd.snapshot.db
 ----
 
 ... Make a copy of the snapshot database from etcd persistent storage:
@@ -124,7 +106,9 @@ $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd
 +
 [source,terminal]
 ----
-$ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db /tmp/etcd.snapshot.db
+$ oc cp -c etcd \
+  ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db \
+  /tmp/etcd.snapshot.db
 ----
 
 . Next, scale down the etcd statefulset by entering the following command:
@@ -147,7 +131,8 @@ $ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pvc/data-etcd-2
 +
 [source,terminal]
 ----
-$ ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd -o jsonpath='{ .spec.template.spec.containers[0].image }')
+$ ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd \
+  -o jsonpath='{ .spec.template.spec.containers[0].image }')
 ----
 +
 ... Create a pod that allows access to etcd data:
@@ -201,14 +186,16 @@ $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd-data
 +
 [source,terminal]
 ----
-$ DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers -l app=etcd-data -o name | cut -d/ -f2)
+$ DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers \
+  -l app=etcd-data -o name | cut -d/ -f2)
 ----
 
 .. Copy an etcd snapshot into the pod by entering the following command:
 +
 [source,terminal]
 ----
-$ oc cp /tmp/etcd.snapshot.db ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.db
+$ oc cp /tmp/etcd.snapshot.db \
+  ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.db
 ----
 
 .. Remove old data from the `etcd-data` pod by entering the following commands:
@@ -227,7 +214,8 @@ $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- mkdir -p /var/lib/data
 +
 [source,terminal]
 ----
-$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- etcdutl snapshot restore /var/lib/restored.snap.db \
+$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \
+     etcdutl snapshot restore /var/lib/restored.snap.db \
      --data-dir=/var/lib/data --skip-hash-check \
      --name etcd-0 \
      --initial-cluster-token=etcd-cluster \
@@ -239,7 +227,8 @@ $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- etcdutl snapshot restore
 +
 [source,terminal]
 ----
-$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm /var/lib/restored.snap.db
+$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \
+  rm /var/lib/restored.snap.db
 ----
 
 .. Delete data access deployment by entering the following command:
@@ -263,16 +252,10 @@ $ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=3
 $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd -w
 ----
 
-.. Scale up all etcd-writer deployments by entering the following command:
-+
-[source,terminal]
-----
-$ oc scale deployment -n ${CONTROL_PLANE_NAMESPACE} --replicas=3 kube-apiserver openshift-apiserver openshift-oauth-apiserver
-----
-
 . Restore reconciliation of the hosted cluster by entering the following command:
 +
 [source,terminal]
 ----
-$ oc patch -n ${CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":""}}' --type=merge
-----
+$ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \
+  -p '{"spec":{"pausedUntil":"null"}}' --type=merge
+----
\ No newline at end of file
diff --git a/modules/hosted-control-planes-concepts-personas.adoc b/modules/hosted-control-planes-concepts-personas.adoc
index 0b8886b353fb..90dbb9aa7665 100644
--- a/modules/hosted-control-planes-concepts-personas.adoc
+++ b/modules/hosted-control-planes-concepts-personas.adoc
@@ -21,7 +21,7 @@ hosted control plane:: An {product-title} control plane that runs on the managem
 
 hosting cluster:: See _management cluster_.
 
-managed cluster:: A cluster that the hub cluster manages. This term is specific to the cluster lifecycle that the {mce} manages in Red Hat Advanced Cluster Management. A managed cluster is not the same thing as a _management cluster_. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/about/welcome-to-red-hat-advanced-cluster-management-for-kubernetes#managed-cluster[Managed cluster].
+managed cluster:: A cluster that the hub cluster manages. This term is specific to the cluster lifecycle that the {mce} manages in Red Hat Advanced Cluster Management. A managed cluster is not the same thing as a _management cluster_. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/about/welcome-to-red-hat-advanced-cluster-management-for-kubernetes#managed-cluster[Managed cluster].
 
 management cluster:: An {product-title} cluster where the HyperShift Operator is deployed and where the control planes for hosted clusters are hosted. The management cluster is synonymous with the _hosting cluster_.
 
diff --git a/modules/hosted-control-planes-monitoring-dashboard.adoc b/modules/hosted-control-planes-monitoring-dashboard.adoc
index 193ea36e60cc..b37b83819057 100644
--- a/modules/hosted-control-planes-monitoring-dashboard.adoc
+++ b/modules/hosted-control-planes-monitoring-dashboard.adoc
@@ -48,6 +48,7 @@ To generate dashboards for each hosted cluster, the HyperShift Operator uses a t
 
 When a dashboard is generated, the following strings are replaced with values that correspond to a specific hosted cluster:
 
+[cols="2,2",options="header"]
 |===
 | Name | Description
 | [x-]`__NAME__` | The name of the hosted cluster
diff --git a/modules/hosted-control-planes-overview.adoc b/modules/hosted-control-planes-overview.adoc
index 826302d71163..0ab277a0f19b 100644
--- a/modules/hosted-control-planes-overview.adoc
+++ b/modules/hosted-control-planes-overview.adoc
@@ -8,7 +8,7 @@
 [id="hosted-control-planes-overview_{context}"]
 = Introduction to {hcp}
 
-{hcp-capital} is available by using a link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#cluster_mce_overview[supported version of {mce}] on the following platforms:
+{hcp-capital} is available by using a link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/clusters/cluster_mce_overview#cluster_mce_overview[supported version of {mce}] on the following platforms:
 
 * Bare metal by using the Agent provider
 * Non-bare-metal Agent machines, as a Technology Preview feature
diff --git a/modules/hosted-control-planes-version-support.adoc b/modules/hosted-control-planes-version-support.adoc
index 8c18fc3c79ea..85dae5aba3ff 100644
--- a/modules/hosted-control-planes-version-support.adoc
+++ b/modules/hosted-control-planes-version-support.adoc
@@ -43,7 +43,7 @@ You can host different versions of control planes on the same management cluster
 ----
     apiVersion: v1
     data:
-      supported-versions: '{"versions":["4.17"]}'
+      supported-versions: '{"versions":["4.18"]}'
     kind: ConfigMap
     metadata:
       labels:
diff --git a/modules/ibi-create-iso-for-bmh.adoc b/modules/ibi-create-iso-for-bmh.adoc
index 083e0960c6db..fde75f19d9f7 100644
--- a/modules/ibi-create-iso-for-bmh.adoc
+++ b/modules/ibi-create-iso-for-bmh.adoc
@@ -59,8 +59,8 @@ kind: ImageBasedInstallationConfig
 metadata:
   name: example-image-based-installation-config
 # The following fields are required
-seedImage: quay.io/openshift-kni/seed-image:4.17.0
-seedVersion: 4.17.0
+seedImage: quay.io/openshift-kni/seed-image:4.18.0
+seedVersion: 4.18.0
 installationDisk: /dev/vda
 pullSecret: '<your_pull_secret>'
 # networkConfig is optional and contains the network configuration for the host in NMState format.
@@ -89,7 +89,7 @@ kind: ImageBasedInstallationConfig
 metadata:
   name: example-image-based-installation-config
 seedImage: quay.io/repo-id/seed:latest
-seedVersion: "4.17.0"
+seedVersion: "4.18.0"
 extraPartitionStart: "-240G"
 installationDisk: /dev/disk/by-id/wwn-0x62c...
 sshKey: 'ssh-ed25519 AAAA...'
diff --git a/modules/ibi-extra-manifests-configmap.adoc b/modules/ibi-extra-manifests-configmap.adoc
index 6c639bcee68f..c5376a6d25a6 100644
--- a/modules/ibi-extra-manifests-configmap.adoc
+++ b/modules/ibi-extra-manifests-configmap.adoc
@@ -83,6 +83,11 @@ $ oc create configmap sr-iov-extra-manifest --from-file=sriov-extra-manifest.yam
 ----
 configmap/sr-iov-extra-manifest created
 ----
++
+[NOTE]
+====
+If you add more than one extra manifest, and the manifests must be applied in a specific order, you must prefix the filenames of the manifests with numbers that represent the required order. For example, `00-namespace.yaml`, `01-sriov-extra-manifest.yaml`, and so on.
+====
 
 . Reference the `ConfigMap` resource in the `spec.extraManifestsRefs` field of the `ImageClusterInstall` resource:
 +
diff --git a/modules/ibi-extra-manifests-standalone.adoc b/modules/ibi-extra-manifests-standalone.adoc
index 476c4eea34ae..c661d0f364dd 100644
--- a/modules/ibi-extra-manifests-standalone.adoc
+++ b/modules/ibi-extra-manifests-standalone.adoc
@@ -21,6 +21,11 @@ You can create a resource in the `extra-manifests` folder of your working direct
 
 The following example adds an single-root I/O virtualization (SR-IOV) network to the deployment.
 
+[NOTE]
+====
+If you add more than one extra manifest, and the manifests must be applied in a specific order, you must prefix the filenames of the manifests with numbers that represent the required order. For example, `00-namespace.yaml`, `01-sriov-extra-manifest.yaml`, and so on.
+====
+
 .Prerequisites
 
 * You created a working directory with the `install-config.yaml` and `image-based-config.yaml` manifests
diff --git a/modules/ibi-extra-partition-ibi-install-iso.adoc b/modules/ibi-extra-partition-ibi-install-iso.adoc
index a11ab8496c0b..2a32591c8cf6 100644
--- a/modules/ibi-extra-partition-ibi-install-iso.adoc
+++ b/modules/ibi-extra-partition-ibi-install-iso.adoc
@@ -27,7 +27,7 @@ kind: ImageBasedInstallationConfig
 metadata:
   name: example-extra-partition
 seedImage: quay.io/repo-id/seed:latest
-seedVersion: "4.17.0"
+seedVersion: "4.18.0"
 installationDisk: /dev/sda
 pullSecret: '{"auths": ...}'
 # ...
diff --git a/modules/ibi-installer-installation-config.adoc b/modules/ibi-installer-installation-config.adoc
index 5d6cd337e1b2..70c5879f9077 100644
--- a/modules/ibi-installer-installation-config.adoc
+++ b/modules/ibi-installer-installation-config.adoc
@@ -33,7 +33,7 @@ If the seed image requires a separate private registry authentication, add the a
 |====
 |Specification|Type|Description
 |`shutdown`|`boolean`|Specifies if the host shuts down after the installation process completes. The default value is `false`.
-|`extraPartitionStart`|`string`|Specifies the start of the extra partition used for `/var/lib/containers`. The default value is `-40Gb`, which means that the partition will be exactly 40Gb in size and uses the space 40Gb from the end of the disk. If you specify a positive value, the partition will start at that position of the disk and extend to the end of the disk.
+|`extraPartitionStart`|`string`|Specifies the start of the extra partition used for `/var/lib/containers`. The default value is `-40G`, which means that the partition will be exactly 40GiB in size and uses the space 40GiB from the end of the disk. If you specify a positive value, the partition will start at that position of the disk and extend to the end of the disk.
 |`extraPartitionLabel`|`string`|The label of the extra partition you use for `/var/lib/containers`. The default partition label is `var-lib-containers`.
 
 [NOTE]
diff --git a/modules/ibm-z-enable-multipathing-fcp-luns.adoc b/modules/ibm-z-enable-multipathing-fcp-luns.adoc
index 9ab116bac192..8f6f9e7a714b 100644
--- a/modules/ibm-z-enable-multipathing-fcp-luns.adoc
+++ b/modules/ibm-z-enable-multipathing-fcp-luns.adoc
@@ -61,7 +61,7 @@ $ sudo fdisk /dev/mapper/mpatha
 +
 [source,terminal]
 ----
-$ sudo multipath -II
+$ sudo multipath -ll
 ----
 +
 .Example output
diff --git a/modules/identity-provider-gitlab-about.adoc b/modules/identity-provider-gitlab-about.adoc
index 5895124d044d..95b1aebf971d 100644
--- a/modules/identity-provider-gitlab-about.adoc
+++ b/modules/identity-provider-gitlab-about.adoc
@@ -7,4 +7,4 @@
 
 Configuring GitLab authentication allows users to log in to {product-title} with their GitLab credentials.
 
-If you use GitLab version 7.7.0 to 11.0, you connect using the link:http://doc.gitlab.com/ce/integration/oauth_provider.html[OAuth integration]. If you use GitLab version 11.1 or later, you can use link:https://docs.gitlab.com/ce/integration/openid_connect_provider.html[OpenID Connect] (OIDC) to connect instead of OAuth.
+If you use GitLab version 7.7.0 to 11.0, you connect using the link:https://docs.gitlab.com/ce/integration/oauth_provider.html[OAuth integration]. If you use GitLab version 11.1 or later, you can use link:https://docs.gitlab.com/ce/integration/openid_connect_provider.html[OpenID Connect] (OIDC) to connect instead of OAuth.
diff --git a/modules/images-allow-pods-to-reference-images-from-secure-registries.adoc b/modules/images-allow-pods-to-reference-images-from-secure-registries.adoc
index 59a717e51681..a70b510893fc 100644
--- a/modules/images-allow-pods-to-reference-images-from-secure-registries.adoc
+++ b/modules/images-allow-pods-to-reference-images-from-secure-registries.adoc
@@ -55,44 +55,4 @@ metadata:
   resourceVersion: "37676"
   uid: e2851531-01bc-48ba-878c-de96cfe31020
 type: Opaque
-----
-
-.Procedure
-
-* Create a secret from an existing authentication file:
-
-** For Docker clients using `.docker/config.json`, enter the following command:
-+
-[source,terminal]
-----
-$ oc create secret generic <pull_secret_name> \
-    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
-    --type=kubernetes.io/dockerconfigjson
-----
-
-** For Podman clients using `.config/containers/auth.json`, enter the following command:
-+
-[source,terminal]
-----
-$ oc create secret generic <pull_secret_name> \
-     --from-file=<path/to/.config/containers/auth.json> \
-     --type=kubernetes.io/podmanconfigjson
-----
-
-* If you do not already have a Docker credentials file for the secured registry, you can create a secret by running:
-+
-[source,terminal]
-----
-$ oc create secret docker-registry <pull_secret_name> \
-    --docker-server=<registry_server> \
-    --docker-username=<user_name> \
-    --docker-password=<password> \
-    --docker-email=<email>
-----
-
-* To use a secret for pulling images for pods, you must add the secret to your service account. The name of the service account in this example should match the name of the service account the pod uses. The default service account is `default`:
-+
-[source,terminal]
-----
-$ oc secrets link default <pull_secret_name> --for=pull
 ----
\ No newline at end of file
diff --git a/modules/images-configuration-blocked.adoc b/modules/images-configuration-blocked.adoc
index 2007b943abca..0bc620cc18cb 100644
--- a/modules/images-configuration-blocked.adoc
+++ b/modules/images-configuration-blocked.adoc
@@ -56,7 +56,7 @@ status:
 Either the `blockedRegistries` registry or the `allowedRegistries` registry can be set, but not both.
 ====
 +
-The Machine Config Operator (MCO) watches the `image.config.openshift.io/cluster` resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the `Ready` state, changes to the blocked registries appear in the `/etc/containers/registries.conf` file on each node.
+The Machine Config Operator (MCO) watches the `image.config.openshift.io/cluster` resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the `Ready` state, changes to the blocked registries appear in the `/etc/containers/registries.conf` file on each node. During this period, you might experience service unavailability.
 
 ifndef::openshift-rosa,openshift-dedicated[]
 .Verification
diff --git a/modules/images-configuration-parameters.adoc b/modules/images-configuration-parameters.adoc
index c1adae16f445..6b0eb4682636 100644
--- a/modules/images-configuration-parameters.adoc
+++ b/modules/images-configuration-parameters.adoc
@@ -47,6 +47,35 @@ pods. For instance, whether or not to allow insecure access. It does not contain
 
 Either `blockedRegistries` or `allowedRegistries` can be set, but not both.
 
+ifndef::openshift-rosa,openshift-dedicated[]
+|`imageStreamImportMode`
+|Controls the import mode behavior of image streams.
+
+You must enable the `TechPreviewNoUpgrade` feature set in the `FeatureGate` custom resource (CR) to enable the `imageStreamImportMode` feature. 
+For more information about feature gates, see "Understanding feature gates".
+
+You can set the `imageStreamImportMode` field to either of the following values:
+
+* `Legacy`: Indicates that the legacy behavior must be used. The legacy behavior discards the manifest list and imports a single sub-manifest. In this case, the platform is chosen in the following order of priority: 
+. Tag annotations: Determining the platform by using the platform-specific annotations in the image tags.
+. Control plane architecture or the operating system: Selecting the platform based on the architecture or the operating system of the control plane.
+. `linux/amd64`: If no platform is selected by the preceeding methods, the `linux/amd64` platform is selected. 
+. The first manifest in the list is selected.
+
+* `PreserveOriginal`: Indicates that the original manifest is preserved. The manifest list and its sub-manifests are imported. 
+
+If you specify a value for this field, the value is applied to the newly created image stream tags that do not already have this value manually set. 
+
+If you do not configure this field, the behavior is decided based on the payload type advertised by the `ClusterVersion` status. In this case, the platform is chosen as follows:
+
+* The single architecture payload implies that the `Legacy` mode is applicable.
+* The multi payload implies that the `PreserveOriginal` mode is applicable.
+
+For information about importing manifest lists, see "Working with manifest lists".
+
+:FeatureName: `imageStreamImportMode`
+include::snippets/technology-preview.adoc[]
+endif::openshift-rosa,openshift-dedicated[]
 |===
 
 [WARNING]
diff --git a/modules/images-configuration-shortname.adoc b/modules/images-configuration-shortname.adoc
index d4c02be105ac..d24867833b23 100644
--- a/modules/images-configuration-shortname.adoc
+++ b/modules/images-configuration-shortname.adoc
@@ -31,7 +31,7 @@ Potentially add the last line to the Ignoring image registry repository mirrorin
 ////
 ====
 
-The Machine Config Operator (MCO) watches the `image.config.openshift.io/cluster` resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the `Ready` state, if the `containerRuntimeSearchRegistries` parameter is added, the MCO creates a file in the `/etc/containers/registries.conf.d` directory on each node with the listed registries. The file overrides the default list of unqualified search registries in the `/etc/containers/registries.conf` file. There is no way to fall back to the default list of unqualified search registries.
+The Machine Config Operator (MCO) watches the `image.config.openshift.io/cluster` resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. During this period, you might experience service unavailability. After the nodes return to the `Ready` state, if the `containerRuntimeSearchRegistries` parameter is added, the MCO creates a file in the `/etc/containers/registries.conf.d` directory on each node with the listed registries. The file overrides the default list of unqualified search registries in the `/etc/containers/registries.conf` file. There is no way to fall back to the default list of unqualified search registries.
 
 The `containerRuntimeSearchRegistries` parameter works only with the Podman and CRI-O container engines. The registries in the list can be used only in pod specs, not in builds and image streams.
 
diff --git a/modules/images-imagestream-specify-architecture.adoc b/modules/images-imagestream-specify-architecture.adoc
index bc8c9bd029e3..d7c6d9c9cfe4 100644
--- a/modules/images-imagestream-specify-architecture.adoc
+++ b/modules/images-imagestream-specify-architecture.adoc
@@ -18,8 +18,6 @@ $ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/
 
 * Run the following command to update your image stream from single-architecture to multi-architecture:
 +
-[source,terminal]
-----
-$ oc import-image <multiarch-image-stream-tag>  --from=<registry>/<project_name>/<image-name> \
---import-mode='PreserveOriginal'
-----
\ No newline at end of file
+--
+include::snippets/update-image-stream-to-multi-arch.adoc[]
+--
\ No newline at end of file
diff --git a/modules/images-update-global-pull-secret.adoc b/modules/images-update-global-pull-secret.adoc
index dbcf8d6b0101..e4ff8b7b5cb6 100644
--- a/modules/images-update-global-pull-secret.adoc
+++ b/modules/images-update-global-pull-secret.adoc
@@ -40,7 +40,9 @@ endif::image-pull-secrets[]
 +
 [source,terminal]
 ----
-$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> <1>
+$ oc get secret/pull-secret -n openshift-config \
+  --template='{{index .data ".dockerconfigjson" | base64decode}}' \
+  ><pull_secret_location> <1>
 ----
 <1> Provide the path to the pull secret file.
 
@@ -62,7 +64,8 @@ Alternatively, you can perform a manual update to the pull secret file.
 +
 [source,terminal]
 ----
-$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> <1>
+$ oc set data secret/pull-secret -n openshift-config \
+  --from-file=.dockerconfigjson=<pull_secret_location> <1>
 ----
 <1> Provide the path to the new pull secret file.
 +
diff --git a/modules/infrastructure-moving-monitoring.adoc b/modules/infrastructure-moving-monitoring.adoc
index 54de79f05d60..ad002b689082 100644
--- a/modules/infrastructure-moving-monitoring.adoc
+++ b/modules/infrastructure-moving-monitoring.adoc
@@ -9,6 +9,12 @@
 The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager.
 The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
 
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+* You have installed the {oc-first}.
+
 .Procedure
 
 . Edit the `cluster-monitoring-config` config map and change the `nodeSelector` to use the `infra` label:
@@ -34,9 +40,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     prometheusK8s:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -44,9 +47,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     prometheusOperator:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -54,9 +54,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     metricsServer:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -64,9 +61,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     kubeStateMetrics:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -74,9 +68,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     telemeterClient:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -84,9 +75,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     openshiftStateMetrics:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -94,9 +82,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     thanosQuerier:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -104,9 +89,6 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
     monitoringPlugin:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
@@ -114,11 +96,8 @@ data:
       - key: node-role.kubernetes.io/infra
         value: reserved
         effect: NoSchedule
-      - key: node-role.kubernetes.io/infra
-        value: reserved
-        effect: NoExecute
 ----
-<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` in the format shown or use `<key>: <value>` pairs, based on the value specified for the node. If you added a taint to the infrastructure node, also add a matching toleration.
+<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` parameter in the format shown or use `<key>: <value>` pairs, based on the value specified for the node. If you added a taint to the infrastructure node, also add a matching toleration.
 
 . Watch the monitoring pods move to the new machines:
 +
diff --git a/modules/infrastructure-moving-registry.adoc b/modules/infrastructure-moving-registry.adoc
index f23ccca14362..5669bafb0e7e 100644
--- a/modules/infrastructure-moving-registry.adoc
+++ b/modules/infrastructure-moving-registry.adoc
@@ -61,15 +61,12 @@ $ oc edit configs.imageregistry.operator.openshift.io/cluster
 +
 [source,yaml]
 ----
+apiVersion: imageregistry.operator.openshift.io/v1
+kind: Config
+metadata:
+  name: cluster
+# ...
 spec:
-  affinity:
-    podAntiAffinity:
-      preferredDuringSchedulingIgnoredDuringExecution:
-      - podAffinityTerm:
-          namespaces:
-          - openshift-image-registry
-          topologyKey: kubernetes.io/hostname
-        weight: 100
   logLevel: Normal
   managementState: Managed
   nodeSelector: <1>
@@ -78,11 +75,8 @@ spec:
   - effect: NoSchedule
     key: node-role.kubernetes.io/infra
     value: reserved
-  - effect: NoExecute
-    key: node-role.kubernetes.io/infra
-    value: reserved
 ----
-<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` in the format shown or use `<key>: <value>` pairs, based on the value specified for the node.  If you added a taint to the infrasructure node, also add a matching toleration.
+<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` parameter in the format shown or use `<key>: <value>` pairs, based on the value specified for the node. If you added a taint to the infrasructure node, also add a matching toleration.
 
 . Verify the registry pod has been moved to the infrastructure node.
 +
diff --git a/modules/infrastructure-moving-router.adoc b/modules/infrastructure-moving-router.adoc
index e8d5c437dd0f..7d0849512f45 100644
--- a/modules/infrastructure-moving-router.adoc
+++ b/modules/infrastructure-moving-router.adoc
@@ -59,20 +59,27 @@ $ oc edit ingresscontroller default -n openshift-ingress-operator
 +
 [source,yaml]
 ----
-  spec:
-    nodePlacement:
-      nodeSelector: <1>
-        matchLabels:
-          node-role.kubernetes.io/infra: ""
-      tolerations:
-      - effect: NoSchedule
-        key: node-role.kubernetes.io/infra
-        value: reserved
-      - effect: NoExecute
-        key: node-role.kubernetes.io/infra
-        value: reserved
-----
-<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` in the format shown or use `<key>: <value>` pairs, based on the value specified for the node. If you added a taint to the infrastructure node, also add a matching toleration.
+apiVersion: operator.openshift.io/v1
+kind: IngressController
+metadata:
+  creationTimestamp: "2025-03-26T21:15:43Z"
+  finalizers:
+  - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
+  generation: 1
+  name: default
+# ...
+spec:
+  nodePlacement:
+    nodeSelector: <1>
+      matchLabels:
+        node-role.kubernetes.io/infra: ""
+    tolerations:
+    - effect: NoSchedule
+      key: node-role.kubernetes.io/infra
+      value: reserved
+# ...
+----
+<1> Add a `nodeSelector` parameter with the appropriate value to the component you want to move. You can use a `nodeSelector` parameter in the format shown or use `<key>: <value>` pairs, based on the value specified for the node. If you added a taint to the infrastructure node, also add a matching toleration.
 
 . Confirm that the router pod is running on the `infra` node.
 .. View the list of router pods and note the node name of the running pod:
diff --git a/modules/insights-operator-configuring.adoc b/modules/insights-operator-configuring.adoc
index 2af1b67f4240..15c685dfe7db 100644
--- a/modules/insights-operator-configuring.adoc
+++ b/modules/insights-operator-configuring.adoc
@@ -80,7 +80,7 @@ data:
         - networking
         - workload_names
     sca:
-      disable: false
+      disabled: false
       interval: 2h
     alerting:
        disabled: false
diff --git a/modules/insights-operator-new-pull-secret-enable.adoc b/modules/insights-operator-new-pull-secret-enable.adoc
index 90bd08c2b8f5..8907bcf2e954 100644
--- a/modules/insights-operator-new-pull-secret-enable.adoc
+++ b/modules/insights-operator-new-pull-secret-enable.adoc
@@ -36,7 +36,9 @@ The file `pull-secret.txt` containing your `cloud.openshift.com` access token in
 +
 [source,terminal]
 ----
-$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' > pull-secret
+$ oc get secret/pull-secret -n openshift-config \
+  --template='{{index .data ".dockerconfigjson" | base64decode}}' \
+  > pull-secret
 ----
 . Make a backup copy of your pull secret.
 +
@@ -51,7 +53,8 @@ $ cp pull-secret pull-secret-backup
 +
 [source,terminal]
 ----
-oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=pull-secret
+$ oc set data secret/pull-secret -n openshift-config \
+  --from-file=.dockerconfigjson=pull-secret
 ----
 
 It may take several minutes for the secret to update and your cluster to begin reporting.
diff --git a/modules/insights-operator-one-time-gather.adoc b/modules/insights-operator-one-time-gather.adoc
index 58b68ee6f24c..810bcc8602da 100644
--- a/modules/insights-operator-one-time-gather.adoc
+++ b/modules/insights-operator-one-time-gather.adoc
@@ -20,7 +20,7 @@ You must run a gather operation to create an Insights Operator archive.
 +
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/insights-operator/release-4.17/docs/gather-job.yaml[]
+include::https://raw.githubusercontent.com/openshift/insights-operator/release-4.18/docs/gather-job.yaml[]
 ----
 . Copy your `insights-operator` image version:
 +
diff --git a/modules/inspecting-pod-and-container-logs.adoc b/modules/inspecting-pod-and-container-logs.adoc
index 1ececd35f154..ff9197ce795a 100644
--- a/modules/inspecting-pod-and-container-logs.adoc
+++ b/modules/inspecting-pod-and-container-logs.adoc
@@ -10,12 +10,12 @@ You can inspect pod and container logs for warnings and error messages related t
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 
diff --git a/modules/install-osp-deploy-dualstack.adoc b/modules/install-osp-deploy-dualstack.adoc
index 9a718a9f8a18..a92b1b813a72 100644
--- a/modules/install-osp-deploy-dualstack.adoc
+++ b/modules/install-osp-deploy-dualstack.adoc
@@ -164,4 +164,10 @@ ipv6.addr-gen-mode=0
 ----
 
 After you create and edit the file, reboot the installation host.
+====
+
+[NOTE]
+====
+The `ip=dhcp,dhcp6` kernel argument, which is set on all of the nodes, results in a single Network Manager connection profile that is activated on multiple interfaces simultaneously.
+Because of this behavior, any additional network has the same connection enforced with an identical UUID. If you need an interface-specific configuration, create a new connection profile for that interface so that the default connection is no longer enforced on it.
 ====
\ No newline at end of file
diff --git a/modules/installation-arm-bootstrap.adoc b/modules/installation-arm-bootstrap.adoc
index 192dfecc8368..db9f76bab32c 100644
--- a/modules/installation-arm-bootstrap.adoc
+++ b/modules/installation-arm-bootstrap.adoc
@@ -20,10 +20,10 @@ bootstrap machine that you need for your {product-title} cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/04_bootstrap.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/04_bootstrap.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/04_bootstrap.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/04_bootstrap.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-arm-control-plane.adoc b/modules/installation-arm-control-plane.adoc
index 249f3058d044..cff1aa1151f5 100644
--- a/modules/installation-arm-control-plane.adoc
+++ b/modules/installation-arm-control-plane.adoc
@@ -20,10 +20,10 @@ control plane machines that you need for your {product-title} cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/05_masters.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/05_masters.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/05_masters.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/05_masters.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-arm-dns.adoc b/modules/installation-arm-dns.adoc
index f028c422011a..6ae936edef86 100644
--- a/modules/installation-arm-dns.adoc
+++ b/modules/installation-arm-dns.adoc
@@ -21,10 +21,10 @@ cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/03_infra.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/03_infra.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/03_infra.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/03_infra.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-arm-image-storage.adoc b/modules/installation-arm-image-storage.adoc
index f06a2fd3b88e..775e9175ec0b 100644
--- a/modules/installation-arm-image-storage.adoc
+++ b/modules/installation-arm-image-storage.adoc
@@ -20,10 +20,10 @@ stored {op-system-first} image that you need for your {product-title} cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/02_storage.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/02_storage.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/02_storage.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/02_storage.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-arm-vnet.adoc b/modules/installation-arm-vnet.adoc
index d859ce692406..868d0df1f5f0 100644
--- a/modules/installation-arm-vnet.adoc
+++ b/modules/installation-arm-vnet.adoc
@@ -20,10 +20,10 @@ VNet that you need for your {product-title} cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/01_vnet.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/01_vnet.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/01_vnet.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/01_vnet.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-arm-worker.adoc b/modules/installation-arm-worker.adoc
index 5273765e8989..4f9e2849f1a9 100644
--- a/modules/installation-arm-worker.adoc
+++ b/modules/installation-arm-worker.adoc
@@ -20,10 +20,10 @@ worker machines that you need for your {product-title} cluster:
 [source,json]
 ----
 ifndef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azure/06_workers.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azure/06_workers.json[]
 endif::ash[]
 ifdef::ash[]
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/azurestack/06_workers.json[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/azurestack/06_workers.json[]
 endif::ash[]
 ----
 ====
diff --git a/modules/installation-aws-user-infra-rhcos-ami.adoc b/modules/installation-aws-user-infra-rhcos-ami.adoc
index b7a41e27e96b..e4cb1fbbfa5a 100644
--- a/modules/installation-aws-user-infra-rhcos-ami.adoc
+++ b/modules/installation-aws-user-infra-rhcos-ami.adoc
@@ -23,97 +23,97 @@ ifndef::openshift-origin[]
 |AWS AMI
 
 |`af-south-1`
-|`ami-019b3e090bb062842`
+|`ami-01bf6b6fca71a7dc3`
 
 |`ap-east-1`
-|`ami-0cb76d97f77cda0a1`
+|`ami-0594c08334dcc4afb`
 
 |`ap-northeast-1`
-|`ami-0d7d4b329e5403cfb`
+|`ami-0313928874609075d`
 
 |`ap-northeast-2`
-|`ami-02d3789d532feb517`
+|`ami-09cfc5a33f840ce70`
 
 |`ap-northeast-3`
-|`ami-08b82c4899109b707`
+|`ami-02fece2c48e16e9f2`
 
 |`ap-south-1`
-|`ami-0c184f8b5ad8af69d`
+|`ami-063d0eaf658eb4dc5`
 
 |`ap-south-2`
-|`ami-0b0525037b9a20e9a`
+|`ami-0c4930cae17448786`
 
 |`ap-southeast-1`
-|`ami-0dbee0006375139a7`
+|`ami-068f696694b2fc0f1`
 
 |`ap-southeast-2`
-|`ami-043072b1af91be72f`
+|`ami-04aee88a86e139991`
 
 |`ap-southeast-3`
-|`ami-09d8bbf16b228139e`
+|`ami-0363d9df44ce25cd3`
 
 |`ap-southeast-4`
-|`ami-01c6b29e9c57b434b`
+|`ami-05b72aa8744449f86`
 
 |`ca-central-1`
-|`ami-06fda1fa0b65b864b`
+|`ami-0a7c95e80fb37ade8`
 
 |`ca-west-1`
-|`ami-0141eea486b5e2c43`
+|`ami-0818def2f3d7a696d`
 
 |`eu-central-1`
-|`ami-0f407de515454fdd0`
+|`ami-02c8714aef084ee90`
 
 |`eu-central-2`
-|`ami-062cfad83bc7b71b8`
+|`ami-083d349477a4e9f69`
 
 |`eu-north-1`
-|`ami-0af77aba6aebb5086`
+|`ami-03f4002a3746bc66b`
 
 |`eu-south-1`
-|`ami-04d9da83bc9f854fc`
+|`ami-038d816008adca0be`
 
 |`eu-south-2`
-|`ami-035d487abf54f0af7`
+|`ami-099f491d6ab9706d0`
 
 |`eu-west-1`
-|`ami-043dd3b788dbaeb1c`
+|`ami-0f0ebf16ff38e816f`
 
 |`eu-west-2`
-|`ami-0c7d0f90a4401b723`
+|`ami-0abb7730ffd4d9944`
 
 |`eu-west-3`
-|`ami-039baa878e1def55f`
+|`ami-032c22188cbfff12c`
 
 |`il-central-1`
-|`ami-07d305bf03b2148de`
+|`ami-08171fe42c6af2676`
 
 |`me-central-1`
-|`ami-0fc457e8897ccb41a`
+|`ami-0f1c6a3d726f5b7b5`
 
 |`me-south-1`
-|`ami-0af99a751cf682b90`
+|`ami-019faf03d74520d13`
 
 |`sa-east-1`
-|`ami-04a7300f64ee01d68`
+|`ami-01591af00107320c3`
 
 |`us-east-1`
-|`ami-01b53f2824bf6d426`
+|`ami-08f1807771f4e468b`
 
 |`us-east-2`
-|`ami-0565349610e27bd41`
+|`ami-078e26f293629fe91`
 
 |`us-gov-east-1`
-|`ami-0020504fa043fe41d`
+|`ami-068e56023ec09c2b1`
 
 |`us-gov-west-1`
-|`ami-036798bce4722d3c2`
+|`ami-09ba2da65d9d836cf`
 
 |`us-west-1`
-|`ami-0147c634ad692da52`
+|`ami-01d1d2ed3d63466da`
 
 |`us-west-2`
-|`ami-0c65d71e89d43aa90`
+|`ami-0d769ba340e913a8c`
 
 |===
 
@@ -126,97 +126,97 @@ ifndef::openshift-origin[]
 |AWS AMI
 
 |`af-south-1`
-|`ami-0e585ef53405bebf5`
+|`ami-02d76a4f0c0ee24cd`
 
 |`ap-east-1`
-|`ami-05f32f1715bb51bda`
+|`ami-07e78c2c0f5f81a49`
 
 |`ap-northeast-1`
-|`ami-05ecb62bab0c50e52`
+|`ami-0e3a6e27f6940ab63`
 
 |`ap-northeast-2`
-|`ami-0a3ffb2c07c9e4a8d`
+|`ami-0116db61662393b23`
 
 |`ap-northeast-3`
-|`ami-0ae6746ea17d1042c`
+|`ami-07dd3d8930d1c27eb`
 
 |`ap-south-1`
-|`ami-00deb5b08c86060b8`
+|`ami-07121d273482babf9`
 
 |`ap-south-2`
-|`ami-047a47d5049781e03`
+|`ami-084f561e41c26ab95`
 
 |`ap-southeast-1`
-|`ami-09cb598f0d36fde4c`
+|`ami-02301ea2b50fc247f`
 
 |`ap-southeast-2`
-|`ami-01fe8a7538500f24c`
+|`ami-0690a605a9bb33d00`
 
 |`ap-southeast-3`
-|`ami-051b3f67dd787d5e9`
+|`ami-08d243c0580c87c80`
 
 |`ap-southeast-4`
-|`ami-04d2e14a9eef40143`
+|`ami-013dad9ce63ec3dc0`
 
 |`ca-central-1`
-|`ami-0f66973ff12d09356`
+|`ami-0238dbad4895283b7`
 
 |`ca-west-1`
-|`ami-0c9f3e2f0470d6d0b`
+|`ami-0faded0cfdf14248a`
 
 |`eu-central-1`
-|`ami-0a79af8849b425a8a`
+|`ami-085a88c5d03df3675`
 
 |`eu-central-2`
-|`ami-0f9f66951c9709471`
+|`ami-08d6da8ffaa81e2b4`
 
 |`eu-north-1`
-|`ami-0670362aa7eb9032d`
+|`ami-0077ccc8e7962b7ee`
 
 |`eu-south-1`
-|`ami-031b24b970eae750b`
+|`ami-02c649a544c9395f2`
 
 |`eu-south-2`
-|`ami-0734d2ed55c00a46c`
+|`ami-0a955bda5a7189ebd`
 
 |`eu-west-1`
-|`ami-0a9af75c2649471c0`
+|`ami-040969e306c9a3efa`
 
 |`eu-west-2`
-|`ami-0b84155a3672ac44e`
+|`ami-06b30fcc40988cc96`
 
 |`eu-west-3`
-|`ami-02b51442c612818d4`
+|`ami-00dc4e0a7798ae0c5`
 
 |`il-central-1`
-|`ami-0d2c47a297d483ce4`
+|`ami-0c1adf273a43b58e2`
 
 |`me-central-1`
-|`ami-0ef3005246bd83b07`
+|`ami-00817b16f81e58b86`
 
 |`me-south-1`
-|`ami-0321ca1ee89015eda`
+|`ami-0f72a9bb1975ba0f9`
 
 |`sa-east-1`
-|`ami-0e63f1103dc71d8ae`
+|`ami-083cf54e8ffc2d716`
 
 |`us-east-1`
-|`ami-0404da96615c73bec`
+|`ami-0eebf083d985a0bcf`
 
 |`us-east-2`
-|`ami-04c3bd7be936f728f`
+|`ami-0b04071739ccf4af2`
 
 |`us-gov-east-1`
-|`ami-0d30bc0b99b153247`
+|`ami-092fec5203140ddd8`
 
 |`us-gov-west-1`
-|`ami-0ee006f84d6aa5045`
+|`ami-078ee5edd87052e70`
 
 |`us-west-1`
-|`ami-061bfd61d5cfd7aa6`
+|`ami-0344d1d886514e258`
 
 |`us-west-2`
-|`ami-05ffb8f6f18b8e3f8`
+|`ami-07ef3531e7692a7ae`
 
 |===
 endif::openshift-origin[]
diff --git a/modules/installation-bare-metal-agent-installer-config-yaml.adoc b/modules/installation-bare-metal-agent-installer-config-yaml.adoc
index a6915fd236e9..4123c76b4f52 100644
--- a/modules/installation-bare-metal-agent-installer-config-yaml.adoc
+++ b/modules/installation-bare-metal-agent-installer-config-yaml.adoc
@@ -16,9 +16,11 @@ baseDomain: example.com <1>
 compute: <2>
 - name: worker
   replicas: 0 <3>
+  architecture: amd64
 controlPlane: <2>
   name: master
   replicas: 1 <4>
+  architecture: amd64
 metadata:
   name: sno-cluster <5>
 networking:
diff --git a/modules/installation-bare-metal-config-yaml.adoc b/modules/installation-bare-metal-config-yaml.adoc
index e8e1d1bcf009..239a26df972f 100644
--- a/modules/installation-bare-metal-config-yaml.adoc
+++ b/modules/installation-bare-metal-config-yaml.adoc
@@ -186,7 +186,7 @@ ifndef::ibm-power[]
 <3> Specifies whether to enable or disable simultaneous multithreading (SMT), or hyperthreading. By default, SMT is enabled to increase the performance of the cores in your machines. You can disable it by setting the parameter value to `Disabled`. If you disable SMT, you must disable it in all cluster machines; this includes both control plane and compute machines.
 endif::ibm-power[]
 ifdef::ibm-power[]
-<3> Simultaneous multithreading (SMT) is not supported.
+<3> Simultaneous multithreading (SMT) is configured as a post-installation task.
 endif::ibm-power[]
 ifndef::ibm-z,ibm-z-kvm,ibm-power[]
 +
diff --git a/modules/installation-cloudformation-bootstrap.adoc b/modules/installation-cloudformation-bootstrap.adoc
index db704f6dd6e1..dda517113a9b 100644
--- a/modules/installation-cloudformation-bootstrap.adoc
+++ b/modules/installation-cloudformation-bootstrap.adoc
@@ -13,6 +13,6 @@ You can use the following CloudFormation template to deploy the bootstrap machin
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/04_cluster_bootstrap.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/04_cluster_bootstrap.yaml[]
 ----
 ====
diff --git a/modules/installation-cloudformation-control-plane.adoc b/modules/installation-cloudformation-control-plane.adoc
index 1489c1e6875a..f719347ccb0e 100644
--- a/modules/installation-cloudformation-control-plane.adoc
+++ b/modules/installation-cloudformation-control-plane.adoc
@@ -14,6 +14,6 @@ machines that you need for your {product-title} cluster.
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/05_cluster_master_nodes.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/05_cluster_master_nodes.yaml[]
 ----
 ====
diff --git a/modules/installation-cloudformation-dns.adoc b/modules/installation-cloudformation-dns.adoc
index 5fde9b4e2a08..8b4a8a365a9b 100644
--- a/modules/installation-cloudformation-dns.adoc
+++ b/modules/installation-cloudformation-dns.adoc
@@ -14,7 +14,7 @@ objects and load balancers that you need for your {product-title} cluster.
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/02_cluster_infra.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/02_cluster_infra.yaml[]
 ----
 ====
 
diff --git a/modules/installation-cloudformation-security.adoc b/modules/installation-cloudformation-security.adoc
index 22f159112da0..8d6c2c24ab76 100644
--- a/modules/installation-cloudformation-security.adoc
+++ b/modules/installation-cloudformation-security.adoc
@@ -14,6 +14,6 @@ that you need for your {product-title} cluster.
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/03_cluster_security.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/03_cluster_security.yaml[]
 ----
 ====
diff --git a/modules/installation-cloudformation-vpc.adoc b/modules/installation-cloudformation-vpc.adoc
index 6c62f193a709..a8775a950b43 100644
--- a/modules/installation-cloudformation-vpc.adoc
+++ b/modules/installation-cloudformation-vpc.adoc
@@ -14,6 +14,6 @@ you need for your {product-title} cluster.
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/01_vpc.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/01_vpc.yaml[]
 ----
 ====
diff --git a/modules/installation-cloudformation-worker.adoc b/modules/installation-cloudformation-worker.adoc
index b0732a4c3008..c3279e6e6472 100644
--- a/modules/installation-cloudformation-worker.adoc
+++ b/modules/installation-cloudformation-worker.adoc
@@ -14,6 +14,6 @@ that you need for your {product-title} cluster.
 ====
 [source,yaml]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/aws/cloudformation/06_cluster_worker_node.yaml[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/aws/cloudformation/06_cluster_worker_node.yaml[]
 ----
 ====
diff --git a/modules/installation-configuration-parameters.adoc b/modules/installation-configuration-parameters.adoc
index 1899072ed36a..f9e8ccdb1096 100644
--- a/modules/installation-configuration-parameters.adoc
+++ b/modules/installation-configuration-parameters.adoc
@@ -743,49 +743,55 @@ ifdef::ibm-power-vs[]
 |platform:
   powervs:
     serviceInstanceGUID:
-|The ServiceInstanceGUID is the ID of the Power IAAS instance created from the {ibm-cloud-name} Catalog.
+|Specifies the ID of the Power IAAS instance created from the {ibm-cloud-name} Catalog.
 |String. For example, `existing_service_instance_GUID`.
 
 |platform:
   powervs:
     clusterOSImage:
-|The ClusterOSImage is a pre-created {ibm-power-server-name} boot image that overrides the default image for cluster nodes.
+|Specifies a pre-created {ibm-power-server-name} boot image that overrides the default image for cluster nodes.
 |String. For example, `existing_cluster_os_image`.
 
 |platform:
   powervs:
     defaultMachinePlatform:
-|The DefaultMachinePlatform is the default configuration used when installing on {ibm-power-server-name} for machine pools that do not define their own platform configuration.
+|Specifies the default configuration used when installing on {ibm-power-server-name} for machine pools that do not define their own platform configuration.
 |String. For example, `existing_machine_platform`.
 
 |platform:
   powervs:
     memoryGiB:
-|The size of a virtual machine's memory, in GB.
+|Specifies the size of a virtual machine's memory, in GB.
 |The valid integer must be an integer number of GB that is at least 2 and no more than 64, depending on the machine type.
 
 |platform:
   powervs:
     procType:
-|The ProcType defines the processor sharing model for the instance.
+|Defines the processor sharing model for the instance.
 |The valid values are Capped, Dedicated, and Shared.
 
 |platform:
   powervs:
     processors:
-|The Processors defines the processing units for the instance.
+|Defines the processing units for the instance.
 |The number of processors must be from .5 to 32 cores. The processors must be in increments of .25.
 
 |platform:
   powervs:
     sysType:
-|The SysType defines the system type for the instance.
-|The system type must be either `e980` or `s922`.
+|Defines the system type for the instance.
+|The system type must be `e980`, `s922`, `e1080`, or `s1022`. The available system types depend on the zone you want to target.
+
+|platform:
+  powervs:
+    tgName:
+|Defines the name of an existing Transit Gateway.
+|String. For example, `existing_tgName`.
 endif::ibm-power-vs[]
 |====
 
 ifdef::aws,gcp[]
-+
+
 [NOTE]
 ====
 ifdef::aws[If your AWS account has service control policies (SCP) enabled, you must configure the `credentialsMode` parameter to `Mint`, `Passthrough`, or `Manual`.]
@@ -793,7 +799,7 @@ ifdef::gcp[If you are installing on GCP into a shared virtual private cloud (VPC
 ====
 endif::aws,gcp[]
 ifdef::aws,gcp,azure[]
-+
+
 [IMPORTANT]
 ====
 Setting this parameter to `Manual` enables alternatives to storing administrator-level secrets in the `kube-system` project, which require additional configuration steps. For more information, see "Alternatives to storing administrator-level secrets in the kube-system project".
@@ -1258,6 +1264,21 @@ You can use this property to exceed the default persistent volume (PV) limit for
 You can also use this property to enable the QEMU guest agent by including the `hw_qemu_guest_agent` property with a value of `yes`.
 |A list of key-value string pairs. For example, `["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]`.
 
+|platform:
+  openstack:
+    controlPlanePort:
+      fixedIPs:
+|Subnets for the machines to use.
+|A list of subnet names or UUIDs to use in cluster installation.
+
+
+|platform:
+  openstack:
+    controlPlanePort:
+      network:
+|A network for the machines to use.
+|The UUID or name of an {rh-openstack} network to use in cluster installation.
+
 |platform:
   openstack:
     defaultMachinePlatform:
@@ -3458,7 +3479,7 @@ The name of one or more failures domains.
         uuid:
       subnetUUIDs:
       -
-a|By default, the installation program installs cluster machines to a single Prism Element instance. You can specify additional Prism Element instances for fault tolerance, and then apply them to:
+a|By default, the installation program installs cluster machines to a single Prism Element instance.  A maximum of 32 subnets for each failure domain (Prism Element) in an {product-title} cluster is supported. All `subnetUUID` values must be unique. You can specify additional Prism Element instances for fault tolerance, and then apply them to:
 
 * The cluster's default machine configuration
 * Only control plane or compute machine pools
@@ -3495,6 +3516,12 @@ For more information on usage, see "Configuring a failure domain" in "Installing
 |The password for the Prism Central user name.
 |String
 
+|platform:
+  nutanix:
+    preloadedOSImageName:
+|Instead of creating and uploading a {op-system} image object for each {product-title} cluster, this parameter uses the named, preloaded {op-system} image object from the Prism Elements to which the {product-title} cluster is deployed.
+|String
+
 |platform:
   nutanix:
     prismCentral:
@@ -3540,7 +3567,7 @@ For more information on usage, see "Configuring a failure domain" in "Installing
 [.small]
 --
 1. The `prismElements` section holds a list of Prism Elements (clusters). A Prism Element encompasses all of the Nutanix resources, for example virtual machines and subnets, that are used to host the {product-title} cluster.
-2. Only one subnet per Prism Element in an {product-title} cluster is supported.
+2. A maximum of 32 subnets for each Prism Element in an {product-title} cluster is supported. All `subnetUUID` values must be unique.
 --
 endif::nutanix[]
 
diff --git a/modules/installation-configuring-nutanix-failure-domains.adoc b/modules/installation-configuring-nutanix-failure-domains.adoc
index 4eb86db8c8c3..9b1d03f4166d 100644
--- a/modules/installation-configuring-nutanix-failure-domains.adoc
+++ b/modules/installation-configuring-nutanix-failure-domains.adoc
@@ -45,7 +45,7 @@ where:
 `<failure_domain_name>`:: Specifies a unique name for the failure domain. The name is limited to 64 or fewer characters, which can include lower-case letters, digits, and a dash (`-`). The dash cannot be in the leading or ending position of the name.
 `<prism_element_name>`:: Optional. Specifies the name of the Prism Element.
 `<prism_element_uuid`>:: Specifies the UUID of the Prism Element.
-`<network_uuid`>:: Specifies the UUID of the Prism Element subnet object. The subnet's IP address prefix (CIDR) should contain the virtual IP addresses that the {product-title} cluster uses. Only one subnet per failure domain (Prism Element) in an {product-title} cluster is supported.
+`<network_uuid`>:: Specifies the one or more UUIDs of the Prism Element subnet objects. Among them, one of the subnet's IP address prefixes (CIDRs) must contain the virtual IP addresses that the {product-title} cluster uses. A maximum of 32 subnets for each failure domain (Prism Element) in an {product-title} cluster is supported. All `subnetUUID` values must be unique.
 
 . As required, configure additional failure domains.
 . To distribute control plane and compute machines across the failure domains, do one of the following:
diff --git a/modules/installation-configuring-shiftstack-single-ipv6.adoc b/modules/installation-configuring-shiftstack-single-ipv6.adoc
new file mode 100644
index 000000000000..5131e4d6c0bc
--- /dev/null
+++ b/modules/installation-configuring-shiftstack-single-ipv6.adoc
@@ -0,0 +1,92 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_openstack/installing-openstack-installer-custom.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="installation-configuring-shiftstack-single-ipv6_{context}"]
+= Configuring a cluster with single-stack IPv6 networking
+
+You can create a single-stack IPv6 cluster on {rh-openstack-first} after you configure your {rh-openstack} deployment.
+
+IMPORTANT: You cannot convert a dual-stack cluster into a single-stack IPv6 cluster.
+
+.Prerequisites
+
+* Your {rh-openstack} deployment has an existing network with a DHCPv6-stateful IPv6 subnet to use as the machine network.
+* DNS is configured for the existing IPv6 subnet.
+* The IPv6 subnet is added to a {rh-openstack} router, and the router is configured to send router advertisements (RAs).
+* You added any additional IPv6 subnets that are used in the cluster to an {rh-openstack} router to enable router advertisements.
++
+NOTE: Using an IPv6 SLAAC subnet is not supported because any `dns_nameservers` addresses are not enforced by {rh-openstack} Neutron.
+* You have a mirror registry with an IPv6 interface.
+* The {rh-openstack} network accepts a minimum MTU size of 1442 bytes.
+* You created API and ingress virtual IP addresses (VIPs) as {rh-openstack} ports on the machine network and included those addresses in the `install-config.yaml` file.
+
+.Procedure
+
+. Create the API VIP port on the network by running the following command:
++
+[source,bash]
+----
+$ openstack port create api --network <v6_machine_network>
+----
+
+. Create the Ingress VIP port on the network by running the following command:
++
+[source,bash]
+----
+$ openstack port create ingress --network <v6_machine_network>
+----
+
+. After the networking resources are pre-created, deploy a cluster by using an `install-config.yaml` file that reflects your IPv6 network configuration. As an example:
++
+[source,yaml]
+----
+apiVersion: v1
+baseDomain: mydomain.test
+compute:
+- name: worker
+  platform:
+    openstack:
+      type: m1.xlarge
+  replicas: 3
+controlPlane:
+  name: master
+  platform:
+    openstack:
+      type: m1.xlarge
+  replicas: 3
+metadata:
+  name: mycluster
+networking:
+  machineNetwork:
+  - cidr: "fd2e:6f44:5dd8:c956::/64" # <1>
+  clusterNetwork:
+  - cidr: fd01::/48
+    hostPrefix: 64
+  serviceNetwork:
+  - fd02::/112
+platform:
+  openstack:
+    ingressVIPs: ['fd2e:6f44:5dd8:c956::383'] # <2>
+    apiVIPs: ['fd2e:6f44:5dd8:c956::9a'] # <2>
+    controlPlanePort:
+      fixedIPs: # <3>
+      - subnet:
+          name: subnet-v6
+      network: # <3>
+        name: v6-network
+imageContentSources: #<4>
+- mirrors:
+  - <mirror>
+  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
+- mirrors:
+  - <mirror>
+  source: registry.ci.openshift.org/ocp/release
+additionalTrustBundle: |
+<certificate_of_the_mirror>
+----
+<1> The CIDR of the subnet specified in this field must match the CIDR of the subnet that is specified in the `controlPlanePort` section.
+<2> Use the address from the ports you generated in the previous steps as the values for the parameters `platform.openstack.ingressVIPs` and `platform.openstack.apiVIPs`.
+<3> Items under the `platform.openstack.controlPlanePort.fixedIPs` and `platform.openstack.controlPlanePort.network` keys can contain an ID, a name, or both.
+<4> The `imageContentSources` section contains the mirror details. For more information on configuring a local image registry, see "Creating a mirror registry with mirror registry for Red Hat OpenShift". 
diff --git a/modules/installation-deployment-manager-bootstrap.adoc b/modules/installation-deployment-manager-bootstrap.adoc
index 326202be007e..83baa4935303 100644
--- a/modules/installation-deployment-manager-bootstrap.adoc
+++ b/modules/installation-deployment-manager-bootstrap.adoc
@@ -14,6 +14,6 @@ machine that you need for your {product-title} cluster:
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/04_bootstrap.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/04_bootstrap.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-control-plane.adoc b/modules/installation-deployment-manager-control-plane.adoc
index e6a4dde8fa9b..fb55d64281b5 100644
--- a/modules/installation-deployment-manager-control-plane.adoc
+++ b/modules/installation-deployment-manager-control-plane.adoc
@@ -14,6 +14,6 @@ plane machines that you need for your {product-title} cluster:
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/05_control_plane.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/05_control_plane.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-ext-lb.adoc b/modules/installation-deployment-manager-ext-lb.adoc
index 1c6fc20e9849..4e315147bf8b 100644
--- a/modules/installation-deployment-manager-ext-lb.adoc
+++ b/modules/installation-deployment-manager-ext-lb.adoc
@@ -12,6 +12,6 @@ You can use the following Deployment Manager template to deploy the external loa
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/02_lb_ext.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/02_lb_ext.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-firewall-rules.adoc b/modules/installation-deployment-manager-firewall-rules.adoc
index 5625e3a00c8f..3d7098ecc1c7 100644
--- a/modules/installation-deployment-manager-firewall-rules.adoc
+++ b/modules/installation-deployment-manager-firewall-rules.adoc
@@ -12,6 +12,6 @@ You can use the following Deployment Manager template to deploy the firewall rue
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/03_firewall.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/03_firewall.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-iam-shared-vpc.adoc b/modules/installation-deployment-manager-iam-shared-vpc.adoc
index 7f457589d881..95ece6be766d 100644
--- a/modules/installation-deployment-manager-iam-shared-vpc.adoc
+++ b/modules/installation-deployment-manager-iam-shared-vpc.adoc
@@ -12,6 +12,6 @@ You can use the following Deployment Manager template to deploy the IAM roles th
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/03_iam.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/03_iam.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-int-lb.adoc b/modules/installation-deployment-manager-int-lb.adoc
index 2a129b382e99..0da183704c61 100644
--- a/modules/installation-deployment-manager-int-lb.adoc
+++ b/modules/installation-deployment-manager-int-lb.adoc
@@ -12,7 +12,7 @@ You can use the following Deployment Manager template to deploy the internal loa
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/02_lb_int.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/02_lb_int.py[]
 ----
 ====
 
diff --git a/modules/installation-deployment-manager-private-dns.adoc b/modules/installation-deployment-manager-private-dns.adoc
index 22da7f208b4a..37f2b0180e94 100644
--- a/modules/installation-deployment-manager-private-dns.adoc
+++ b/modules/installation-deployment-manager-private-dns.adoc
@@ -12,6 +12,6 @@ You can use the following Deployment Manager template to deploy the private DNS
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/02_dns.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/02_dns.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-vpc.adoc b/modules/installation-deployment-manager-vpc.adoc
index 38fd0ff934c6..822f49ce202e 100644
--- a/modules/installation-deployment-manager-vpc.adoc
+++ b/modules/installation-deployment-manager-vpc.adoc
@@ -14,6 +14,6 @@ you need for your {product-title} cluster:
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/01_vpc.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/01_vpc.py[]
 ----
 ====
diff --git a/modules/installation-deployment-manager-worker.adoc b/modules/installation-deployment-manager-worker.adoc
index a60fb60712df..dc4afd5e52f8 100644
--- a/modules/installation-deployment-manager-worker.adoc
+++ b/modules/installation-deployment-manager-worker.adoc
@@ -14,6 +14,6 @@ that you need for your {product-title} cluster:
 ====
 [source,python]
 ----
-include::https://raw.githubusercontent.com/openshift/installer/release-4.17/upi/gcp/06_worker.py[]
+include::https://raw.githubusercontent.com/openshift/installer/release-4.18/upi/gcp/06_worker.py[]
 ----
 ====
diff --git a/modules/installation-gcp-tested-machine-types.adoc b/modules/installation-gcp-tested-machine-types.adoc
index ed1951576f26..0da04bf2f752 100644
--- a/modules/installation-gcp-tested-machine-types.adoc
+++ b/modules/installation-gcp-tested-machine-types.adoc
@@ -15,6 +15,13 @@
 
 The following Google Cloud Platform instance types have been tested with {product-title}.
 
+[NOTE]
+====
+Not all instance types are available in all regions and zones. For a detailed breakdown of which instance types are available in which zones, see link:https://cloud.google.com/compute/docs/regions-zones#available[regions and zones] (Google documentation).
+
+Some instance types require the use of Hyperdisk storage. If you use an instance type that requires Hyperdisk storage, all of the nodes in your cluster must support Hyperdisk storage, and you must change the default storage class to use Hyperdisk storage. For more information, see link:https://cloud.google.com/compute/docs/disks/hyperdisks#machine-type-support[machine series support for Hyperdisk] (Google documentation). For instructions on modifying storage classes, see the "GCE PersistentDisk (gcePD) object definition" section in the Dynamic Provisioning page in _Storage_.
+====
+
 .Machine series
 [%collapsible]
 ====
diff --git a/modules/installation-gcp-user-infra-rhcos.adoc b/modules/installation-gcp-user-infra-rhcos.adoc
index 0c74b2e52569..3be7ef1f3524 100644
--- a/modules/installation-gcp-user-infra-rhcos.adoc
+++ b/modules/installation-gcp-user-infra-rhcos.adoc
@@ -12,7 +12,7 @@ your {product-title} nodes.
 .Procedure
 
 ifndef::openshift-origin[]
-. Obtain the {op-system} image from the link:https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.17/[{op-system} image mirror] page.
+. Obtain the {op-system} image from the link:https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/[{op-system} image mirror] page.
 +
 [IMPORTANT]
 ====
diff --git a/modules/installation-ibm-cloud-regions.adoc b/modules/installation-ibm-cloud-regions.adoc
index a488d2c6e2b0..68b0648ed553 100644
--- a/modules/installation-ibm-cloud-regions.adoc
+++ b/modules/installation-ibm-cloud-regions.adoc
@@ -43,6 +43,8 @@ Deploying your cluster in the `eu-es` (Madrid, Spain) region is not supported fo
 endif::ibm-vpc[]
 ifdef::ibm-power-vs[]
 
+* `tor` (Toronto, Canada)
+** `tor01`
 * `dal` (Dallas, USA)
 ** `dal10`
 ** `dal12`
@@ -61,9 +63,14 @@ ifdef::ibm-power-vs[]
 ** `sao04`
 * `syd` (Sydney, Australia)
 ** `syd04`
+** `syd05`
 * `wdc` (Washington DC, USA)
 ** `wdc06`
 ** `wdc07`
+* `us-east` (Washington DC, United States)
+** `us-east`
+* `us-south` (Dallas, United States)
+** `us-south`
 
 You might optionally specify the {ibm-cloud-name} region in which the installation program creates any VPC components.
 
@@ -74,6 +81,7 @@ If you do not specify the region, the installation program selects the region cl
 
 {ibm-cloud-name} supports the following regions:
 
+* `us-east`
 * `us-south`
 * `eu-de`
 * `eu-es`
diff --git a/modules/installation-minimum-resource-requirements.adoc b/modules/installation-minimum-resource-requirements.adoc
index dbd76009bd9c..04ddba3248cf 100644
--- a/modules/installation-minimum-resource-requirements.adoc
+++ b/modules/installation-minimum-resource-requirements.adoc
@@ -235,14 +235,14 @@ endif::vsphere[]
 --
 [NOTE]
 ====
-As of {product-title} version 4.13, RHCOS is based on RHEL version 9.2, which updates the micro-architecture requirements. The following list contains the minimum instruction set architectures (ISA) that each architecture requires:
+For {product-title} version 4.18, RHCOS is based on RHEL version 9.4, which updates the micro-architecture requirements. The following list contains the minimum instruction set architectures (ISA) that each architecture requires:
 
 * x86-64 architecture requires x86-64-v2 ISA
 * ARM64 architecture requires ARMv8.0-A ISA
 * IBM Power architecture requires Power 9 ISA
 * s390x architecture requires z14 ISA
 
-For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.0_release_notes/index#architectures[RHEL Architectures].
+For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.2_release_notes/index#architectures[Architectures] ({op-system-base} documentation).
 ====
 
 ifdef::azure[]
diff --git a/modules/installation-mirror-repository.adoc b/modules/installation-mirror-repository.adoc
index ec0696026987..f69bfbb35483 100644
--- a/modules/installation-mirror-repository.adoc
+++ b/modules/installation-mirror-repository.adoc
@@ -33,8 +33,14 @@ endif::[]
 Complete the following steps on the mirror host:
 
 . Review the
+ifndef::openshift-origin[]
 link:https://access.redhat.com/downloads/content/290/[{product-title} downloads page]
 to determine the version of {product-title} that you want to install and determine the corresponding tag on the link:https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags[Repository Tags] page.
+endif::[]
+ifdef::openshift-origin[]
+link:https://github.com/okd-project/okd/releases/[{product-title} releases page]
+to determine the version and tag of {product-title} that you want to install.
+endif::[]
 
 . Set the required environment variables:
 .. Export the release version:
@@ -81,7 +87,7 @@ endif::[]
 ifdef::openshift-origin[]
 [source,terminal]
 ----
-$ PRODUCT_REPO='openshift'
+$ PRODUCT_REPO='okd'
 ----
 endif::[]
 
@@ -107,7 +113,7 @@ endif::[]
 ifdef::openshift-origin[]
 [source,terminal]
 ----
-$ RELEASE_NAME="okd"
+$ RELEASE_NAME="scos-release"
 ----
 endif::[]
 
diff --git a/modules/installation-network-user-infra.adoc b/modules/installation-network-user-infra.adoc
index cc885063c8bf..429b48b99d10 100644
--- a/modules/installation-network-user-infra.adoc
+++ b/modules/installation-network-user-infra.adoc
@@ -218,23 +218,6 @@ If an external NTP time server is configured, you must open UDP port `123`.
 
 |===
 
-ifdef::vsphere[]
-[discrete]
-== Ethernet adaptor hardware address requirements
-
-When provisioning VMs for the cluster, the ethernet interfaces configured for
-each VM must use a MAC address from the VMware Organizationally Unique
-Identifier (OUI) allocation ranges:
-
-* `00:05:69:00:00:00` to `00:05:69:FF:FF:FF`
-* `00:0c:29:00:00:00` to `00:0c:29:FF:FF:FF`
-* `00:1c:14:00:00:00` to `00:1c:14:FF:FF:FF`
-* `00:50:56:00:00:00` to `00:50:56:FF:FF:FF`
-
-If a MAC address outside the VMware OUI is used, the cluster installation will
-not succeed.
-endif::vsphere[]
-
 ifndef::azure,gcp[]
 [discrete]
 == NTP configuration for user-provisioned infrastructure
diff --git a/modules/installation-nutanix-installer-infra-reqs.adoc b/modules/installation-nutanix-installer-infra-reqs.adoc
index ab325f25fa26..875f2fdd31f7 100644
--- a/modules/installation-nutanix-installer-infra-reqs.adoc
+++ b/modules/installation-nutanix-installer-infra-reqs.adoc
@@ -8,6 +8,13 @@
 
 Before you install an {product-title} cluster, review the following Nutanix AOS environment requirements.
 
+[id="installation-nutanix-installer-infrastructure-reqs_{context}"]
+== Infrastructure requirements
+
+You can install {product-title} on on-premise Nutanix clusters, Nutanix Cloud Clusters (NC2) on {aws-first}, or NC2 on {azure-first}.
+
+For more information, see link:https://www.nutanix.com/products/nutanix-cloud-clusters/aws[Nutanix Cloud Clusters on AWS] and link:https://www.nutanix.com/products/nutanix-cloud-clusters/azure[Nutanix Cloud Clusters on Microsoft Azure].
+
 [id="installation-nutanix-installer-infra-reqs-account_{context}"]
 == Required account privileges
 
diff --git a/modules/installation-obtaining-fips-installer-mirror.adoc b/modules/installation-obtaining-fips-installer-mirror.adoc
index b91e26c6f53a..3cfe43de57dc 100644
--- a/modules/installation-obtaining-fips-installer-mirror.adoc
+++ b/modules/installation-obtaining-fips-installer-mirror.adoc
@@ -13,7 +13,7 @@
 
 .Procedure
 
-. Download the installation program from https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest-4.17/openshift-install-rhel9-amd64.tar.gz.
+. Download the installation program from https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest-4.18/openshift-install-rhel9-amd64.tar.gz.
 . Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:
 +
 [source,terminal]
diff --git a/modules/installation-obtaining-installer.adoc b/modules/installation-obtaining-installer.adoc
index 50b58de7c52b..0d86ff52cf86 100644
--- a/modules/installation-obtaining-installer.adoc
+++ b/modules/installation-obtaining-installer.adoc
@@ -95,6 +95,13 @@ ifndef::ibm-z,private,vsphere[* You have a computer that runs Linux or macOS, wi
 
 ifndef::openshift-origin[]
 . Go to the link:https://console.redhat.com/openshift/install[Cluster Type] page on the {hybrid-console}. If you have a Red{nbsp}Hat account, log in with your credentials. If you do not, create an account.
+
++
+[TIP]
+====
+You can also link:https://mirror.openshift.com/pub/openshift-v4/clients/ocp/[download the binaries for a specific {product-title} release].
+====
+
 . Select your infrastructure provider from the *Run it yourself* section of the page.
 . Select your host operating system and architecture from the dropdown menus under *OpenShift Installer* and click *Download Installer*.
 . Place the downloaded file in the directory where you want to store the installation configuration files.
diff --git a/modules/installation-openstack-ovs-dpdk-performance-profile.adoc b/modules/installation-openstack-ovs-dpdk-performance-profile.adoc
index c3b8717bc9b0..c6137b2e9a14 100644
--- a/modules/installation-openstack-ovs-dpdk-performance-profile.adoc
+++ b/modules/installation-openstack-ovs-dpdk-performance-profile.adoc
@@ -39,9 +39,9 @@ spec:
         size: 1G
   nodeSelector:
     node-role.kubernetes.io/worker: ''
+  globallyDisableIrqLoadBalancing: true
   realTimeKernel:
     enabled: false
-    globallyDisableIrqLoadBalancing: true
 ----
 
 Insert values that are appropriate for your configuration for the `CPU_ISOLATED`, `CPU_RESERVED`, and `HUGEPAGES_COUNT` keys.
diff --git a/modules/installation-osp-creating-network-resources.adoc b/modules/installation-osp-creating-network-resources.adoc
index 4aaeba644414..ed4199843a95 100644
--- a/modules/installation-osp-creating-network-resources.adoc
+++ b/modules/installation-osp-creating-network-resources.adoc
@@ -17,6 +17,29 @@ Create the network resources that an {product-title} on {rh-openstack-first} ins
 
 . For a dual stack cluster deployment, edit the `inventory.yaml` file and uncomment the `os_subnet6` attribute.
 
+. To ensure that your network resources have unique names on the {rh-openstack} deployment, create an environment variable and JSON file for use in the Ansible playbooks:
++
+.. Create an environment variable that has a unique name value by running the following command:
++
+[source,terminal]
+----
+$ export OS_NET_ID="openshift-$(dd if=/dev/urandom count=4 bs=1 2>/dev/null |hexdump -e '"%02x"')"
+----
+
+.. Verify that the variable is set by running the following command on a command line:
++
+[source,terminal]
+----
+$ echo $OS_NET_ID
+----
+
+.. Create a JSON object that includes the variable in a file called `netid.json` by running the following command:
++
+[source,terminal]
+----
+$ echo "{\"os_net_id\": \"$OS_NET_ID\"}" | tee netid.json
+----
+
 . On a command line, create the network resources by running the following command:
 +
 [source,terminal]
diff --git a/modules/installation-osp-fixing-subnet.adoc b/modules/installation-osp-fixing-subnet.adoc
index b6b58df985c5..04f8ffc00ca7 100644
--- a/modules/installation-osp-fixing-subnet.adoc
+++ b/modules/installation-osp-fixing-subnet.adoc
@@ -24,22 +24,39 @@ The IP range that the installation program uses by default might not match the N
 +
 [source,terminal]
 ----
-$ python -c 'import yaml
+$ python -c 'import os
+import sys
+import yaml
+import re
+re_os_net_id = re.compile(r"{{\s*os_net_id\s*}}")
+os_net_id = os.getenv("OS_NET_ID")
+path = "common.yaml"
+facts = None
+for _dict in yaml.safe_load(open(path))[0]["tasks"]:
+    if "os_network" in _dict.get("set_fact", {}):
+        facts = _dict["set_fact"]
+        break
+if not facts:
+    print("Cannot find `os_network` in common.yaml file. Make sure OpenStack resource names are defined in one of the tasks.")
+    sys.exit(1)
+os_network = re_os_net_id.sub(os_net_id, facts["os_network"])
+os_subnet = re_os_net_id.sub(os_net_id, facts["os_subnet"])
 path = "install-config.yaml"
 data = yaml.safe_load(open(path))
 inventory = yaml.safe_load(open("inventory.yaml"))["all"]["hosts"]["localhost"]
 machine_net = [{"cidr": inventory["os_subnet_range"]}]
 api_vips = [inventory["os_apiVIP"]]
 ingress_vips = [inventory["os_ingressVIP"]]
-ctrl_plane_port = {"network": {"name": inventory["os_network"]}, "fixedIPs": [{"subnet": {"name": inventory["os_subnet"]}}]}
-if inventory.get("os_subnet6"): <1>
+ctrl_plane_port = {"network": {"name": os_network}, "fixedIPs": [{"subnet": {"name": os_subnet}}]}
+if inventory.get("os_subnet6_range"): <1>
+    os_subnet6 = re_os_net_id.sub(os_net_id, facts["os_subnet6"])
     machine_net.append({"cidr": inventory["os_subnet6_range"]})
     api_vips.append(inventory["os_apiVIP6"])
     ingress_vips.append(inventory["os_ingressVIP6"])
     data["networking"]["networkType"] = "OVNKubernetes"
     data["networking"]["clusterNetwork"].append({"cidr": inventory["cluster_network6_cidr"], "hostPrefix": inventory["cluster_network6_prefix"]})
     data["networking"]["serviceNetwork"].append(inventory["service_subnet6_range"])
-    ctrl_plane_port["fixedIPs"].append({"subnet": {"name": inventory["os_subnet6"]}})
+    ctrl_plane_port["fixedIPs"].append({"subnet": {"name": os_subnet6}})
 data["networking"]["machineNetwork"] = machine_net
 data["platform"]["openstack"]["apiVIPs"] = api_vips
 data["platform"]["openstack"]["ingressVIPs"] = ingress_vips
diff --git a/modules/installation-special-config-chrony.adoc b/modules/installation-special-config-chrony.adoc
index 545d6bd717b5..3e282ca06ada 100644
--- a/modules/installation-special-config-chrony.adoc
+++ b/modules/installation-special-config-chrony.adoc
@@ -59,6 +59,11 @@ storage:
 <1> On control plane nodes, substitute `master` for `worker` in both of these locations.
 <2> Specify an octal value mode for the `mode` field in the machine config file. After creating the file and applying the changes, the `mode` is converted to a decimal value. You can check the YAML file with the command `oc get mc <mc-name> -o yaml`.
 <3> Specify any valid, reachable time source, such as the one provided by your DHCP server.
++
+[NOTE]
+====
+For all-machine to all-machine communication, the Network Time Protocol (NTP) on UDP is port `123`. If an external NTP time server is configured, you must open UDP port `123`.
+====
 ifndef::restricted[Alternately, you can specify any of the following NTP servers: `1.rhel.pool.ntp.org`, `2.rhel.pool.ntp.org`, or `3.rhel.pool.ntp.org`.]
 
 . Use Butane to generate a `MachineConfig` object file, `99-worker-chrony.yaml`, containing the configuration to be delivered to the nodes:
diff --git a/modules/installation-special-config-raid-intel-vroc.adoc b/modules/installation-special-config-raid-intel-vroc.adoc
index 7bef82942220..7d951a7d472e 100644
--- a/modules/installation-special-config-raid-intel-vroc.adoc
+++ b/modules/installation-special-config-raid-intel-vroc.adoc
@@ -31,14 +31,14 @@ $ mdadm -CR /dev/md/imsm0 -e \
 +
 [source,terminal]
 ----
-$ mdadm -CR /dev/md/dummy -l0 -n2 /dev/imsm0 -z10M --assume-clean
+$ mdadm -CR /dev/md/dummy -l0 -n2 /dev/md/imsm0 -z10M --assume-clean
 ----
 
 .. Create the real RAID1 array by running the following command:
 +
 [source,terminal]
 ----
-$ mdadm -CR /dev/md/coreos -l1 -n2 /dev/imsm0
+$ mdadm -CR /dev/md/coreos -l1 -n2 /dev/md/imsm0
 ----
 
 .. Stop both RAID0 and RAID1 member arrays and delete the dummy RAID0 array with the following commands:
diff --git a/modules/installation-user-infra-machines-iso.adoc b/modules/installation-user-infra-machines-iso.adoc
index 25c27ab9d5bb..72e8697e7e66 100644
--- a/modules/installation-user-infra-machines-iso.adoc
+++ b/modules/installation-user-infra-machines-iso.adoc
@@ -85,10 +85,10 @@ $ openshift-install coreos print-stream-json | grep '\.iso[^.]'
 [source,terminal]
 ifndef::openshift-origin[]
 ----
-"location": "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
-"location": "<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
-"location": "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
-"location": "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
+"location": "<url>/art/storage/releases/rhcos-4.18-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
+"location": "<url>/art/storage/releases/rhcos-4.18-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
+"location": "<url>/art/storage/releases/rhcos-4.18-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
+"location": "<url>/art/storage/releases/rhcos-4.18/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
 ----
 endif::openshift-origin[]
 ifdef::openshift-origin[]
diff --git a/modules/installation-user-infra-machines-pxe.adoc b/modules/installation-user-infra-machines-pxe.adoc
index 4efac2c4d007..c572d99b1ca0 100644
--- a/modules/installation-user-infra-machines-pxe.adoc
+++ b/modules/installation-user-infra-machines-pxe.adoc
@@ -101,18 +101,18 @@ $ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initra
 [source,terminal]
 ifndef::openshift-origin[]
 ----
-"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
-"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
-"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
-"<url>/art/storage/releases/rhcos-4.17-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
-"<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
-"<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
-"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
-"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
-"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
-"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
-"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
-"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"
+"<url>/art/storage/releases/rhcos-4.18-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
+"<url>/art/storage/releases/rhcos-4.18-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
+"<url>/art/storage/releases/rhcos-4.18-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
+"<url>/art/storage/releases/rhcos-4.18-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
+"<url>/art/storage/releases/rhcos-4.18-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
+"<url>/art/storage/releases/rhcos-4.18-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
+"<url>/art/storage/releases/rhcos-4.18-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
+"<url>/art/storage/releases/rhcos-4.18-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
+"<url>/art/storage/releases/rhcos-4.18-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
+"<url>/art/storage/releases/rhcos-4.18/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
+"<url>/art/storage/releases/rhcos-4.18/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
+"<url>/art/storage/releases/rhcos-4.18/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"
 ----
 endif::openshift-origin[]
 ifdef::openshift-origin[]
diff --git a/modules/installation-vsphere-infrastructure.adoc b/modules/installation-vsphere-infrastructure.adoc
index 2c64fa747d75..e8c77d5417f8 100644
--- a/modules/installation-vsphere-infrastructure.adoc
+++ b/modules/installation-vsphere-infrastructure.adoc
@@ -44,7 +44,7 @@ You must ensure that the time on your ESXi hosts is synchronized before you inst
 
 |CPU micro-architecture
 |x86-64-v2 or higher
-|OpenShift 4.13 and later are based on RHEL 9.2 host operating system which raised the microarchitecture requirements to x86-64-v2. See the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.0_release_notes/index#architectures[RHEL Microarchitecture requirements documentation]. You can verify compatibility by following the procedures outlined in link:https://access.redhat.com/solutions/7052996[this KCS article].
+|{product-title} version 4.13 and later are based on the {op-system-base} 9.2 host operating system, which raised the microarchitecture requirements to x86-64-v2. See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.2_release_notes/index#architectures[Architectures] in the {op-system-base} documentation.
 |===
 
 [IMPORTANT]
diff --git a/modules/installation-vsphere-machines.adoc b/modules/installation-vsphere-machines.adoc
index 1f088fc2f097..0c0b7765779c 100644
--- a/modules/installation-vsphere-machines.adoc
+++ b/modules/installation-vsphere-machines.adoc
@@ -79,7 +79,7 @@ If you plan to add more compute machines to your cluster after you finish instal
 ====
 
 ifndef::openshift-origin[]
-. Obtain the {op-system} OVA image. Images are available from the link:https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.17/[{op-system} image mirror] page.
+. Obtain the {op-system} OVA image. Images are available from the link:https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/[{op-system} image mirror] page.
 +
 [IMPORTANT]
 ====
diff --git a/modules/installation-vsphere-multiple-nics.adoc b/modules/installation-vsphere-multiple-nics.adoc
new file mode 100644
index 000000000000..a81afbc718c0
--- /dev/null
+++ b/modules/installation-vsphere-multiple-nics.adoc
@@ -0,0 +1,80 @@
+// Module included in the following assemblies:
+//
+// * installing/installing-vsphere-installer-provisioned-network-customizations.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="installation-vsphere-multiple-nics_{context}"]
+= Configuring multiple NICs
+
+For scenarios requiring multiple network interface controller (NIC), you can configure multiple network adapters per node. 
+
+:FeatureName: Configuring multiple NICs
+include::snippets/technology-preview.adoc[]
+
+.Procedure
+
+. Specify the network adapter names in the networks section of `platform.vsphere.failureDomains[*].topology` as shown in the following `install-config.yaml` file:
++
+[source,yaml]
+----
+platform:
+  vsphere:
+    vcenters:
+      ...
+    failureDomains:
+    - name: <failure_domain_name>
+      region: <default_region_name>
+      zone: <default_zone_name>
+      server: <fully_qualified_domain_name>
+      topology:
+        datacenter: <data_center>
+        computeCluster: "/<data_center>/host/<cluster>"
+        networks: # <1>
+        - <VM_network1_name>
+        - <VM_network2_name>
+        - ...
+        - <VM_network10_name>
+----
+<1> Specifies the list of network adapters. You can specify up to 10 network adapters.
+
+. Specify at least one of the following configurations in the `install-config.yaml` file:
+
+** `networking.machineNetwork`
++
+.Example configuration
++
+[source,yaml]
+----
+networking:
+  ...
+  machineNetwork:
+  - cidr: 10.0.0.0/16
+  ...
+----
++
+[NOTE]
+====
+The `networking.machineNetwork.cidr` field must correspond to an address on the first adapter defined in `topology.networks`.
+====
+
+** Add a `nodeNetworking` object to the `install-config.yaml` file and specify internal and external network subnet CIDR implementations for the object.
++
+.Example configuration
++
+[source,yaml]
+----
+platform:
+  vsphere:
+    nodeNetworking:
+     external:
+       networkSubnetCidr:
+       - <machine_network_cidr_ipv4>
+       - <machine_network_cidr_ipv6>
+     internal:
+       networkSubnetCidr:
+       - <machine_network_cidr_ipv4>
+       - <machine_network_cidr_ipv6>
+    failureDomains:
+    - name: <failure_domain_name>
+      region: <default_region_name>
+----
\ No newline at end of file
diff --git a/modules/installing-a-cluster-with-multiarch-support.adoc b/modules/installing-a-cluster-with-multiarch-support.adoc
index c0d9631ec3a3..1204f05478bf 100644
--- a/modules/installing-a-cluster-with-multiarch-support.adoc
+++ b/modules/installing-a-cluster-with-multiarch-support.adoc
@@ -22,7 +22,7 @@ $ ./openshift-install version
 .Example output
 [source,terminal]
 ----
-./openshift-install 4.17.0
+./openshift-install 4.18.0
 built from commit abc123etc
 release image quay.io/openshift-release-dev/ocp-release@sha256:abc123wxyzetc
 release architecture multi
diff --git a/modules/installing-cluster-compare.adoc b/modules/installing-cluster-compare.adoc
index b09a0cac0153..0718a37eeac0 100644
--- a/modules/installing-cluster-compare.adoc
+++ b/modules/installing-cluster-compare.adoc
@@ -23,7 +23,7 @@ Install the `cluster-compare` plugin to compare a reference configuration with a
 +
 [source,terminal]
 ----
-$ podman login registry.access.redhat.com
+$ podman login registry.redhat.io
 ----
 
 . Create a container for the `cluster-compare` image by running the following command:
diff --git a/modules/installing-oadp-rosa-sts.adoc b/modules/installing-oadp-rosa-sts.adoc
index 5f386fe6ee14..f8926d64aef8 100644
--- a/modules/installing-oadp-rosa-sts.adoc
+++ b/modules/installing-oadp-rosa-sts.adoc
@@ -46,11 +46,10 @@ $ cat <<EOF > ${SCRATCH}/credentials
   [default]
   role_arn = ${ROLE_ARN}
   web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
-  region = <aws_region> <1>
+  region = <aws_region> # <1>
 EOF
 ----
-<1> The AWS region in which the cloud resources have been created.
-
+<1> Replace `<aws_region>` with the AWS region to use for the {sts-short} endpoint.
 .. Create a namespace for OADP:
 +
 [source,terminal]
@@ -164,7 +163,7 @@ $ cat << EOF | oc create -f -
     name: ${CLUSTER_NAME}-dpa
     namespace: openshift-adp
   spec:
-    backupImages: true <1>
+    backupImages: true # <1>
     features:
       dataMover:
         enable: false
@@ -185,11 +184,14 @@ $ cat << EOF | oc create -f -
         - openshift
         - aws
         - csi
-      restic:
+      nodeAgent:  # <2>
         enable: false
+        uploaderType: kopia # <3>
 EOF
 ----
 <1> ROSA supports internal image backup. Set this field to `false` if you do not want to use image backup.
+<2> See the important note regarding the `nodeAgent` attribute.
+<3> The type of uploader. The possible values are `restic` or `kopia`. The built-in Data Mover uses Kopia as the default uploader mechanism regardless of the value of the `uploaderType` field.
 
 // . Create the `DataProtectionApplication` resource, which is used to configure the connection to the storage where the backups and volume snapshots are stored:
 
@@ -204,10 +206,7 @@ $ cat << EOF | oc create -f -
     name: ${CLUSTER_NAME}-dpa
     namespace: openshift-adp
   spec:
-    backupImages: true <1>
-    features:
-      dataMover:
-         enable: false
+    backupImages: true # <1>
     backupLocations:
     - bucket:
         cloudStorageRef:
@@ -224,16 +223,16 @@ $ cat << EOF | oc create -f -
         defaultPlugins:
         - openshift
         - aws
-      nodeAgent: <2>
+      nodeAgent: # <2>
         enable: false
         uploaderType: restic
     snapshotLocations:
       - velero:
           config:
-            credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials <3>
-            enableSharedConfig: "true" <4>
-            profile: default <5>
-            region: ${REGION} <6>
+            credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials # <3>
+            enableSharedConfig: "true" # <4>
+            profile: default # <5>
+            region: ${REGION} # <6>
           provider: aws
 EOF
 ----
diff --git a/modules/installing-oci-about-agent-based-installer.adoc b/modules/installing-oci-about-agent-based-installer.adoc
index 715c0cfc56fc..7347aa953c5e 100644
--- a/modules/installing-oci-about-agent-based-installer.adoc
+++ b/modules/installing-oci-about-agent-based-installer.adoc
@@ -20,7 +20,7 @@ image::684_OpenShift_Installing_on_OCI_0624-connected.png[Image of a high-level
 .Workflow for using the Agent-based installer in a disconnected environment to install a cluster on {oci}
 image::684_OpenShift_Installing_on_OCI_0624-disconnected.png[Image of a high-level workflow for using the Agent-based installer in a disconnected environment to install a cluster on {oci}]
 
-{oci} provides services that can meet your regulatory compliance, performance, and cost-effectiveness needs. {oci} supports 64-bit `x86` instances and 64-bit `ARM` instances. Additionally, {oci} provides an {ocvs} service where you can move VMware workloads to {oci} with minimal application re-architecture.
+{oci} provides services that can meet your regulatory compliance, performance, and cost-effectiveness needs. {oci} supports 64-bit `x86` instances and 64-bit `ARM` instances.
 
 [NOTE]
 ====
@@ -33,10 +33,6 @@ By running your {product-title} cluster on {oci}, you can access the following c
 
 * Block Volume storage, where you can configure scaling and auto-tuning settings for your storage volume, so that the Block Volume service automatically adjusts the performance level to optimize performance.
 
-// Should I remove the reference below of ocvs? If so, what should the new phrasing be?
-
-* {ocvs-first}, where you can deploy a cluster in a public-cloud environment that operates on a VMware® vSphere software-defined data center (SDDC). You continue to retain full-administrative control over your VMware vSphere environment, but you can use {oci} services to improve your applications on flexible, scalable, and secure infrastructure.
-
 [IMPORTANT]
 ====
 To ensure the best performance conditions for your cluster workloads that operate on {oci} and on the OCVS service, ensure volume performance units (VPUs) for your block volume is sized for your workloads. The following list provides some guidance in selecting the VPUs needed for specific performance needs:
diff --git a/modules/installing-oci-adding-hosts-day-two.adoc b/modules/installing-oci-adding-hosts-day-two.adoc
new file mode 100644
index 000000000000..3044b3b39c05
--- /dev/null
+++ b/modules/installing-oci-adding-hosts-day-two.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-oci-assisted-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="installing-oci-adding-hosts-day-two_{context}"]
+= Adding hosts to the cluster following the installation
+
+After creating a cluster with the {ai-full}, you can use the {hybrid-console} to add new host nodes to the cluster and approve their certificate signing requests (CRSs).
+
+For details, see link:https://docs.oracle.com/en-us/iaas/Content/openshift-on-oci/adding-nodes.htm[Adding Nodes to a Cluster (Oracle documentation)].
diff --git a/modules/installing-ocp-agent-basic-inputs.adoc b/modules/installing-ocp-agent-basic-inputs.adoc
new file mode 100644
index 000000000000..4286d8cbdb89
--- /dev/null
+++ b/modules/installing-ocp-agent-basic-inputs.adoc
@@ -0,0 +1,110 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="installing-ocp-agent-basic-inputs_{context}"]
+= Creating the configuration inputs
+
+
+You must create the configuration files that are used by the installation program to create the agent image.
+
+.Procedure
+
+. Place the `openshift-install` binary in a directory that is on your PATH.
+
+. Create a directory to store the install configuration by running the following command:
++
+[source,terminal]
+----
+$ mkdir ~/<directory_name>
+----
+
+. Create the `install-config.yaml` file by running the following command:
++
+--
+[source,terminal]
+----
+$ cat << EOF > ./my-cluster/install-config.yaml
+apiVersion: v1
+baseDomain: test.example.com
+compute:
+- architecture: amd64 // <1>
+  hyperthreading: Enabled
+  name: worker
+  replicas: 0
+controlPlane:
+  architecture: amd64
+  hyperthreading: Enabled
+  name: master
+  replicas: 1
+metadata:
+  name: sno-cluster // <2>
+networking:
+  clusterNetwork:
+  - cidr: fd01::/48
+    hostPrefix: 64
+  machineNetwork:
+  - cidr: fd2e:6f44:5dd8:c956::/120
+  networkType: OVNKubernetes // <3>
+  serviceNetwork:
+  - fd02::/112
+platform: <4>
+  none: {}
+pullSecret: '<pull_secret>' // <5>
+sshKey: '<ssh_pub_key>' // <6>
+additionalTrustBundle: | // <7>
+  -----BEGIN CERTIFICATE-----
+  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
+  -----END CERTIFICATE-----
+imageContentSources: // <8>
+- mirrors:
+  - <local_registry>/<local_repository_name>/release
+  source: quay.io/openshift-release-dev/ocp-release
+- mirrors:
+  - <local_registry>/<local_repository_name>/release
+  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
+EOF
+----
+<1> Specify the system architecture. Valid values are `amd64`, `arm64`, `ppc64le`, and `s390x`.
++
+If you are using the release image with the `multi` payload, you can install the cluster on different architectures such as `arm64`, `amd64`, `s390x`, and `ppc64le`. Otherwise, you can install the cluster only on the `release architecture` displayed in the output of the `openshift-install version` command. For more information, see "Verifying the supported architecture for installing an Agent-based Installer cluster".
+<2> Required. Specify your cluster name.
+<3> The cluster network plugin to install. The default value `OVNKubernetes` is the only supported value.
+<4> Specify your platform.
++
+[NOTE]
+====
+For bare metal platforms, host settings made in the platform section of the `install-config.yaml` file are used by default, unless they are overridden by configurations made in the `agent-config.yaml` file.
+====
+<5> Specify your pull secret.
+<6> Specify your SSH public key.
+<7> Provide the contents of the certificate file that you used for your mirror registry.
+The certificate file can be an existing, trusted certificate authority or the self-signed certificate that you generated for the mirror registry.
+You must specify this parameter if you are using a disconnected mirror registry.
+<8> Provide the `imageContentSources` section according to the output of the command that you used to mirror the repository.
+You must specify this parameter if you are using a disconnected mirror registry.
++
+[IMPORTANT]
+====
+* When using the `oc adm release mirror` command, use the output from the `imageContentSources` section.
+* When using the `oc mirror` command, use the `repositoryDigestMirrors` section of the `ImageContentSourcePolicy` file that results from running the command.
+* The `ImageContentSourcePolicy` resource is deprecated.
+====
+--
+
+. Create the `agent-config.yaml` file by running the following command:
++
+[source,terminal]
+----
+$ cat > agent-config.yaml << EOF
+apiVersion: v1beta1
+kind: AgentConfig
+metadata:
+  name: sno-cluster
+rendezvousIP: fd2e:6f44:5dd8:c956::50 // <1>
+EOF
+----
++
+<1> This IP address is used to determine which node performs the bootstrapping process as well as running the `assisted-service` component.
+You must provide the rendezvous IP address when you do not specify at least one host IP address in the `networkConfig` parameter. If this address is not provided, one IP address is selected from the provided host `networkConfig` parameter.
diff --git a/modules/installing-ocp-agent-boot.adoc b/modules/installing-ocp-agent-boot.adoc
index 97cb3a50a5db..f381d4198fbb 100644
--- a/modules/installing-ocp-agent-boot.adoc
+++ b/modules/installing-ocp-agent-boot.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-boot_{context}"]
diff --git a/modules/installing-ocp-agent-download.adoc b/modules/installing-ocp-agent-download.adoc
index 7fe462b0a270..636774668db5 100644
--- a/modules/installing-ocp-agent-download.adoc
+++ b/modules/installing-ocp-agent-download.adoc
@@ -2,6 +2,8 @@
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
 // * installing/installing_with_agent_based_installer/prepare-pxe-infra-agent.adoc
+// * installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-retrieve_{context}"]
diff --git a/modules/installing-ocp-agent-gather-log.adoc b/modules/installing-ocp-agent-gather-log.adoc
index c1e212b00612..f8321d8fb95f 100644
--- a/modules/installing-ocp-agent-gather-log.adoc
+++ b/modules/installing-ocp-agent-gather-log.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-gather-log_{context}"]
diff --git a/modules/installing-ocp-agent-ibm-z-kvm.adoc b/modules/installing-ocp-agent-ibm-z-kvm.adoc
index 81e2995b4296..cb53329e3049 100644
--- a/modules/installing-ocp-agent-ibm-z-kvm.adoc
+++ b/modules/installing-ocp-agent-ibm-z-kvm.adoc
@@ -49,10 +49,12 @@ $ virt-install \
    --osinfo detect=on,require=off
 ----
 <1> For the `--location` parameter, specify the location of the kernel/initrd on the HTTP or HTTPS server.
+
 endif::pxe-boot[]
 
 ifndef::pxe-boot[]
 +
+.ISO boot
 [source,terminal]
 ----
 $ virt-install
@@ -72,6 +74,43 @@ $ virt-install
 <1> For the `--cdrom` parameter, specify the location of the ISO image on the HTTP or HTTPS server.
 endif::pxe-boot[]
 
+. Optional: Enable FIPS mode.
++
+To enable FIPS mode on {ibm-z-name} clusters with {op-system-base} KVM you must use PXE boot instead and run the `virt-install` command with the following parameters:
++
+.PXE boot
+[source,terminal]
+----
+$ virt-install \
+   --name <vm_name> \
+   --autostart \
+   --ram=16384 \
+   --cpu host \
+   --vcpus=8 \
+   --location <path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img \// <1>
+   --disk <qcow_image_path> \
+   --network network:macvtap ,mac=<mac_address> \
+   --graphics none \
+   --noautoconsole \
+   --wait=-1 \
+   --extra-args "rd.neednet=1 nameserver=<nameserver>" \
+   --extra-args "ip=<IP>::<nameserver>::<hostname>:enc1:none" \
+   --extra-args "coreos.live.rootfs_url=http://<http_server>:8080/agent.s390x-rootfs.img" \
+   --extra-args "random.trust_cpu=on rd.luks.options=discard" \
+   --extra-args "ignition.firstboot ignition.platform.id=metal" \
+   --extra-args "console=tty1 console=ttyS1,115200n8" \
+   --extra-args "coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8" \
+   --extra-args "fips=1" \// <2>
+   --osinfo detect=on,require=off
+----
+<1> For the `--location` parameter, specify the location of the kernel/initrd on the HTTP or HTTPS server.
+<2> To enable FIPS mode, specify `fips=1`. This entry is required in addition to setting the `fips` parameter to `true` in the `install-config.yaml` file.
++
+[NOTE]
+====
+Currently, only PXE boot is supported to enable FIPS mode on {ibm-z-name}.
+====
+
 ifeval::["{context}" == "prepare-pxe-assets-agent"]
 :!pxe-boot:
 endif::[]
\ No newline at end of file
diff --git a/modules/installing-ocp-agent-ibm-z-zvm.adoc b/modules/installing-ocp-agent-ibm-z-zvm.adoc
index 7ae89676ca47..53184b69c001 100644
--- a/modules/installing-ocp-agent-ibm-z-zvm.adoc
+++ b/modules/installing-ocp-agent-ibm-z-zvm.adoc
@@ -23,13 +23,14 @@ Only use this procedure for {ibm-z-name} clusters with z/VM.
 ----
 rd.neednet=1 \
 console=ttysclp0 \
-coreos.live.rootfs_url=<rootfs_url> \ <1>
-ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \ <2>
-zfcp.allow_lun_scan=0 \ <3>
+coreos.live.rootfs_url=<rootfs_url> \// <1>
+ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \// <2>
+zfcp.allow_lun_scan=0 \// <3>
 ai.ip_cfg_override=1 \
 rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
-rd.dasd=0.0.4411 \ <4>
-rd.zfcp=0.0.8001,0x50050763040051e3,0x4000406300000000 \ <5>
+rd.dasd=0.0.4411 \// <4>
+rd.zfcp=0.0.8001,0x50050763040051e3,0x4000406300000000 \// <5>
+fips=1 \// <6>
 random.trust_cpu=on rd.luks.options=discard \
 ignition.firstboot ignition.platform.id=metal \
 console=tty1 console=ttyS1,115200n8 \
@@ -40,6 +41,7 @@ coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8"
 <3> The default is `1`. Omit this entry when using an OSA network adapter.
 <4> For installations on DASD-type disks, use `rd.dasd` to specify the DASD where {op-system-first} is to be installed. Omit this entry for FCP-type disks.
 <5> For installations on FCP-type disks, use `rd.zfcp=<adapter>,<wwpn>,<lun>` to specify the FCP disk where {op-system} is to be installed. Omit this entry for DASD-type disks.
+<6> To enable FIPS mode, specify `fips=1`. This entry is required in addition to setting the `fips` parameter to `true` in the `install-config.yaml` file.
 +
 Leave all other parameters unchanged.
 
diff --git a/modules/installing-ocp-agent-inputs.adoc b/modules/installing-ocp-agent-inputs.adoc
index dfd498acc9cf..08b8616e9a60 100644
--- a/modules/installing-ocp-agent-inputs.adoc
+++ b/modules/installing-ocp-agent-inputs.adoc
@@ -2,25 +2,40 @@
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
 // *installing/installing_with_agent_based_installer/prepare-pxe-infra-agent.adoc
+// * installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
 
 ifeval::["{context}" == "prepare-pxe-assets-agent"]
 :pxe-boot:
 endif::[]
 
+ifeval::["{context}" == "installing-using-iscsi"]
+:iscsi-boot:
+endif::[]
+
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-inputs_{context}"]
 = Creating the preferred configuration inputs
 
 ifndef::pxe-boot[]
 Use this procedure to create the preferred configuration inputs used to create the agent image.
+
+[NOTE]
+====
+Configuring the `install-config.yaml` and `agent-config.yaml` files is the preferred method for using the Agent-based Installer. Using {ztp} manifests is optional.
+====
 endif::pxe-boot[]
 ifdef::pxe-boot[]
 Use this procedure to create the preferred configuration inputs used to create the PXE files.
+
+[NOTE]
+====
+Configuring the `install-config.yaml` and `agent-config.yaml` files is the preferred method for using the Agent-based Installer. Using {ztp} manifests is optional.
+====
 endif::pxe-boot[]
 
 .Procedure
 
-. Install `nmstate` dependency by running the following command:
+. Install the `nmstate` dependency by running the following command:
 +
 [source,terminal]
 ----
@@ -36,12 +51,6 @@ $ sudo dnf install /usr/bin/nmstatectl -y
 $ mkdir ~/<directory_name>
 ----
 
-+
-[NOTE]
-====
-This is the preferred method for the Agent-based installation. Using {ztp} manifests is optional.
-====
-
 . Create the `install-config.yaml` file by running the following command:
 +
 --
@@ -86,7 +95,7 @@ If you are using the release image with the `multi` payload, you can install the
 +
 [NOTE]
 ====
-For bare metal platforms, host settings made in the platform section of the `install-config.yaml` file are used by default, unless they are overridden by configurations made in the `agent-config.yaml` file.
+For bare-metal platforms, host settings made in the platform section of the `install-config.yaml` file are used by default, unless they are overridden by configurations made in the `agent-config.yaml` file.
 ====
 <5> Specify your pull secret.
 <6> Specify your SSH public key.
@@ -173,6 +182,7 @@ hosts: // <2>
             next-hop-address: 192.168.111.2
             next-hop-interface: eno1
             table-id: 254
+ifdef::iscsi-boot[minimalISO: true <6>]
 EOF
 ----
 +
@@ -182,6 +192,10 @@ You must provide the rendezvous IP address when you do not specify at least one
 <3> Optional: Overrides the hostname obtained from either the Dynamic Host Configuration Protocol (DHCP) or a reverse DNS lookup. Each host must have a unique hostname supplied by one of these methods.
 <4> Enables provisioning of the {op-system-first} image to a particular device. The installation program examines the devices in the order it discovers them, and compares the discovered values with the hint values. It uses the first discovered device that matches the hint value.
 <5> Optional: Configures the network interface of a host in NMState format.
+ifdef::iscsi-boot[]
+<6> Generates an ISO image without the rootfs image file, and instead provides details about where to pull the rootfs file from.
+You must set this parameter to `true` to enable iSCSI booting.
+endif::iscsi-boot[]
 
 ifdef::pxe-boot[]
 
@@ -203,3 +217,7 @@ endif::pxe-boot[]
 ifeval::["{context}" == "prepare-pxe-assets-agent"]
 :!pxe-boot:
 endif::[]
+
+ifeval::["{context}" == "installing-using-iscsi"]
+:!iscsi-boot:
+endif::[]
\ No newline at end of file
diff --git a/modules/installing-ocp-agent-iscsi-files.adoc b/modules/installing-ocp-agent-iscsi-files.adoc
new file mode 100644
index 000000000000..4ab5801e640c
--- /dev/null
+++ b/modules/installing-ocp-agent-iscsi-files.adoc
@@ -0,0 +1,49 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="installing-ocp-agent-iscsi-files_{context}"]
+= Creating the installation files
+
+Use the following procedure to generate the ISO image and create an iPXE script to upload to your iSCSI target.
+
+.Procedure
+
+. Create the agent image by running the following command:
++
+[source,terminal]
+----
+$ openshift-install --dir <install_directory> agent create image
+----
+
+. Create an iPXE script by running the following command:
++
+[source,terminal]
+----
+$ cat << EOF > agent.ipxe
+!ipxe
+set initiator-iqn <iscsi_initiator_base>:\${hostname}
+sanboot --keep iscsi:<iscsi_network_subnet>.1::::<iscsi_target_base>:\${hostname}
+EOF
+----
++
+--
+where:
+
+<iscsi_initiator_base>:: Specifies the iSCSI initiator name on the host that is booting the ISO.
+This name can also be used by the iSCSI target.
+<iscsi_network_subnet>:: Specifies the IP address of the iSCSI target.
+<iscsi_target_base>:: Specifies the iSCSI target name.
+This name can be the same as the initiator name.
+--
++
+.Example Command
+[source,terminal]
+----
+$ cat << EOF > agent.ipxe
+!ipxe
+set initiator-iqn iqn.2023-01.com.example:\${hostname}
+sanboot --keep iscsi:192.168.45.1::::iqn.2023-01.com.example:\${hostname}
+EOF
+----
\ No newline at end of file
diff --git a/modules/installing-ocp-agent-iscsi-requirements.adoc b/modules/installing-ocp-agent-iscsi-requirements.adoc
new file mode 100644
index 000000000000..d32d9d0fb333
--- /dev/null
+++ b/modules/installing-ocp-agent-iscsi-requirements.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_with_agent_based_installer/installing-using-iscsi.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="iscsi-boot-requirements_{context}"]
+= Requirements for iSCSI booting
+
+The following configurations are necessary to enable iSCSI booting when using the Agent-based Installer:
+
+* Dynamic Host Configuration Protocol (DHCP) must be configured.
+Static networking is not supported.
+* You must create an additional network for iSCSI that is separate from the machine network of the cluster.
+The machine network is rebooted during cluster installation and cannot be used for the iSCSI session.
+* If the host on which you are booting the agent ISO image also has an installed disk, it might be necessary to specify the iSCSI disk name in the `rootDeviceHints` parameter to ensure that it is chosen as the boot disk for the final {op-system-first} image.
+You can also use a diskless environment for iSCSI booting, in which case you do not need to set the `rootDeviceHints` parameter.
\ No newline at end of file
diff --git a/modules/installing-ocp-agent-tui.adoc b/modules/installing-ocp-agent-tui.adoc
index e4a189986cf3..75222d989722 100644
--- a/modules/installing-ocp-agent-tui.adoc
+++ b/modules/installing-ocp-agent-tui.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-tui_{context}"]
diff --git a/modules/installing-ocp-agent-verify.adoc b/modules/installing-ocp-agent-verify.adoc
index 3deca318ea21..21285abacd12 100644
--- a/modules/installing-ocp-agent-verify.adoc
+++ b/modules/installing-ocp-agent-verify.adoc
@@ -1,6 +1,11 @@
 // Module included in the following assemblies:
 //
 // * installing/installing-with-agent-based-installer/installing-with-agent-based-installer.adoc
+// * installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc
+
+ifeval::["{context}" == "installing-with-agent-basic"]
+:basic:
+endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-ocp-agent-verify_{context}"]
@@ -59,6 +64,8 @@ INFO Access the OpenShift web-console here: https://console-openshift-console.ap
 ----
 
 
+// Note for a later doc effort - now that there is a section for ztp manifests, maybe this NOTE can be moved to that section?
+ifndef::basic[]
 [NOTE]
 ====
 If you are using the optional method of {ztp} manifests, you can configure IP address endpoints for cluster nodes through the `AgentClusterInstall.yaml` file in three ways:
@@ -92,3 +99,8 @@ networking:
   - fd03::/112
   networkType: OVNKubernetes
 ----
+endif::basic[]
+
+ifeval::["{context}" == "installing-with-agent-basic"]
+:!basic:
+endif::[]
\ No newline at end of file
diff --git a/modules/installing-wmco-using-web-console.adoc b/modules/installing-wmco-using-web-console.adoc
index 06545af44bfd..4c44cfb6c02d 100644
--- a/modules/installing-wmco-using-web-console.adoc
+++ b/modules/installing-wmco-using-web-console.adoc
@@ -36,9 +36,9 @@ Dual NIC is not supported on WMCO-managed Windows instances.
 * The *Automatic* strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
 +
 * The *Manual* strategy requires a user with appropriate credentials to approve the Operator update.
-
++
 //TODO add image of Installation page when official Operator is available.
-
++
 . Click *Install*. The WMCO is now listed on the *Installed Operators* page.
 +
 [NOTE]
diff --git a/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc b/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc
index 8bd9b2647a2a..3f990068740b 100644
--- a/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc
+++ b/modules/ipi-install-firmware-requirements-for-installing-with-virtual-media.adoc
@@ -29,16 +29,19 @@ Red Hat does not test every combination of firmware, hardware, or other third-pa
 | 16th Generation | iDRAC 9 | v7.10.70.00
 | 15th Generation | iDRAC 9 | v6.10.30.00 and v7.10.70.00
 | 14th Generation | iDRAC 9 | v6.10.30.00
-| 13th Generation .2+| iDRAC 8 | v2.75.75.75 or later
 
 |====
 
-
 .Firmware compatibility for Cisco UCS hardware with Redfish virtual media
 [cols="1,1,1",options="header"]
 |====
 | Model | Management | Firmware versions
-| UCS X-Series servers footnote:[Installer-provisioned installation is supported for UCS M6 Platform and later.] | CIMC | 5.2(2) or later
-| UCS C-Series servers in UCS managed domain | CIMC | 4.3 or later
-
+| UCS X-Series servers | Intersight Managed Mode  | 5.2(2) or later
+| FI-Attached UCS C-Series servers | Intersight Managed Mode | 4.3 or later
+| Standalone UCS C-Series servers | Standalone / Intersight | 4.3 or later
 |====
+
+[NOTE]
+====
+Always confirm that your server supports {op-system-first} on link:https://ucshcltool.cloudapps.cisco.com/public/[UCSHCL].
+====
diff --git a/modules/ipi-install-mirroring-for-disconnected-registry.adoc b/modules/ipi-install-mirroring-for-disconnected-registry.adoc
index e4243c26496e..fadc9cf47938 100644
--- a/modules/ipi-install-mirroring-for-disconnected-registry.adoc
+++ b/modules/ipi-install-mirroring-for-disconnected-registry.adoc
@@ -24,8 +24,14 @@ endif::[]
 .Procedure
 
 . Review the
+ifndef::openshift-origin[]
 link:https://access.redhat.com/downloads/content/290/[{product-title} downloads page]
 to determine the version of {product-title} that you want to install and determine the corresponding tag on the link:https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags[Repository Tags] page.
+endif::[]
+ifdef::openshift-origin[]
+link:https://github.com/okd-project/okd/releases/[{product-title} releases page]
+to determine the version and tag of {product-title} that you want to install.
+endif::[]
 
 . Set the required environment variables:
 .. Export the release version:
@@ -72,7 +78,7 @@ endif::[]
 ifdef::openshift-origin[]
 [source,terminal]
 ----
-$ PRODUCT_REPO='openshift'
+$ PRODUCT_REPO='okd'
 ----
 endif::[]
 
@@ -98,7 +104,7 @@ endif::[]
 ifdef::openshift-origin[]
 [source,terminal]
 ----
-$ RELEASE_NAME="okd"
+$ RELEASE_NAME="scos-release"
 ----
 endif::[]
 
diff --git a/modules/ipi-install-verifying-support-for-redfish-apis.adoc b/modules/ipi-install-verifying-support-for-redfish-apis.adoc
index a7ad8b376d4e..8f9954659c88 100644
--- a/modules/ipi-install-verifying-support-for-redfish-apis.adoc
+++ b/modules/ipi-install-verifying-support-for-redfish-apis.adoc
@@ -47,14 +47,14 @@ $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: appl
 +
 [source,terminal]
 ----
-$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
+$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
 ----
 
-. Check the status of setting the BIOS boot mode that uses `Legacy` or `UEFI` by running the following command:
+. Check the status of setting the firmware boot mode that uses `Legacy` or `UEFI` by running the following command:
 +
 [source,terminal]
 ----
-$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
+$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
 ----
 
 .List of Redfish virtual media APIs
@@ -63,19 +63,24 @@ $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json"  https://$Ser
 +
 [source,terminal]
 ----
-$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
+$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
 ----
 
-. Check the ability to mount virtual media by running the following command:
+. Virtual media might use `POST` or `PATCH`, depending on your hardware. Check the ability to mount virtual media by running one of the following commands:
 +
 [source,terminal]
 ----
-$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: *" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
+$ curl -u $USER:$PASS -X POST -H "Content-Type: application/json" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
+----
++
+[source,terminal]
+----
+$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
 ----
 
 [NOTE]
 ====
-The `PowerOn` and `PowerOff` commands for Redfish APIs are the same for the Redfish virtual media APIs.
+The `PowerOn` and `PowerOff` commands for Redfish APIs are the same for the Redfish virtual media APIs. In some hardware, you might only find the `VirtualMedia` resource under `Systems/$SystemID` instead of `Managers/$ManagerID`. For the `VirtualMedia` resource, the `UserName` and `Password` fields are optional.
 ====
 
 [IMPORTANT]
diff --git a/modules/k8s-nmstate-deploying-nmstate-CLI.adoc b/modules/k8s-nmstate-deploying-nmstate-CLI.adoc
index 1eac99c32a37..f4a1d771a942 100644
--- a/modules/k8s-nmstate-deploying-nmstate-CLI.adoc
+++ b/modules/k8s-nmstate-deploying-nmstate-CLI.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-the-kubernetes-nmstate-operator-CLI_{context}"]
-= Installing the Kubernetes NMState Operator using the CLI
+= Installing the Kubernetes NMState Operator by using the CLI
 
 You can install the Kubernetes NMState Operator by using the OpenShift CLI (`oc)`. After it is installed, the Operator can deploy the NMState State Controller as a daemon set across all of the cluster nodes.
 
@@ -74,10 +74,10 @@ $ oc get clusterserviceversion -n openshift-nmstate \
 ----
 +
 .Example output
-[source, terminal,subs="attributes+"]
+[source,terminal,subs="attributes+"]
 ----
-Name                                             Phase
-kubernetes-nmstate-operator.4.17.0-202210210157   Succeeded
+Name                                                          Phase
+kubernetes-nmstate-operator.{product-version}.0-202210210157  Succeeded
 ----
 
 . Create an instance of the `nmstate` Operator:
@@ -92,7 +92,7 @@ metadata:
 EOF
 ----
 
-. Verify the pods for NMState Operator are running:
+. Verify that all pods for the NMState Operator are in a `Running` state:
 +
 [source,terminal]
 ----
@@ -100,18 +100,11 @@ $ oc get pod -n openshift-nmstate
 ----
 +
 .Example output
-[source, terminal,subs="attributes+"]
-----
-Name                                      Ready   Status  Restarts  Age
-pod/nmstate-cert-manager-5b47d8dddf-5wnb5   1/1   Running  0         77s
-pod/nmstate-console-plugin-d6b76c6b9-4dcwm  1/1   Running  0         77s
-pod/nmstate-handler-6v7rm                   1/1   Running  0         77s
-pod/nmstate-handler-bjcxw                   1/1   Running  0         77s
-pod/nmstate-handler-fv6m2                   1/1   Running  0         77s
-pod/nmstate-handler-kb8j6                   1/1   Running  0         77s
-pod/nmstate-handler-wn55p                   1/1   Running  0         77s
-pod/nmstate-operator-f6bb869b6-v5m92        1/1   Running  0        4m51s
-pod/nmstate-webhook-66d6bbd84b-6n674        1/1   Running  0         77s
-pod/nmstate-webhook-66d6bbd84b-vlzrd        1/1   Running  0         77s
+[source,terminal,subs="attributes+"]
+----
+Name                                      Ready   Status   Restarts  Age
+pod/nmstate-handler-wn55p                 1/1     Running  0         77s
+pod/nmstate-operator-f6bb869b6-v5m92      1/1     Running  0         4m51s
+...
 ----
 
diff --git a/modules/k8s-nmstate-uninstall-operator.adoc b/modules/k8s-nmstate-uninstall-operator.adoc
new file mode 100644
index 000000000000..c46fb6a34f71
--- /dev/null
+++ b/modules/k8s-nmstate-uninstall-operator.adoc
@@ -0,0 +1,108 @@
+// Module included in the following assemblies:
+//
+// networking/k8s_nmstate/k8s-nmstate-about-the-kubernetes-nmstate-operator.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="k8s-nmstate-uninstall-operator_{context}"]
+= Uninstalling the Kubernetes NMState Operator
+
+You can use the {olm-first} to uninstall the Kubernetes NMState Operator, but by design {olm} does not delete any associated custom resource definitions (CRDs), custom resources (CRs), or API Services. 
+
+Before you uninstall the Kubernetes NMState Operator from the `Subcription` resource used by {olm}, identify what Kubernetes NMState Operator resources to delete. This identification ensures that you can delete resources without impacting your running cluster.
+
+If you need to reinstall the Kubernetes NMState Operator, see "Installing the Kubernetes NMState Operator by using the CLI" or "Installing the Kubernetes NMState Operator by using the web console".
+
+.Prerequisites
+
+* You have installed the {oc-first}.
+* You have installed the `jq` CLI tool.
+* You are logged in as a user with `cluster-admin` privileges.
+
+.Procedure
+
+. Unsubscribe the Kubernetes NMState Operator from the `Subcription` resource by running the following command:
++
+[source,terminal]
+----
+$ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
+----
+
+. Find the `ClusterServiceVersion` (CSV) resource that associates with the Kubernetes NMState Operator:
++
+[source,terminal]
+----
+$ oc get --namespace openshift-nmstate clusterserviceversion
+----
++
+.Example output that lists a CSV resource
+[source,terminal]
+----
+NAME                              	  DISPLAY                   	VERSION   REPLACES     PHASE
+kubernetes-nmstate-operator.v4.18.0   Kubernetes NMState Operator   4.18.0           	   Succeeded
+----
+
+. Delete the CSV resource. After you delete the file, {olm} deletes certain resources, such as `RBAC`, that it created for the Operator.
++
+[source,terminal]
+----
+$ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0
+----
+
+. Delete the `nmstate` CR and any associated `Deployment` resources by running the following commands:
++
+[source,terminal]
+----
+$ oc -n openshift-nmstate delete nmstate nmstate
+----
++
+[source,terminal]
+----
+$ oc delete --all deployments --namespace=openshift-nmstate
+----
+
+. After you deleted the `nmstate` CR, remove the `nmstate-console-plugin` console plugin name from the `console.operator.openshift.io/cluster` CR.
++
+.. Store the position of the `nmstate-console-plugin` entry that exists among the list of enable plugins by running the following command. The following command uses the `jq` CLI tool to store the index of the entry in an environment variable named `INDEX`:
++
+[source,terminal]
+----
+INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
+----
++
+.. Remove the `nmstate-console-plugin` entry from the `console.operator.openshift.io/cluster` CR by running the following patch command:
++
+[source,terminal]
+----
+$ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]" <1>
+----
+<1> `INDEX` is an auxiliary variable. You can specify a different name for this variable.
+
+. Delete all the custom resource definitions (CRDs), such as `nmstates.nmstate.io`, by running the following commands:
++
+[source,terminal]
+----
+$ oc delete crd nmstates.nmstate.io
+----
++
+[source,terminal]
+----
+$ oc delete crd nodenetworkconfigurationenactments.nmstate.io
+----
++
+[source,terminal]
+----
+$ oc delete crd nodenetworkstates.nmstate.io
+----
++
+[source,terminal]
+----
+$ oc delete crd nodenetworkconfigurationpolicies.nmstate.io
+----
+
+. Delete the namespace:
++
+[source,terminal]
+----
+$ oc delete namespace kubernetes-nmstate
+----
+
diff --git a/modules/kmm-applying-tolerations-to-kernel-module-pods.adoc b/modules/kmm-applying-tolerations-to-kernel-module-pods.adoc
new file mode 100644
index 000000000000..02530a82fbc5
--- /dev/null
+++ b/modules/kmm-applying-tolerations-to-kernel-module-pods.adoc
@@ -0,0 +1,68 @@
+// Module included in the following assemblies:
+//
+// * hardware_enablement/kmm-kernel-module-management.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="kmm-applying-tolerations-to-kernel-module-pods_{context}"]
+= Applying tolerations to kernel module pods 
+
+Taints and tolerations consist of `effect`, `key`, and `value` parameters. Tolerations include additional `operator` and `tolerationSeconds` parameters. 
+
+`effect`:: Indicates the taint effect to match. If left empty, all taint effects are matched. When you set `effect`, valid values are: `NoSchedule`, `PreferNoSchedule`, or `NoExecute`.
+
+`key`:: The taint key that the toleration applies to. If left empty, all taint keys are matched. If the `key` is empty, you must set the `operator` parameter to `Exists`. This combination matches all values and all keys.
+
+`value`:: The taint value the toleration matches to. If the `operator` parameter is `Exists`, the value must be empty, otherwise use a regular string.
+
+`operator`:: Represents a relationship of a key to the value. Valid `operator` parameters are `Exists` and `Equal`. The default value is `Equal`. `Exists` is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
+
+`tolerationSeconds`:: Represents the period of time the toleration (which must be of effect `NoExecute`, otherwise this field is ignored) tolerates the taint. By default, it is not set and the taint is tolerated forever without eviction. Zero and negative values are treated as `0` and immediately evicted by the system.
+
+.Example taint in a node specification
+[source,yaml]
+----
+apiVersion: v1
+kind: Node
+metadata:
+  name: <my_node>
+#...
+spec:
+  taints:
+  - effect: NoSchedule
+    key: key1
+    value: value1
+#...
+----
+
+.Example toleration in a module specification
+[source,yaml]
+----
+apiVersion: kmm.sigs.x-k8s.io/v1beta1
+kind: Module
+metadata:
+  name: <my_kmod>
+spec:
+  ...
+  tolerations:
+    effect: NoSchedule
+    key: key1
+    operator: Equal
+    tolerationSeconds: 36000
+    value: value1
+----
+
+Toleration values must match the taint that is added to the nodes. A toleration matches a taint:
+
+* If the `operator` parameter is set to `Equal`:
+
+** the `key` parameters are the same;
+
+** the `value` parameters are the same;
+
+** the `effect` parameters are the same.
+
+* If the `operator` parameter is set to `Exists`:
+
+** the `key` parameters are the same;
+
+** the `effect` parameters are the same.
\ No newline at end of file
diff --git a/modules/kmm-using-tolerations-for-kernel-module-scheduling.adoc b/modules/kmm-using-tolerations-for-kernel-module-scheduling.adoc
new file mode 100644
index 000000000000..9372fc8cf6f1
--- /dev/null
+++ b/modules/kmm-using-tolerations-for-kernel-module-scheduling.adoc
@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * hardware_enablement/kmm-kernel-module-management.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="kmm-using-tolerations-for-kernel-module-scheduling_{context}"]
+= Using tolerations for kernel module scheduling
+
+There are circumstances where you need to evacuate workloads on a node before upgrading a kernel module, which you can do through taints. You can use a taint to schedule only pods that contain a matching toleration on the node.
+
+However, you also need to set tolerations to allow Kernel Module Management (KMM) pods that run housekeeping operations, such as kernel module upgrades. The tolerations must match the taint that is added to the nodes.
+
+You can create user-defined tolerations to kernel modules to schedule selected KMM pods on a cordoned node. For example, during a device driver upgrade you cordon a node, at the same time, you can run housekeeping pods that perform the driver upgrades.
+
+The `ModuleSpec` field is used to carry the tolerations to the KMM pods that are used during pod creation.
diff --git a/modules/ldap-syncing-activedir.adoc b/modules/ldap-syncing-activedir.adoc
index 3e497003b9fa..1cd791cd7e11 100644
--- a/modules/ldap-syncing-activedir.adoc
+++ b/modules/ldap-syncing-activedir.adoc
@@ -48,12 +48,12 @@ during search and returned to the client, but not committed to the database.
 .Prerequisites
 
 * Create the configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-augmented-activedir.adoc b/modules/ldap-syncing-augmented-activedir.adoc
index 3a0fb8ab0ac9..0aeea936154e 100644
--- a/modules/ldap-syncing-augmented-activedir.adoc
+++ b/modules/ldap-syncing-augmented-activedir.adoc
@@ -58,12 +58,12 @@ member: cn=Jim,ou=users,dc=example,dc=com
 .Prerequisites
 
 * Create the configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-nesting.adoc b/modules/ldap-syncing-nesting.adoc
index 3c6a8858002e..0d71219ab3b1 100644
--- a/modules/ldap-syncing-nesting.adoc
+++ b/modules/ldap-syncing-nesting.adoc
@@ -136,12 +136,12 @@ of https://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx[`LDAP_MATCHIN
 .Prerequisites
 
 * Create the configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-rfc2307-user-defined-error.adoc b/modules/ldap-syncing-rfc2307-user-defined-error.adoc
index 312068c380c4..40b2f9207660 100644
--- a/modules/ldap-syncing-rfc2307-user-defined-error.adoc
+++ b/modules/ldap-syncing-rfc2307-user-defined-error.adoc
@@ -118,12 +118,12 @@ member of a group is out of scope.
 .Prerequisites
 
 * Create the configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-rfc2307.adoc b/modules/ldap-syncing-rfc2307.adoc
index 96acc2000e56..9154e526e69c 100644
--- a/modules/ldap-syncing-rfc2307.adoc
+++ b/modules/ldap-syncing-rfc2307.adoc
@@ -65,12 +65,12 @@ the group.
 .Prerequisites
 
 * Create the configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-running-all-ldap.adoc b/modules/ldap-syncing-running-all-ldap.adoc
index 85f2bab40297..b60b044fbcec 100644
--- a/modules/ldap-syncing-running-all-ldap.adoc
+++ b/modules/ldap-syncing-running-all-ldap.adoc
@@ -11,12 +11,12 @@ You can sync all groups from the LDAP server with {product-title}.
 .Prerequisites
 
 * Create a sync configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-running-openshift.adoc b/modules/ldap-syncing-running-openshift.adoc
index ae21e4d78769..5ce8f353eebb 100644
--- a/modules/ldap-syncing-running-openshift.adoc
+++ b/modules/ldap-syncing-running-openshift.adoc
@@ -12,12 +12,12 @@ LDAP server specified in the configuration file.
 .Prerequisites
 
 * Create a sync configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/ldap-syncing-running-subset.adoc b/modules/ldap-syncing-running-subset.adoc
index d2a3d55faed7..9f5872596ead 100644
--- a/modules/ldap-syncing-running-subset.adoc
+++ b/modules/ldap-syncing-running-subset.adoc
@@ -21,12 +21,12 @@ present in {product-title}.
 .Prerequisites
 
 * Create a sync configuration file.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/life-cycle-dates.adoc b/modules/life-cycle-dates.adoc
index 6b368b66de28..8f7d5d6afc3b 100644
--- a/modules/life-cycle-dates.adoc
+++ b/modules/life-cycle-dates.adoc
@@ -18,13 +18,13 @@ ifdef::rosa-with-hcp[]
 |4.17       |Oct 14, 2024           |Feb 14, 2026
 |4.16       |Jul 2, 2024            |Nov 2, 2025
 |4.15       |Feb 27, 2024           |Jun 30, 2025
-|4.14       |Dec 4, 2023            |Feb 28, 2025
+|4.14       |Dec 4, 2023            |May 1, 2025
 endif::rosa-with-hcp[]
 ifndef::rosa-with-hcp[]
 |4.17       |Oct 14, 2024           |Feb 14, 2026
 |4.16       |Jul 2, 2024            |Nov 2, 2025
 |4.15       |Feb 27, 2024           |Jun 30, 2025
-|4.14       |Oct 31, 2023           |Feb 28, 2025
+|4.14       |Oct 31, 2023           |May 1, 2025
 |4.13       |May 17, 2023           |Sep 17, 2024
 |4.12       |Jan 17, 2023           |Jul 17, 2024
 |4.11       |Aug 10, 2022           |Dec 10, 2023
diff --git a/modules/log6x-collection-setup.adoc b/modules/log6x-collection-setup.adoc
index 61d25e7ada27..4a85990fcc2b 100644
--- a/modules/log6x-collection-setup.adoc
+++ b/modules/log6x-collection-setup.adoc
@@ -18,6 +18,10 @@ To use the existing legacy service account `logcollector`, create the following
 [source,terminal]
 ----
 $ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
+----
+
+[source,terminal]
+----
 $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
 ----
 
diff --git a/modules/log6x-loki-pod-placement.adoc b/modules/log6x-loki-pod-placement.adoc
index fc1b5f79da17..e25a1b94ede4 100644
--- a/modules/log6x-loki-pod-placement.adoc
+++ b/modules/log6x-loki-pod-placement.adoc
@@ -81,15 +81,6 @@ spec:
       - effect: NoExecute
         key: node-role.kubernetes.io/infra
         value: reserved
-      nodeSelector:
-        node-role.kubernetes.io/infra: ""
-      tolerations:
-      - effect: NoSchedule
-        key: node-role.kubernetes.io/infra
-        value: reserved
-      - effect: NoExecute
-        key: node-role.kubernetes.io/infra
-        value: reserved
     indexGateway:
       nodeSelector:
         node-role.kubernetes.io/infra: ""
diff --git a/modules/log6x-loki-zone-fail-recovery.adoc b/modules/log6x-loki-zone-fail-recovery.adoc
index e94fde1c7d28..fa468ac2dc8c 100644
--- a/modules/log6x-loki-zone-fail-recovery.adoc
+++ b/modules/log6x-loki-zone-fail-recovery.adoc
@@ -61,14 +61,14 @@ wal-logging-loki-ruler-1
 +
 [source,terminal]
 ----
-$ oc delete pvc <pvc_name>  -n openshift-logging
+$ oc delete pvc <pvc_name> -n openshift-logging
 ----
 +
 . Delete the pod(s) by running the following command:
 +
 [source,terminal]
 ----
-$ oc delete pod <pod_name>  -n openshift-logging
+$ oc delete pod <pod_name> -n openshift-logging
 ----
 +
 Once these objects have been successfully deleted, they should automatically be rescheduled in an available zone.
diff --git a/modules/log6x-quickstart-viaq.adoc b/modules/log6x-quickstart-viaq.adoc
index 22486f380091..4195b211e0bb 100644
--- a/modules/log6x-quickstart-viaq.adoc
+++ b/modules/log6x-quickstart-viaq.adoc
@@ -9,11 +9,13 @@
 To use the default ViaQ data model, follow these steps:  
 
 .Prerequisites
-* Cluster administrator permissions
+* You have access to an {product-title} cluster with `cluster-admin` permissions.
+* You installed the {oc-first}.
+* You have access to a supported object store. For example, AWS S3, Google Cloud Storage, {azure-short}, Swift, Minio, or {rh-storage}.
 
 .Procedure
 
-. Install the {clo}, {loki-op}, and {coo-first} from OperatorHub.
+. Install the `{clo}`, `{loki-op}`, and `{coo-first}` from OperatorHub.
 
 . Create a `LokiStack` custom resource (CR) in the `openshift-logging` namespace:
 +
@@ -55,7 +57,7 @@ $ oc create sa collector -n openshift-logging
 +
 [source,terminal]
 ----
-$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
+$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector -n openshift-logging
 ----
 +
 [NOTE]
@@ -63,26 +65,21 @@ $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collec
 The `ClusterRole` resource is created automatically during the Cluster Logging Operator installation and does not need to be created manually.
 ====
 
-. Allow the collector's service account to collect logs:
+. To collect logs, use the service account of the collector by running the following commands:
 +
 [source,terminal]
 ----
-$ oc project openshift-logging
+$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector -n openshift-logging
 ----
 +
 [source,terminal]
 ----
-$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
+$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector -n openshift-logging
 ----
 +
 [source,terminal]
 ----
-$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
-----
-+
-[source,terminal]
-----
-$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
+$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector -n openshift-logging
 ----
 +
 [NOTE]
@@ -146,4 +143,4 @@ The `dataModel` field is optional and left unset (`dataModel: ""`) by default. T
 ====
 
 .Verification
-* Verify that logs are visible in the *Log* section of the *Observe* tab in the OpenShift web console.
\ No newline at end of file
+* Verify that logs are visible in the *Log* section of the *Observe* tab in the {product-title} web console.
diff --git a/modules/logging-loki-storage-odf.adoc b/modules/logging-loki-storage-odf.adoc
index dc88ed867cd4..3fe69f83bf88 100644
--- a/modules/logging-loki-storage-odf.adoc
+++ b/modules/logging-loki-storage-odf.adoc
@@ -10,7 +10,7 @@
 * You installed the {loki-op}.
 * You installed the {oc-first}.
 * You deployed link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/[{rh-storage}].
-* You configured your {rh-storage} cluster link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html/managing_and_allocating_storage_resources/adding-file-and-object-storage-to-an-existing-external-ocs-cluster[for object storage].
+* You configured your {rh-storage} cluster link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html/managing_and_allocating_storage_resources/adding-file-and-object-storage-to-an-existing-external-ocs-cluster[for object storage].
 
 .Procedure
 
diff --git a/modules/lvms-about-creating-lvmcluster-cr.adoc b/modules/lvms-about-creating-lvmcluster-cr.adoc
index d332bfabff8f..7153fba8e5bd 100644
--- a/modules/lvms-about-creating-lvmcluster-cr.adoc
+++ b/modules/lvms-about-creating-lvmcluster-cr.adoc
@@ -8,6 +8,11 @@
 
 You can create an `LVMCluster` custom resource (CR) by using the OpenShift CLI (`oc`) or the {product-title} web console. If you have installed {lvms} by using {rh-rhacm-first}, you can also create an `LVMCluster` CR by using {rh-rhacm}. 
 
+[IMPORTANT]
+====
+You must create the `LVMCluster` CR in the same namespace where you installed the {lvms} Operator, which is `openshift-storage` by default.
+====
+
 Upon creating the `LVMCluster` CR, {lvms} creates the following system-managed CRs:
 
 * A `storageClass` and `volumeSnapshotClass` for each device class.
diff --git a/modules/lvms-scaling-storage-expand-pvc.adoc b/modules/lvms-scaling-storage-expand-pvc.adoc
index 437705ce4f5c..d739bf34436a 100644
--- a/modules/lvms-scaling-storage-expand-pvc.adoc
+++ b/modules/lvms-scaling-storage-expand-pvc.adoc
@@ -23,8 +23,8 @@ To expand a PVC, you must update the `storage` field in the PVC.
 +
 [source,terminal]
 ----
-$ oc patch <pvc_name> -n <application_namespace> -p \ <1>
-'{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}} --type=merge' <2>
+$ oc patch pvc <pvc_name> -n <application_namespace> \ <1>
+--type=merge -p \ '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}' <2>
 ----
 <1> Replace `<pvc_name>` with the name of the PVC that you want to expand.
 <2> Replace `<desired_size>` with the new size to expand the PVC.
diff --git a/modules/machine-config-node-disruption-config.adoc b/modules/machine-config-node-disruption-config.adoc
index c1f3e95969d7..aadc68e96172 100644
--- a/modules/machine-config-node-disruption-config.adoc
+++ b/modules/machine-config-node-disruption-config.adoc
@@ -34,9 +34,9 @@ spec:
   nodeDisruptionPolicy: <1>
     files: # <2>
     - actions: # <3>
-      - reload: # <4>
+      - restart: # <4>
           serviceName: chronyd.service # <5>
-        type: Reload
+        type: Restart
       path: /etc/chrony.conf # <6>
     sshkey: # <7>
       actions:
@@ -93,9 +93,9 @@ status:
       files:
 # ...
       - actions:
-        - reload:
+        - restart:
             serviceName: chronyd.service
-          type: Reload
+          type: Restart
         path: /etc/chrony.conf
       sshkey:
         actions:
diff --git a/modules/machine-config-node-disruption-example.adoc b/modules/machine-config-node-disruption-example.adoc
index 868a9fec4234..aabf3146c965 100644
--- a/modules/machine-config-node-disruption-example.adoc
+++ b/modules/machine-config-node-disruption-example.adoc
@@ -20,6 +20,7 @@ The following example `MachineConfiguration` object shows no user defined polici
 ----
 apiVersion: operator.openshift.io/v1
 kind: MachineConfiguration
+metadata:
   name: cluster
 spec:
   logLevel: Normal
@@ -79,7 +80,6 @@ apiVersion: operator.openshift.io/v1
 kind: MachineConfiguration
 metadata:
   name: cluster
-  namespace: openshift-machine-config-operator
 # ...
 spec:
   nodeDisruptionPolicy:
@@ -96,7 +96,7 @@ spec:
 # ...
 ----
 
-In the following example, when changes are made to the `/etc/chrony.conf` file, the MCO reloads the `chronyd.service` on the cluster nodes. If files are added to or modified in the `/var/run` directory, the MCO applies the changes with no further action.
+In the following example, when changes are made to the `/etc/chrony.conf` file, the MCO restarts the `chronyd.service` on the cluster nodes. If files are added to or modified in the `/var/run` directory, the MCO applies the changes with no further action.
 
 .Example node disruption policy for a configuration file change
 [source,yaml]
@@ -105,15 +105,14 @@ apiVersion: operator.openshift.io/v1
 kind: MachineConfiguration
 metadata:
   name: cluster
-  namespace: openshift-machine-config-operator
 # ...
 spec:
   nodeDisruptionPolicy:
     files:
     - actions:
-      - reload:
+      - restart:
           serviceName: chronyd.service
-        type: Reload
+        type: Restart
         path: /etc/chrony.conf
     - actions:
       - type: None
@@ -129,7 +128,6 @@ apiVersion: operator.openshift.io/v1
 kind: MachineConfiguration
 metadata:
   name: cluster
-  namespace: openshift-machine-config-operator
 # ...
 spec:
   nodeDisruptionPolicy:
@@ -155,7 +153,6 @@ apiVersion: operator.openshift.io/v1
 kind: MachineConfiguration
 metadata:
   name: cluster
-  namespace: openshift-machine-config-operator
 # ...
 spec:
   nodeDisruptionPolicy:
diff --git a/modules/machine-config-overview.adoc b/modules/machine-config-overview.adoc
index 5d2e28547c2a..84e8df15a7af 100644
--- a/modules/machine-config-overview.adoc
+++ b/modules/machine-config-overview.adoc
@@ -31,7 +31,7 @@ a machine config that is injected directly into the {product-title} installer pr
 
 * MCO is only supported for writing to files in `/etc` and `/var` directories, although there are symbolic links to some directories that can be writeable by being symbolically linked to one of those areas. The `/opt` and `/usr/local` directories are examples.
 
-* Ignition is the configuration format used in MachineConfigs. See the link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition Configuration Specification v3.2.0] for details.
+* Ignition is the configuration format used in MachineConfigs. See the link:https://coreos.github.io/ignition/configuration-v3_4/[Ignition Configuration Specification v3.4.0] for details.
 
 * Although Ignition config settings can be delivered directly at {product-title} installation time, and are formatted in the same way that MCO delivers Ignition configs, MCO has no way of seeing what those original Ignition configs are. Therefore, you should wrap Ignition config settings into a machine config before deploying them.
 
diff --git a/modules/machine-user-infra-machines-ibm-z-kvm.adoc b/modules/machine-user-infra-machines-ibm-z-kvm.adoc
index d90215ae2a3a..750312d79af2 100644
--- a/modules/machine-user-infra-machines-ibm-z-kvm.adoc
+++ b/modules/machine-user-infra-machines-ibm-z-kvm.adoc
@@ -16,31 +16,6 @@ You can create more {op-system-first} compute machines for your cluster by using
 * An HTTP or HTTPS server is set up.
 
 .Procedure
-// Step 1 is a workaround for https://issues.redhat.com/browse/OCPBUGS-18394
-// Can be removed when bug is fixed.
-. Disable UDP aggregation.
-+
-Currently, UDP aggregation is not supported on {ibm-z-name} and is not automatically deactivated on multi-architecture compute clusters with an `x86_64` control plane and additional `s390x` compute machines. To ensure that the addtional compute nodes are added to the cluster correctly, you must manually disable UDP aggregation.
-
-.. Create a YAML file `udp-aggregation-config.yaml` with the following content:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-data:
-  disable-udp-aggregation: "true"
-metadata:
-  name: udp-aggregation-config
-  namespace: openshift-network-operator
-----
-
-.. Create the ConfigMap resource by running the following command:
-+
-[source,terminal]
-----
-$ oc create -f udp-aggregation-config.yaml
-----
 
 . Extract the Ignition config file from the cluster by running the following command:
 +
@@ -78,7 +53,7 @@ $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootim
 | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
 ----
 
-. Move the downloaded {op-system-base} live `kernel`, `initramfs` and `rootfs` files to an HTTP or HTTPS server before you launch `virt-install`.
+. Move the downloaded {op-system-base} live `kernel`, `initramfs`, and `rootfs` files to an HTTP or HTTPS server before you launch `virt-install`.
 
 . Create the new KVM guest nodes using the {op-system-base} `kernel`, `initramfs`, and Ignition files; the new disk image; and adjusted parm line arguments.
 +
diff --git a/modules/machine-user-infra-machines-ibm-z.adoc b/modules/machine-user-infra-machines-ibm-z.adoc
index d2f5cccc8228..28b796e4310e 100644
--- a/modules/machine-user-infra-machines-ibm-z.adoc
+++ b/modules/machine-user-infra-machines-ibm-z.adoc
@@ -1,12 +1,25 @@
 // Module included in the following assemblies:
 //
 // * post_installation_configuration/configuring-multi-arch-compute-machines/creating-multi-arch-compute-nodes-ibm-z.adoc
-
+ifeval::["{context}" == "creating-multi-arch-compute-nodes-ibm-z"]
+:ibm-z:
+endif::[]
+ifeval::["{context}" == "creating-multi-arch-compute-nodes-ibm-z-lpar"]
+:ibm-z-lpar:
+endif::[]
 :_mod-docs-content-type: PROCEDURE
+// Assumption is that attribute once outside ifdef works for several level one headings.
 [id="machine-user-infra-machines-ibm-z_{context}"]
+ifdef::ibm-z[]
 = Creating {op-system} machines on {ibm-z-title} with z/VM
 
 You can create more {op-system-first} compute machines running on {ibm-z-name} with z/VM and attach them to your existing cluster.
+endif::ibm-z[]
+ifdef::ibm-z-lpar[]
+= Creating {op-system} machines on {ibm-z-title} in an LPAR
+
+You can create more {op-system-first} compute machines running on {ibm-z-name} in a logical partition (LPAR) and attach them to your existing cluster.
+endif::ibm-z-lpar[]
 
 .Prerequisites
 
@@ -14,31 +27,6 @@ You can create more {op-system-first} compute machines running on {ibm-z-name} w
 * You have an HTTP or HTTPS server running on your provisioning machine that is accessible to the machines you create.
 
 .Procedure
-// Step 1 is a workaround for https://issues.redhat.com/browse/OCPBUGS-18394
-// Can be removed when bug is fixed.
-. Disable UDP aggregation.
-+
-Currently, UDP aggregation is not supported on {ibm-z-name} and is not automatically deactivated on multi-architecture compute clusters with an `x86_64` control plane and additional `s390x` compute machines. To ensure that the addtional compute nodes are added to the cluster correctly, you must manually disable UDP aggregation.
-
-.. Create a YAML file `udp-aggregation-config.yaml` with the following content:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-data:
-  disable-udp-aggregation: "true"
-metadata:
-  name: udp-aggregation-config
-  namespace: openshift-network-operator
-----
-
-.. Create the ConfigMap resource by running the following command:
-+
-[source,terminal]
-----
-$ oc create -f udp-aggregation-config.yaml
-----
 
 . Extract the Ignition config file from the cluster by running the following command:
 +
@@ -76,9 +64,9 @@ $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootim
 | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
 ----
 
-. Move the downloaded {op-system-base} live `kernel`, `initramfs`, and `rootfs` files to an HTTP or HTTPS server that is accessible from the z/VM guest you want to add.
+. Move the downloaded {op-system-base} live `kernel`, `initramfs`, and `rootfs` files to an HTTP or HTTPS server that is accessible from the {op-system} guest you want to add.
 
-. Create a parameter file for the z/VM guest. The following parameters are specific for the virtual machine:
+. Create a parameter file for the guest. The following parameters are specific for the virtual machine:
 ** Optional: To specify a static IP address, add an `ip=` parameter with the following entries, with each separated by a colon:
 ... The IP address for the machine.
 ... An empty string.
@@ -129,7 +117,7 @@ If additional LUNs are configured with NPIV, FCP requires `zfcp.allow_lun_scan=0
 +
 [IMPORTANT]
 ====
-Additional postinstallation steps are required to fully enable multipathing. For more information, see “Enabling multipathing with kernel arguments on {op-system}" in _Postinstallation machine configuration tasks_.
+Additional postinstallation steps are required to fully enable multipathing. For more information, see “Enabling multipathing with kernel arguments on {op-system}" in _Machine configuration_.
 ====
 // Add xref once it's allowed.
 +
@@ -152,8 +140,8 @@ rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000
 ----
 +
 Write all options in the parameter file as a single line and make sure that you have no newline characters.
-
-. Transfer the `initramfs`, `kernel`, parameter files, and {op-system} images to z/VM, for example, by using FTP. For details about how to transfer the files with FTP and boot from the virtual reader, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-installing-zvm-s390[Installing under Z/VM].
+ifdef::ibm-z[]
+. Transfer the `initramfs`, `kernel`, parameter files, and {op-system} images to z/VM, for example, by using FTP. For details about how to transfer the files with FTP and boot from the virtual reader, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/interactively_installing_rhel_over_the_network/index#installing-under-z-vm_booting-the-installation-media[Booting the installation on {ibm-z-name} to install {op-system-base} in z/VM].
 . Punch the files to the virtual reader of the z/VM guest virtual machine.
 +
 See link:https://www.ibm.com/docs/en/zvm/latest?topic=commands-punch[PUNCH] in {ibm-name} Documentation.
@@ -171,3 +159,16 @@ $ ipl c
 ----
 +
 See link:https://www.ibm.com/docs/en/zvm/latest?topic=commands-ipl[IPL] in {ibm-name} Documentation.
+endif::ibm-z[]
+ifdef::ibm-z-lpar[]
+. Transfer the initramfs, kernel, parameter files, and {op-system} images to the LPAR, for example with FTP. For details about how to transfer the files with FTP and boot, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/interactively_installing_rhel_over_the_network/index#installing-in-an-lpar_booting-the-installation-media[Booting the installation on {ibm-z-name} to install {op-system-base} in an LPAR].
+
+. Boot the machine
+endif::ibm-z-lpar[]
+
+ifeval::["{context}" == "creating-multi-arch-compute-nodes-ibm-z"]
+:!ibm-z:
+endif::[]
+ifeval::["{context}" == "creating-multi-arch-compute-nodes-ibm-z-lpar"]
+:!ibm-z-lpar:
+endif::[]
diff --git a/modules/machineconfig-garbage-collect-removing.adoc b/modules/machineconfig-garbage-collect-removing.adoc
index a481a0bda24a..a477d1e62d66 100644
--- a/modules/machineconfig-garbage-collect-removing.adoc
+++ b/modules/machineconfig-garbage-collect-removing.adoc
@@ -8,9 +8,9 @@
 
 You can remove unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `--confirm` command.  If any rendered machine config is not deleted, the command output indicates which was not deleted and lists the reason for skipping the deletion.
 
-.Procedure 
+.Procedure
 
-. Optional: List the rendered machine configs that you can remove automatically by running the following command. Any rendered machine config marked with `as it's currently in use` in the command output is not removed. 
+. Optional: List the rendered machine configs that you can remove automatically by running the following command. Any rendered machine config marked with the `as it's currently in use` message in the command output cannot be removed.
 +
 [source,terminal]
 ----
@@ -21,9 +21,9 @@ $ oc adm prune renderedmachineconfigs --pool-name=worker
 [source,terminal]
 ----
 Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
-DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
-DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
-DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use
+dry-run deleting rendered MachineConfig rendered-worker-f38bf61ced3c920cf5a29a200ed43243
+dry-run deleting MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
+Skip dry-run deleting rendered MachineConfig rendered-worker-708c652868f7597eaa1e2622edc366ef as it's currently in use
 ----
 +
 --
@@ -40,12 +40,19 @@ $ oc adm prune renderedmachineconfigs --pool-name=worker --count=2 --confirm
 ----
 +
 --
-where: 
+where:
 
 `--count`:: Optional: Specifies the maximum number of unused rendered machine configs you want to delete, starting with the oldest.
 
-`--confirm`:: Optional: Indicate that pruning should occur, instead of performing a dry-run.
+`--confirm`:: Indicates that pruning should occur, instead of performing a dry-run.
 
 `--pool-name`:: Optional: Specifies the machine config pool from which you want to delete the machine. If not specified, all the pools are evaluated.
-
 --
++
+.Example output
+[source,terminal]
+----
+deleting rendered MachineConfig rendered-worker-f38bf61ced3c920cf5a29a200ed43243
+deleting rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
+Skip deleting rendered MachineConfig rendered-worker-708c652868f7597eaa1e2622edc366ef as it's currently in use
+----
diff --git a/modules/machineconfig-garbage-collect-viewing.adoc b/modules/machineconfig-garbage-collect-viewing.adoc
index f7243c46512d..1bdf77d7a46e 100644
--- a/modules/machineconfig-garbage-collect-viewing.adoc
+++ b/modules/machineconfig-garbage-collect-viewing.adoc
@@ -6,7 +6,7 @@
 [id="machineconfig-garbage-collect-viewing_{context}"]
 = Viewing rendered machine configs
 
-You can view a list of rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `list` subcommand.  
+You can view a list of rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `list` subcommand.
 
 For example, the command in the following procedure would list all rendered machine configs for the `worker` machine config pool.
 
@@ -33,18 +33,20 @@ list:: Displays a list of rendered machine configs in your cluster.
 [source,terminal]
 ----
 worker
-status: rendered-worker-ae115e2b5e6ae05e0e6e5d62c7d0dd81
-spec: rendered-worker-ae115e2b5e6ae05e0e6e5d62c7d0dd81
+
+rendered-worker-f38bf61ced3c920cf5a29a200ed43243 -- 2025-01-21 13:45:01 +0000 UTC (Currently in use: false)
+rendered-worker-fc94397dc7c43808c7014683c208956e-- 2025-01-30 17:20:53 +0000 UTC (Currently in use: false)
+rendered-worker-708c652868f7597eaa1e2622edc366ef -- 2025-01-31 18:01:16 +0000 UTC (Currently in use: true)
 ----
 
-* List the rendered machine configs that you can remove automatically by running the following command. Any rendered machine config marked with `as it's currently in use` in the command output is not removed.
+* List the rendered machine configs that you can remove automatically by running the following command. Any rendered machine config marked with the `as it's currently in use` message in the command output cannot be removed.
 +
 [source,terminal]
 ----
 $ oc adm prune renderedmachineconfigs --pool-name=worker
 ----
 +
-The command runs in dry-run mode, and no machine configs are removed. 
+The command runs in dry-run mode, and no machine configs are removed.
 +
 --
 where:
@@ -56,7 +58,7 @@ where:
 [source,terminal]
 ----
 Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
-DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
-DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
-DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use
+dry-run deleting rendered MachineConfig rendered-worker-f38bf61ced3c920cf5a29a200ed43243
+dry-run deleting MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
+Skip dry-run deleting rendered MachineConfig rendered-worker-708c652868f7597eaa1e2622edc366ef as it's currently in use
 ----
diff --git a/modules/machineset-imds-options.adoc b/modules/machineset-imds-options.adoc
index 02ea4dca5bb8..248a6a446839 100644
--- a/modules/machineset-imds-options.adoc
+++ b/modules/machineset-imds-options.adoc
@@ -15,7 +15,7 @@ You can use machine sets to create machines that use a specific version of the A
 
 [NOTE]
 ====
-Using IMDSv2 is only supported on AWS clusters that were created with {product-title} version 4.7 or later.
+To use IMDSv2 on AWS clusters that were created with {product-title} version 4.6 or earlier, you must update your boot image. For more information, see "Updated boot images".
 ====
 
 ifndef::cpmso[]
diff --git a/modules/machineset-vsphere-multiple-nics.adoc b/modules/machineset-vsphere-multiple-nics.adoc
new file mode 100644
index 000000000000..ac8775f3ccb3
--- /dev/null
+++ b/modules/machineset-vsphere-multiple-nics.adoc
@@ -0,0 +1,150 @@
+
+// Module included in the following assemblies:
+//
+// * machine_management/creating_machinesets/creating-machineset-vsphere.adoc
+// * machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="machineset-vsphere-multiple-nics_{context}"]
+= Configuring multiple network interface controllers by using machine sets
+
+{product-title} clusters on {vmw-first} support connecting up to 10 network interface controllers (NICs) to a node. 
+By configuring multiple NICs, you can provide dedicated network links in the node virtual machines (VMs) for uses such as storage or databases.
+
+You can use machine sets to manage this configuration.
+
+* If you want to use multiple NICs in a {vmw-short} cluster that was not configured to do so during installation, you can use machine sets to implement this configuration.
+* If your cluster was set up during installation to use multiple NICs, machine sets that you create can use your existing failure domain configuration.
+* If your failure domain configuration changes, you can use machine sets to make updates that reflect those changes.
+
+tag::controlplane[]
+[NOTE]
+====
+This feature is not compatible with a control plane machine set that uses more than one failure domain.
+====
+end::controlplane[]
+
+:FeatureName: Configuring multiple NICs
+include::snippets/technology-preview.adoc[]
+
+.Prerequisites
+
+* You have administrator access to {oc-first} for an {product-title} cluster on {vmw-short}.
+
+.Procedure
+
+. For a cluster that already uses multiple NICs, obtain the following values from the `Infrastructure` resource by running the following command:
++
+[source,terminal]
+----
+$ oc get infrastructure cluster -o=jsonpath={.spec.platformSpec.vsphere.failureDomains}
+----
++
+.Required network interface controller values
+|===
+|`Infrastructure` resource value | Placeholder value for sample machine set | Description
+
+|`failureDomain.topology.networks[0]`
+|`<vm_network_name_1>`
+|The name of the first NIC to use.
+
+|`failureDomain.topology.networks[1]`
+|`<vm_network_name_2>`
+|The name of the second NIC to use.
+
+|`failureDomain.topology.networks[<n-1>]`
+|`<vm_network_name_n>`
+|The name of the __n__th NIC to use.
+Collect the name of each NIC in the `Infrastructure` resource.
+
+|`failureDomain.topology.template`
+|`<vm_template_name>`
+|The {vmw-short} VM template to use.
+
+|`failureDomain.topology.datacenter`
+|`<vcenter_data_center_name>`
+|The vCenter data center to deploy the machine set on.
+
+|`failureDomain.topology.datastore`
+|`<vcenter_datastore_name>`
+|The vCenter datastore to deploy the machine set on.
+
+|`failureDomain.topology.folder`
+|`<vcenter_vm_folder_path>`
+|The path to the {vmw-short} VM folder in vCenter, such as `/dc1/vm/user-inst-5ddjd`.
+
+|`failureDomain.topology.computeCluster` + `/Resources`
+|`<vsphere_resource_pool>`
+|The {vmw-short} resource pool for your VMs.
+
+|`failureDomain.server`
+|`<vcenter_server_ip>`
+|The vCenter server IP or fully qualified domain name (FQDN).
+|===
+
+. In a text editor, open the YAML file for an existing machine set or create a new one.
+
+. Use a machine set configuration formatted like the following example.
++
+--
+* For a cluster that currently uses multiple NICs, use the values from the `Infrastructure` resource to populate the values in the machine set custom resource.
+* For a cluster that is not using multiple NICs, populate the values you want to use in the machine set custom resource.
+--
++
+.Sample machine set
+[source,yaml]
+----
+tag::compute[]
+apiVersion: machine.openshift.io/v1beta1
+kind: MachineSet
+# ...
+spec:
+  template:
+    spec:
+      providerSpec:
+        value:
+          network:
+            devices: # <1>
+            - networkName: "<vm_network_name_1>"
+            - networkName: "<vm_network_name_2>"
+          template: <vm_template_name> # <2>
+          workspace:
+            datacenter: <vcenter_data_center_name> # <3>
+            datastore: <vcenter_datastore_name> # <4>
+            folder: <vcenter_vm_folder_path> # <5>
+            resourcepool: <vsphere_resource_pool> # <6>
+            server: <vcenter_server_ip> # <7>
+# ...
+end::compute[]
+tag::controlplane[]
+apiVersion: machine.openshift.io/v1
+kind: ControlPlaneMachineSet
+# ...
+spec:
+  template:
+    machines_v1beta1_machine_openshift_io:
+      spec:
+        providerSpec:
+          value:
+            network:
+              devices: # <1>
+              - networkName: "<vm_network_name_1>"
+              - networkName: "<vm_network_name_2>"
+            template: <vm_template_name> # <2>
+            workspace:
+              datacenter: <vcenter_data_center_name> # <3>
+              datastore: <vcenter_datastore_name> # <4>
+              folder: <vcenter_vm_folder_path> # <5>
+              resourcepool: <vsphere_resource_pool> # <6>
+              server: <vcenter_server_ip> # <7>
+
+# ...
+end::controlplane[]
+----
+<1> Specify a list of up to 10 NICs to use.
+<2> Specify the {vmw-short} VM template to use, such as `user-5ddjd-rhcos`.
+<3> Specify the vCenter data center to deploy the machine set on.
+<4> Specify the vCenter datastore to deploy the machine set on.
+<5> Specify the path to the {vmw-short} VM folder in vCenter, such as `/dc1/vm/user-inst-5ddjd`.
+<6> Specify the {vmw-short} resource pool for your VMs.
+<7> Specify the vCenter server IP or fully qualified domain name (FQDN).
\ No newline at end of file
diff --git a/modules/machineset-yaml-aws.adoc b/modules/machineset-yaml-aws.adoc
index de42c81d8c17..55cb617858aa 100644
--- a/modules/machineset-yaml-aws.adoc
+++ b/modules/machineset-yaml-aws.adoc
@@ -121,8 +121,8 @@ endif::edge[]
           instanceType: m6i.large
           kind: AWSMachineProviderConfig
           placement:
-            availabilityZone: <zone> <6>
-            region: <region> <7>
+            availabilityZone: <zone> <5>
+            region: <region> <6>
           securityGroups:
             - filters:
                 - name: tag:Name
@@ -137,16 +137,16 @@ ifndef::edge[]
             filters:
               - name: tag:Name
                 values:
-                  - <infrastructure_id>-private-<zone> <8>
+                  - <infrastructure_id>-private-<zone> <7>
 endif::edge[]
 ifdef::edge[]
-              id: <value_of_PublicSubnetIds> <8>
+              id: <value_of_PublicSubnetIds> <7>
           publicIp: true
 endif::edge[]
           tags:
             - name: kubernetes.io/cluster/<infrastructure_id> 
               value: owned
-            - name: <custom_tag_name> <5>
+            - name: <custom_tag_name> <8>
               value: <custom_tag_value> 
           userDataSecret:
             name: worker-user-data
@@ -188,26 +188,25 @@ $ oc -n openshift-machine-api \
     -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
     get machineset/<infrastructure_id>-<role>-<zone>
 ----
-<5> Optional: Specify custom tag data for your cluster. For example, you might add an admin contact email address by specifying a `name:value` pair of `Email:\admin-email@example.com`.
-+
-[NOTE]
-====
-Custom tags can also be specified during installation in the `install-config.yml` file. If the `install-config.yml` file and the machine set include a tag with the same `name` data, the value for the tag from the machine set takes priority over the value for the tag in the `install-config.yml` file.
-====
-
 ifndef::edge[]
-<6> Specify the zone, for example, `us-east-1a`.
+<5> Specify the zone name, for example, `us-east-1a`.
 endif::edge[]
 ifdef::edge[]
-<6> Specify the zone name, for example, `us-east-1-nyc-1a`.
-endif::edge[]
-<7> Specify the region, for example, `us-east-1`.
+<5> Specify the zone name, for example, `us-east-1-nyc-1a`.
+endif::edge[] 
+<6> Specify the region, for example, `us-east-1`.
 ifndef::edge[]
-<8> Specify the infrastructure ID and zone.
+<7> Specify the infrastructure ID and zone.
 endif::edge[]
 ifdef::edge[]
-<8> The ID of the public subnet that you created in AWS {zone-type}. You created this public subnet ID when you finished the procedure for "Creating a subnet in an AWS zone".
+<7> The ID of the public subnet that you created in AWS {zone-type}. You created this public subnet ID when you finished the procedure for "Creating a subnet in an AWS zone".
 endif::edge[]
+<8> Optional: Specify custom tag data for your cluster. For example, you might add an admin contact email address by specifying a `name:value` pair of `Email:\admin-email@example.com`.
++
+[NOTE]
+====
+Custom tags can also be specified during installation in the `install-config.yml` file. If the `install-config.yml` file and the machine set include a tag with the same `name` data, the value for the tag from the machine set takes priority over the value for the tag in the `install-config.yml` file.
+====
 ifdef::infra,edge[]
 <9> Specify a taint to prevent user workloads from being scheduled on
 ifdef::infra[`infra`]
diff --git a/modules/machineset-yaml-azure.adoc b/modules/machineset-yaml-azure.adoc
index 19c259787a82..50e885a0f9ce 100644
--- a/modules/machineset-yaml-azure.adoc
+++ b/modules/machineset-yaml-azure.adoc
@@ -151,11 +151,19 @@ ifdef::infra[]
 <2> Specify the `infra` node label.
 <3> Specify the infrastructure ID, `infra` node label, and region.
 endif::infra[]
-<4> Specify the image details for your compute machine set. If you want to use an Azure Marketplace image, see "Selecting an Azure Marketplace image".
+<4> Specify the image details for your compute machine set. If you want to use an Azure Marketplace image, see "Using the Azure Marketplace offering".
 <5> Specify an image that is compatible with your instance type. The Hyper-V generation V2 images created by the installation program have a `-gen2` suffix, while V1 images have the same name without the suffix.
 <6> Specify the region to place machines on.
 <7> Optional: Specify custom tags in your machine set. Provide the tag name in `<custom_tag_name>` field and the corresponding tag value in `<custom_tag_value>` field.
-<8> Specify the zone within your region to place machines on. Be sure that your region supports the zone that you specify.
+<8> Specify the zone within your region to place machines on. 
+Ensure that your region supports the zone that you specify.
++
+[IMPORTANT]
+====
+If your region supports availability zones, you must specify the zone.
+Specifying the zone avoids volume node affinity failure when a pod requires a persistent volume attachment.
+To do this, you can create a compute machine set for each zone in the same region.
+====
 ifdef::infra[]
 <9> Specify a taint to prevent user workloads from being scheduled on infra nodes.
 +
diff --git a/modules/machineset-yaml-baremetal.adoc b/modules/machineset-yaml-baremetal.adoc
index b86f342302f4..716a3c612daf 100644
--- a/modules/machineset-yaml-baremetal.adoc
+++ b/modules/machineset-yaml-baremetal.adoc
@@ -85,7 +85,7 @@ endif::infra[]
           metadata:
             creationTimestamp: null
           userData:
-            name: worker-user-data
+            name: worker-user-data-managed
 ----
 <1> Specify the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. If you have the OpenShift CLI (`oc`) installed, you can obtain the infrastructure ID by running the following command:
 +
diff --git a/modules/machineset-yaml-nutanix.adoc b/modules/machineset-yaml-nutanix.adoc
index 0ec2248ad5a9..aa111b8f3a29 100644
--- a/modules/machineset-yaml-nutanix.adoc
+++ b/modules/machineset-yaml-nutanix.adoc
@@ -108,16 +108,16 @@ endif::infra[]
           project: <10>
             type: name
             name: <project_name>
-          subnets:
+          subnets: <11>
           - type: uuid
             uuid: <subnet_uuid>
-          systemDiskSize: 120Gi <11>
+          systemDiskSize: 120Gi <12>
           userDataSecret:
-            name: <user_data_secret> <12>
-          vcpuSockets: 4 <13>
-          vcpusPerSocket: 1 <14>
+            name: <user_data_secret> <13>
+          vcpuSockets: 4 <14>
+          vcpusPerSocket: 1 <15>
 ifdef::infra[]
-      taints: <15>
+      taints: <16>
       - key: node-role.kubernetes.io/infra
         effect: NoSchedule
 endif::infra[]
@@ -143,12 +143,16 @@ You must use the `Legacy` boot type in {product-title} {product-version}.
 <8> Specify the image to use. Use an image from an existing default compute machine set for the cluster.
 <9> Specify the amount of memory for the cluster in Gi.
 <10> Specify the Nutanix project that you use for your cluster. In this example, the project type is `name`, so there is a `name` stanza.
-<11> Specify the size of the system disk in Gi.
-<12> Specify the name of the secret in the user data YAML file that is in the `openshift-machine-api` namespace. Use the value that installation program populates in the default compute machine set.
-<13> Specify the number of vCPU sockets.
-<14> Specify the number of vCPUs per socket.
+<11> Specify one or more UUID for the Prism Element subnet object. 
+The CIDR IP address prefix for one of the specified subnets must contain the virtual IP addresses that the {product-title} cluster uses. 
+A maximum of 32 subnets for each Prism Element failure domain in the cluster is supported.
+All subnet UUID values must be unique.
+<12> Specify the size of the system disk in Gi.
+<13> Specify the name of the secret in the user data YAML file that is in the `openshift-machine-api` namespace. Use the value that installation program populates in the default compute machine set.
+<14> Specify the number of vCPU sockets.
+<15> Specify the number of vCPUs per socket.
 ifdef::infra[]
-<15> Specify a taint to prevent user workloads from being scheduled on infra nodes.
+<16> Specify a taint to prevent user workloads from being scheduled on infra nodes.
 +
 [NOTE]
 ====
diff --git a/modules/machineset-yaml-osp-sr-iov-port-security.adoc b/modules/machineset-yaml-osp-sr-iov-port-security.adoc
index 149244158a4d..a094f24c90e6 100644
--- a/modules/machineset-yaml-osp-sr-iov-port-security.adoc
+++ b/modules/machineset-yaml-osp-sr-iov-port-security.adoc
@@ -82,10 +82,12 @@ spec:
           trunk: false
           userDataSecret:
             name: worker-user-data
+          configDrive: true <4>
 ----
 <1> Specify allowed address pairs for the API and ingress ports.
 <2> Specify the machines network and subnet.
 <3> Specify the compute machines security group.
+<4> The value of the `configDrive` parameter must be `true`.
 
 [NOTE]
 ====
@@ -94,4 +96,4 @@ Trunking is enabled for ports that are created by entries in the networks and su
 You can enable trunking for each port.
 
 Optionally, you can add tags to ports as part of their `tags` lists.
-====
\ No newline at end of file
+====
diff --git a/modules/machineset-yaml-osp-sr-iov.adoc b/modules/machineset-yaml-osp-sr-iov.adoc
index 6715fa59f6c6..9dad5442e740 100644
--- a/modules/machineset-yaml-osp-sr-iov.adoc
+++ b/modules/machineset-yaml-osp-sr-iov.adoc
@@ -91,6 +91,7 @@ spec:
           userDataSecret:
             name: <node_role>-user-data
           availabilityZone: <optional_openstack_availability_zone>
+          configDrive: true <5> 
 ----
 <1> Enter a network UUID for each port.
 <2> Enter a subnet UUID for each port.
@@ -98,6 +99,7 @@ spec:
 <4> The value of the `portSecurity` parameter must be `false` for each port.
 +
 You cannot set security groups and allowed address pairs for ports when port security is disabled. Setting security groups on the instance applies the groups to all ports that are attached to it.
+<5> The value of the `configDrive` parameter must be `true`.
 
 [IMPORTANT]
 ====
diff --git a/modules/managed-resources.adoc b/modules/managed-resources.adoc
new file mode 100644
index 000000000000..f89c96f48564
--- /dev/null
+++ b/modules/managed-resources.adoc
@@ -0,0 +1,70 @@
+:_mod-docs-content-type: CONCEPT
+//[id="sd-managed-resources"]
+[id="sd-redhat-managed-resources_{context}"]
+= Red{nbsp}Hat managed resources
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: sd-managed-resources
+
+toc::[]
+
+[id="sd-managed-resources-overview_{context}"]
+== Overview
+
+The following covers all {product-title} resources that are managed or protected by the Service Reliability Engineering Platform (SRE-P) Team. Customers should not try to change these resources because doing so can lead to cluster instability.
+
+[id="sd-managed-resources-all_{context}"]
+== Managed resources
+
+The following list displays the {product-title} resources managed by OpenShift Hive, the centralized fleet configuration management system. These resources are in addition to the OpenShift Container Platform resources created during installation. OpenShift Hive continually attempts to maintain consistency across all {product-title} clusters. Changes to {product-title} resources should be made through {cluster-manager} so that {cluster-manager} and Hive are synchronized. Contact ocm-feedback@redhat.com if {cluster-manager} does not support modifying the resources in question.
+
+.List of Red{nbsp}Hat managed resources
+[%collapsible]
+====
+[source,yaml]
+----
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/managed/all-osd-resources.yaml[]
+----
+====
+
+[id="sd-core-namespaces_{context}"]
+== {product-title} core namespaces
+
+{product-title} core namespaces are installed by default during cluster installation.
+
+.List of core namespaces
+[%collapsible]
+====
+[source,yaml]
+----
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/master/deploy/osd-managed-resources/ocp-namespaces.ConfigMap.yaml[]
+----
+====
+
+[id="sd-add-on-managed-namespaces_{context}"]
+== {product-title} add-on namespaces
+
+{product-title} add-ons are services available for installation after cluster installation. These additional services include {openshift-dev-spaces-productname}, Red{nbsp}Hat OpenShift API Management, and Cluster Logging Operator. Any changes to resources within the following namespaces can be overridden by the add-on during upgrades, which can lead to unsupported configurations for the add-on functionality.
+
+.List of add-on managed namespaces
+[%collapsible]
+====
+[source,yaml]
+----
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/addons-namespaces/main.yaml[]
+----
+====
+
+[id="sd-validating-webhooks_{context}"]
+== {product-title} validating webhooks
+
+{product-title} validating webhooks are a set of dynamic admission controls maintained by the OpenShift SRE team. These HTTP callbacks, also known as webhooks, are called for various types of requests to ensure cluster stability. The following list describes the various webhooks with rules containing the registered operations and resources that are controlled. Any attempt to circumvent these validating webhooks could affect the stability and supportability of the cluster.
+
+.List of validating webhooks
+[%collapsible]
+====
+[source,json]
+----
+include::https://raw.githubusercontent.com/openshift/managed-cluster-validating-webhooks/master/docs/webhooks.json[]
+----
+====
+
diff --git a/modules/manually-maintained-credentials-upgrade-extract.adoc b/modules/manually-maintained-credentials-upgrade-extract.adoc
index 82b88b9194f9..2f5463c8cefd 100644
--- a/modules/manually-maintained-credentials-upgrade-extract.adoc
+++ b/modules/manually-maintained-credentials-upgrade-extract.adoc
@@ -32,7 +32,7 @@ The output of this command includes pull specs for the available updates similar
 Recommended updates:
 
 VERSION IMAGE
-4.17.0  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
+4.18.0  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
 ...
 ----
 
diff --git a/modules/manually-removing-cloud-creds.adoc b/modules/manually-removing-cloud-creds.adoc
index 5d4b5c6e1ea2..3e0c2c359058 100644
--- a/modules/manually-removing-cloud-creds.adoc
+++ b/modules/manually-removing-cloud-creds.adoc
@@ -14,7 +14,7 @@ The CCO only requires the administrator-level credential during changes that req
 
 [NOTE]
 ====
-Before performing a minor version cluster update (for example, updating from {product-title} 4.16 to 4.17), you must reinstate the credential secret with the administrator-level credential. 
+Before performing a minor version cluster update (for example, updating from {product-title} {ocp-nminus1} to {product-version}), you must reinstate the credential secret with the administrator-level credential. 
 If the credential is not present, the update might be blocked.
 ====
 
diff --git a/modules/manually-restoring-cluster-etcd-backup.adoc b/modules/manually-restoring-cluster-etcd-backup.adoc
new file mode 100644
index 000000000000..22ae14d135a3
--- /dev/null
+++ b/modules/manually-restoring-cluster-etcd-backup.adoc
@@ -0,0 +1,389 @@
+// Module included in the following assemblies:
+//
+// * disaster_recovery/scenario-2-manually-restoring-cluster-etcd-backup.adoc
+// * post_installation_configuration/cluster-tasks.adoc
+
+
+:_mod-docs-content-type: PROCEDURE
+[id="manually-restoring-cluster-etcd-backup_{context}"]
+= Restoring a cluster manually from an etcd backup
+
+The restore procedure described in the section "Restoring to a previous cluster state": 
+
+* Requires the complete recreation of 2 control plane nodes, which might be a complex procedure for clusters installed with the UPI installation method, since an UPI installation does not create any `Machine` or `ControlPlaneMachineset` for the control plane nodes.
+
+* Uses the script /usr/local/bin/cluster-restore.sh, which starts a new single-member etcd cluster and then scales it to three members. 
+
+In contrast, this procedure:
+
+* Does not require recreating any control plane nodes.
+* Directly starts a three-member etcd cluster.
+
+If the cluster uses a `MachineSet` for the control plane, it is suggested to use the "Restoring to a previous cluster state" for a simpler etcd recovery procedure.
+
+When you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.7.2 cluster must use an etcd backup that was taken from 4.7.2.
+
+.Prerequisites
+
+* Access to the cluster as a user with the `cluster-admin` role; for example, the `kubeadmin` user.
+* SSH access to _all_ control plane hosts, with a host user allowed to become `root`; for example, the default `core` host user.
+* A backup directory containing both a previous etcd snapshot and the resources for the static pods from the same backup. The file names in the directory must be in the following formats: `snapshot_<datetimestamp>.db` and `static_kuberesources_<datetimestamp>.tar.gz`.
+
+.Procedure
+
+. Use SSH to connect to each of the control plane nodes.
++
+The Kubernetes API server becomes inaccessible after the restore process starts, so you cannot access the control plane nodes. For this reason, it is recommended to use a SSH connection for each control plane host you are accessing in a separate terminal.
++
+[IMPORTANT]
+====
+If you do not complete this step, you will not be able to access the control plane hosts to complete the restore procedure, and you will be unable to recover your cluster from this state.
+====
+
+. Copy the etcd backup directory to each control plane host.
++
+This procedure assumes that you copied the `backup` directory containing the etcd snapshot and the resources for the static pods to the `/home/core/assets` directory of each control plane host. You might need to create such `assets` folder if it does not exist yet.
+
+. Stop the static pods on all the control plane nodes; one host at a time.
+
+.. Move the existing Kubernetes API Server static pod manifest out of the kubelet manifest directory.
++
+[source,terminal]
+----
+$ mkdir -p /root/manifests-backup
+$ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
+----
+
+.. Verify that the Kubernetes API Server containers have stopped with the command:
++
+[source,terminal]
+----
+$ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"
+----
++
+The output of this command should be empty. If it is not empty, wait a few minutes and check again.
+
+.. If the Kubernetes API Server containers are still running, terminate them manually with the following command:
++
+[source,terminal]
+----
+$ crictl stop <container_id>
+----
+
+.. Repeat the same steps for `kube-controller-manager-pod.yaml`, `kube-scheduler-pod.yaml` and **finally** `etcd-pod.yaml`.
+
+... Stop the `kube-controller-manager` pod with the following command:
++
+[source,terminal]
+----
+$ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
+----
+
+... Check if the containers are stopped using the following command:
++
+[source,terminal]
+----
+$ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
+----
+
+... Stop the `kube-scheduler` pod using the following command:
++
+[source,terminal]
+----
+$ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
+----
+
+... Check if the containers are stopped using the following command:
++
+[source,terminal]
+----
+$ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
+----
+
+... Stop the `etcd` pod using the following command:
++
+[source,terminal]
+----
+$ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
+----
+
+... Check if the containers are stopped using the following command:
++
+[source,terminal]
+----
+$ crictl ps | grep etcd | grep -E -v "operator|guard"
+----
+
+. On each control plane host, save the current `etcd` data, by moving it into the `backup` folder:
++
+[source,terminal]
+----
+$ mkdir /home/core/assets/old-member-data
+$ mv /var/lib/etcd/member /home/core/assets/old-member-data
+----
++
+This data will be useful in case the `etcd` backup restore does not work and the `etcd` cluster must be restored to the current state.
+
+. Find the correct etcd parameters for each control plane host.
+
+.. The value for `<ETCD_NAME>` is unique for the each control plane host, and it is equal to the value of the `ETCD_NAME` variable in the manifest `/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml` file in the specific control plane host. It can be found with the command:
++
+[source,terminal]
+----
+RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml"
+cat $RESTORE_ETCD_POD_YAML | \
+  grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \
+  grep -Po '(?<=value: ").+(?=")'
+----
+
+.. The value for `<UUID>` can be generated in a control plane host with the command:
++
+[source,terminal]
+----
+$ uuidgen
+----
++
+[NOTE]
+==== 
+The value for `<UUID>` must be generated only once. After generating `UUID` on one control plane host, do not generate it again on the others. The same `UUID` will be used in the next steps on all control plane hosts.
+====
+
+.. The value for `ETCD_NODE_PEER_URL` should be set like the following example:
++
+[source,yaml]
+----
+https://<IP_CURRENT_HOST>:2380
+----
++
+The correct IP can be found from the `<ETCD_NAME>` of the specific control plane host, with the command:
++
+[source,terminal]
+----
+$ echo <ETCD_NAME> | \
+  sed -E 's/[.-]/_/g' | \
+  xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
+  grep "IP" | grep -Po '(?<=").+(?=")'
+----
+
+.. The value for `<ETCD_INITIAL_CLUSTER>` should be set like the following, where `<ETCD_NAME_n>` is the `<ETCD_NAME>` of each control plane host. 
++
+[NOTE]
+====
+The port used must be 2380 and not 2379. The port 2379 is used for etcd database management and is configured directly in etcd start command in container.
+====
++
+.Example output
+[source,terminal]
+----
+<ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2> <1>
+----
+<1> Specifies the `ETCD_NODE_PEER_URL` values from each control plane host.
++
+The `<ETCD_INITIAL_CLUSTER>` value remains same across all control plane hosts. The same value is required in the next steps on every control plane host.
+
+. Regenerate the etcd database from the backup. 
++
+Such operation must be executed on each control plane host.
+
+.. Copy the `etcd` backup to `/var/lib/etcd` directory with the command:
++
+[source,terminal]
+----
+$ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
+----
+
+.. Identify the correct `etcdctl` image before proceeding. Use the following command to retrieve the image from the backup of the pod manifest:
++
+[source,terminal]
+----
+$ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
+----
++
+[source,terminal]
+----
+$ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
+----
+
+.. Check that the version of the `etcdctl` tool is the version of the `etcd` server where the backup was created:
++
+[source,terminal]
+----
+$ etcdctl version
+----
+
+.. Run the following command to regenerate the `etcd` database, using the correct values for the current host: 
++
+[source,terminal]
+----
+$ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \
+  --name "<ETCD_NAME>" \
+  --initial-cluster="<ETCD_INITIAL_CLUSTER>" \
+  --initial-cluster-token "openshift-etcd-<UUID>" \
+  --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \
+  --data-dir="/var/lib/etcd/restore-<UUID>" \
+  --skip-hash-check=true
+----
++
+[NOTE]
+====
+The quotes are mandatory when regenerating the `etcd` database.
+====
+
+. Record the values printed in the `added member` logs; for example:
++
+.Example output
+----
+2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false}
+2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false}
+2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}
+----
+
+.. Exit from the container.
+
+.. Repeat these steps on the other control plane hosts, checking that the values printed in the `added member` logs are the same for all control plane hosts.
+
+. Move the regenerated `etcd` database to the default location. 
++
+Such operation must be executed on each control plane host.
+
+.. Move the regenerated database (the `member` folder created by the previous `etcdctl snapshot restore` command) to the default etcd location `/var/lib/etcd`:
++
+[source,terminal]
+----
+$ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
+----
+
+.. Restore the SELinux context for `/var/lib/etcd/member` folder on `/var/lib/etcd` directory:
++
+[source,terminal]
+----
+$ restorecon -vR /var/lib/etcd/
+----
+
+.. Remove the leftover files and directories:
++
+[source,terminal]
+----
+$ rm -rf /var/lib/etcd/restore-<UUID>
+----
++
+[source,terminal]
+----
+$ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
+----
++
+[IMPORTANT]
+====
+When you are finished the `/var/lib/etcd` directory must contain only the folder `member`.
+====
+
+.. Repeat these steps on the other control plane hosts.
+
+. Restart the etcd cluster.
+
+.. The following steps must be executed on all control plane hosts, but **one host at a time**.
+
+.. Move the `etcd` static pod manifest back to the kubelet manifest directory, in order to make kubelet start the related containers :
++
+[source,terminal]
+----
+$ mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests
+----
+
+.. Verify that all the `etcd` containers have started:
++
+[source,terminal]
+----
+$ crictl ps | grep etcd | grep -v operator
+----
++
+.Example output
+[source,terminal]
+----
+38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
+e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
+08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
+2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl    
+----
++
+If the output of this command is empty, wait a few minutes and check again.
+
+. Check the status of the `etcd` cluster.
+
+.. On any of the control plane hosts, check the status of the `etcd` cluster with the following command:
++
+[source,terminal]
+----
+$ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table
+----
++
+.Example output
+[source,terminal]
+----
++--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
+|         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
++--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
+| https://10.0.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
+|  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
+| https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
++--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
+----
+
+. Restart the other static pods.
++
+The following steps must be executed on all control plane hosts, but one host at a time.
+
+.. Move the Kubernetes API Server static pod manifest back to the kubelet manifest directory to make kubelet start the related containers with the command:
++
+[source,terminal]
+----
+$ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
+----
+
+.. Verify that all the Kubernetes API Server containers have started:
++
+[source,terminal]
+----
+$ crictl ps | grep kube-apiserver | grep -v operator
+----
++
+[NOTE]
+====
+if the output of the following command is empty, wait a few minutes and check again.
+====
+
+.. Repeat the same steps for `kube-controller-manager-pod.yaml` and `kube-scheduler-pod.yaml` files.
+
+... Restart the kubelets in all nodes using the following command:
++
+[source,terminal]
+----
+$ systemctl restart kubelet
+----
+
+... Start the remaining control plane pods using the following command:
++
+[source,terminal]
+----
+$ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
+----
+
+... Check if the `kube-apiserver`, `kube-scheduler` and `kube-controller-manager` pods start correctly:
++
+[source,terminal]
+----
+$ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
+----
+
+... Wipe the OVN databases using the following commands:
++
+[source,terminal]
+----
+for NODE in  $(oc get node -o name | sed 's:node/::g')
+do 
+  oc debug node/${NODE} -- chroot /host /bin/bash -c  'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'
+  oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait
+  oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s
+done
+----
+
diff --git a/modules/master-node-sizing.adoc b/modules/master-node-sizing.adoc
index f079a31a4cc2..1e0fa40b2471 100644
--- a/modules/master-node-sizing.adoc
+++ b/modules/master-node-sizing.adoc
@@ -49,10 +49,10 @@ On a large and dense cluster with three control plane nodes, the CPU and memory
 
 [IMPORTANT]
 ====
-The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the `running` phase.
+The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the `Running` phase.
 ====
 
-Operator Lifecycle Manager (OLM ) runs on the control plane nodes and its memory footprint depends on the number of namespaces and user installed operators that OLM needs to manage on the cluster. Control plane nodes need to be sized accordingly to avoid OOM kills. Following data points are based on the results from cluster maximums testing.
+Operator Lifecycle Manager (OLM) runs on the control plane nodes and its memory footprint depends on the number of namespaces and user installed operators that OLM needs to manage on the cluster. Control plane nodes need to be sized accordingly to avoid OOM kills. Following data points are based on the results from cluster maximums testing.
 
 [options="header",cols="3*"]
 |===
diff --git a/modules/mco-update-boot-images-configuring.adoc b/modules/mco-update-boot-images-configuring.adoc
index f091fa729b69..469aa41ff341 100644
--- a/modules/mco-update-boot-images-configuring.adoc
+++ b/modules/mco-update-boot-images-configuring.adoc
@@ -9,10 +9,7 @@
 
 By default, {product-title} does not manage the boot image. You can configure your cluster to update the boot image whenever you update your cluster by modifying the `MachineConfiguration` object.
 
-Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and as a Technology Preview feature for Amazon Web Services (AWS) clusters. It is not supported for clusters managed by the {cluster-capi-operator}.
-
-:FeatureName: The updating boot image feature for AWS
-include::snippets/technology-preview.adoc[]
+Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) and Amazon Web Services (AWS) clusters. It is not supported for clusters managed by the {cluster-capi-operator}.
 
 .Procedure
 
diff --git a/modules/microshift-about-remote-health-monitoring.adoc b/modules/microshift-about-remote-health-monitoring.adoc
new file mode 100644
index 000000000000..6b0155d6c9f3
--- /dev/null
+++ b/modules/microshift-about-remote-health-monitoring.adoc
@@ -0,0 +1,28 @@
+// Module included in the following assemblies:
+//
+// microshift_support/microshift-remote-cluster-monitoring.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-about-remote-health-monitoring_{context}"]
+= About remote health monitoring with {microshift-short}
+
+Remote health monitoring is conducted in {microshift-short} by the collection of telemetry and configuration data about your cluster that is reported to Red{nbsp}Hat with the Telemeter API. A cluster that reports Telemetry to Red{nbsp}Hat is considered a _connected cluster_.
+
+*Telemetry* is the term that Red{nbsp}Hat uses to describe the information being sent to Red{nbsp}Hat by the {microshift-short} Telemeter API. Lightweight attributes are sent from a connected cluster to Red{nbsp}Hat to monitor the health of clusters.
+
+.Telemetry benefits
+
+Telemetry provides the following benefits:
+
+* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red{nbsp}Hat from a broader perspective. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Jira issue].
+
+* *Targeted prioritization of new features and functionality*. The data collected provides information about system capabilities and usage characteristics. With this information, Red{nbsp}Hat can focus on developing the new features and functionality that have the greatest impact for our customers.
+
+Telemetry sends a carefully chosen subset of the cluster monitoring metrics to Red{nbsp}Hat. The Telemeter API fetches the metrics values every hour and uploads the data to Red{nbsp}Hat. This stream of data is used by Red{nbsp}Hat to monitor a cluster over time.
+
+This debugging information is available to Red{nbsp}Hat Support and Engineering teams with the same restrictions as accessing data reported through support cases. All _connected cluster_ information is used by Red{nbsp}Hat to help make {microshift-short} better.
+
+[NOTE]
+====
+{microshift-short} does not support Prometheus. To view the Telemetry gathered from your cluster, you must contact Red{nbsp}Hat Support.
+====
\ No newline at end of file
diff --git a/modules/microshift-accessing-cluster-locally.adoc b/modules/microshift-accessing-cluster-locally.adoc
index 46f683f394a5..8a86286ee012 100644
--- a/modules/microshift-accessing-cluster-locally.adoc
+++ b/modules/microshift-accessing-cluster-locally.adoc
@@ -12,7 +12,7 @@ Use the following procedure to access the {microshift-short} cluster locally by
 
 .Prerequisites
 
-* You have installed the `oc` binary.
+* You installed {oc-first}.
 
 .Procedure
 
@@ -41,7 +41,6 @@ $ chmod go-r ~/.kube/config
 
 * Verify that {microshift-short} is running by entering the following command:
 +
-[source,terminal]
-----
-$ oc get all -A
-----
+--
+include::snippets/microshift-healthy-pods-snip.adoc[leveloffset=+2]
+--
diff --git a/modules/microshift-accessing-cluster-open-firewall.adoc b/modules/microshift-accessing-cluster-open-firewall.adoc
index 24f20068e8d5..a716e5b420d1 100644
--- a/modules/microshift-accessing-cluster-open-firewall.adoc
+++ b/modules/microshift-accessing-cluster-open-firewall.adoc
@@ -14,7 +14,7 @@ For this procedure, `user@microshift` is the user on the {microshift-short} host
 
 .Prerequisites
 
-* You have installed the `oc` binary.
+* You installed {oc-first}.
 
 * Your account has cluster administration privileges.
 
@@ -31,7 +31,6 @@ For this procedure, `user@microshift` is the user on the {microshift-short} host
 
 * As `user@microshift`, verify that {microshift-short} is running by entering the following command:
 +
-[source,terminal]
-----
-[user@microshift]$ oc get all -A
-----
+--
+include::snippets/microshift-healthy-pods-snip.adoc[leveloffset=+2]
+--
\ No newline at end of file
diff --git a/modules/microshift-accessing-cluster-remotely.adoc b/modules/microshift-accessing-cluster-remotely.adoc
index 3848f2dda6eb..d0bbcdb3d79f 100644
--- a/modules/microshift-accessing-cluster-remotely.adoc
+++ b/modules/microshift-accessing-cluster-remotely.adoc
@@ -14,7 +14,7 @@ The `user@workstation` login is used to access the host machine remotely. The `<
 
 .Prerequisites
 
-* You have installed the `oc` binary.
+* You installed {oc-first}.
 
 * The `user@microshift` has opened the firewall from the local host.
 
@@ -22,29 +22,33 @@ The `user@workstation` login is used to access the host machine remotely. The `<
 
 . As `user@workstation`, create a `~/.kube/` folder if your {op-system-base-full} machine does not have one by running the following command:
 +
-[source,terminal,subs="attributes+"]
+[source,terminal]
 ----
 [user@workstation]$ mkdir -p ~/.kube/
 ----
 
 . As `user@workstation`, set a variable for the hostname of your {microshift-short} host by running the following command:
 +
-[source,terminal,subs="attributes+"]
+[source,terminal,subs="+quotes"]
 ----
-[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of {microshift-short} machine>
+[user@workstation]$ MICROSHIFT_MACHINE=_<microshift_hostname>_ # <1>
 ----
+<1> Replace the value, _<{microshift-short}_hostname>_, with the either the name or the IP address of the host running {microshift}.
 
 . As `user@workstation`, copy the generated `kubeconfig` file that contains the host name or IP address you want to connect with from the {op-system-base} machine running {microshift-short} to your local machine by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
+[user@workstation]$ ssh _<user>_@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config # <1>
 ----
+<1> Replace _<user>_ with your SSH login credentials.
 +
+--
 [NOTE]
 ====
-To generate the `kubeconfig` files for this step, see link:https://access.redhat.com/documentation/en-us/red_hat_build_of_microshift/{product-version}/html/configuring/microshift-kubeconfig#generating-additional-kubeconfig-files_microshift-kubeconfig[Generating additional kubeconfig files for remote access].
+To generate the `kubeconfig` files for this step, see link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{product-version}/html/configuring/microshift-kubeconfig#generating-additional-kubeconfig-files_microshift-kubeconfig[Generating additional kubeconfig files for remote access].
 ====
+--
 
 . As `user@workstation`, update the permissions on your `~/.kube/config` file by running the following command:
 +
@@ -57,7 +61,6 @@ $ chmod go-r ~/.kube/config
 
 * As `user@workstation`, verify that {microshift-short} is running by entering the following command:
 +
-[source,terminal]
-----
-[user@workstation]$ oc get all -A
-----
+--
+include::snippets/microshift-healthy-pods-snip.adoc[leveloffset=+2]
+--
\ No newline at end of file
diff --git a/modules/microshift-adding-app-rpms-to-blueprint.adoc b/modules/microshift-adding-app-rpms-to-blueprint.adoc
index bbfc3899054d..0631727412fd 100644
--- a/modules/microshift-adding-app-rpms-to-blueprint.adoc
+++ b/modules/microshift-adding-app-rpms-to-blueprint.adoc
@@ -6,7 +6,7 @@
 [id="microshift-adding-app-rpms-to-blueprint_{context}"]
 = Adding application RPMs to a blueprint
 
-To add application RPMs to a blueprint, you must create a local repository that Image Builder can use to create the ISO. With this procedure, the required container images for your workload can be pulled over the network.
+To add application RPMs to a blueprint, you must create a local repository that image builder can use to create the ISO. With this procedure, the required container images for your workload can be pulled over the network.
 
 .Prerequisites
 
diff --git a/modules/microshift-adding-service-to-blueprint.adoc b/modules/microshift-adding-service-to-blueprint.adoc
index 87dad62b3603..88267b6a6278 100644
--- a/modules/microshift-adding-service-to-blueprint.adoc
+++ b/modules/microshift-adding-service-to-blueprint.adoc
@@ -37,7 +37,7 @@ groups = []
 
 [[packages]]
 name = "microshift"
-version = "4.18.1" <3>
+version = "4.19.1" <3>
 
 [customizations.services]
 enabled = ["microshift"]
@@ -45,7 +45,7 @@ EOF
 ----
 <1> The name of the TOML file.
 <2> The name of the blueprint.
-<3> Substitute the value for the version you want. For example, insert `4.18.1` to download the {microshift-short} 4.18.1 RPMs.
+<3> Substitute the value for the version you want. For example, insert `4.19.1` to download the {microshift-short} 4.19.1 RPMs.
 
 . Optional. Use the blueprint installed in the `/usr/share/microshift/blueprint` directory that is specific to your platform architecture. See the following example snippet for an explanation of the blueprint sections:
 +
diff --git a/modules/microshift-auto-recovery-example-bootc-systems.adoc b/modules/microshift-auto-recovery-example-bootc-systems.adoc
new file mode 100644
index 000000000000..e89da20976c1
--- /dev/null
+++ b/modules/microshift-auto-recovery-example-bootc-systems.adoc
@@ -0,0 +1,93 @@
+// Module included in the following assemblies:
+//
+// * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-auto-recovery-example-bootc-systems_{context}"]
+= Using automatic recovery in image mode for {op-system-base} systems
+
+:FeatureName: Image mode for {op-system-base}
+
+include::snippets/technology-preview.adoc[]
+
+As a use case, consider the following example situation in which you want to automate the `auto-recovery` process for image mode for {op-system-base-full} systems that use the systemd service.
+
+[IMPORTANT]
+====
+You must include the entire `auto-recovery` process for {op-system-image} systems that use `systemd` in the container file.
+====
+
+.Prerequisites
+
+* You created a Containerfile as instructed in link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.18/html/installing_with_rhel_image_mode/installing-with-rhel-image-mode#microshift-rhel-image-mode-build-image_microshift-install-rhel-image-mode[Building the bootc image].
+
+* You created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the "Using auto-recovery in RPM systems" section.
++
+[IMPORTANT]
+====
+The location of the the `10-auto-recovery.conf` and `microshift-auto-recovery.service` must be relative to the Containerfile.
+
+For example, if the path to the Containerfile is `/home/microshift/my-build/Containerfile`, the systemd files need to be adjacent for proper embedding. The following paths are correct for this example:
+
+* `/home/microshift/my-build/auto-rec/10-auto-recovery.conf`
+* `/home/microshift/my-build/auto-rec/microshift-auto-recovery.service`
+* `/home/microshift/my-build/auto-rec/microshift-auto-recovery`
+====
+
+* You created the `microshift-auto-recovery` script as explained in the "Using auto-recovery in RPM systems" section.
+
+.Procedure
+
+. Use the following example snippet to update the container file that you use to prepare the {op-system-image} image.
++
+[source,text]
+----
+RUN mkdir -p /usr/lib/systemd/system/microshift.service.d
+COPY ./auto-rec/10-auto-recovery.conf /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf
+COPY ./auto-rec/microshift-auto-recovery.service /usr/lib/systemd/system/
+COPY ./auto-rec/microshift-auto-recovery /usr/bin/
+RUN chmod +x /usr/bin/microshift-auto-recovery
+----
++
+[IMPORTANT]
+====
+Podman uses the host subscription information and repositories inside the container when building the container image. If the `rhocp` and `fast-datapath` repositories are not available on the host, the build fails.
+====
+
+. Rebuild your local bootc image by running the following image build command:
++
+[source,terminal]
+----
+PULL_SECRET=~/.pull-secret.json
+USER_PASSWD=<your_redhat_user_password>
+IMAGE_NAME=microshift-4.18-bootc
+
+sudo podman build --authfile "${PULL_SECRET}" -t "${IMAGE_NAME}" \
+    --build-arg USER_PASSWD="${USER_PASSWD}" \
+    -f Containerfile
+----
++
+[NOTE]
+====
+Secrets are used during the image build in the following ways:
+
+* The podman `--authfile` argument is required to pull the base `rhel-bootc:9.4` image from the `registry.redhat.io` registry.
+
+* The build `USER_PASSWD` argument is used to set a password for the `redhat user`.
+====
+
+.Verification
+
+* Verify that the local bootc image was created by running the following command:
++
+[source,terminal]
+----
+$ sudo podman images "${IMAGE_NAME}"
+----
++
+.Example output
+[source,text]
+----
+REPOSITORY                       TAG         IMAGE ID      CREATED        SIZE
+localhost/microshift-4.18-bootc  latest      193425283c00  2 minutes ago  2.31 GB
+----
\ No newline at end of file
diff --git a/modules/microshift-automation-example-ostree-systems.adoc b/modules/microshift-auto-recovery-example-ostree-systems.adoc
similarity index 65%
rename from modules/microshift-automation-example-ostree-systems.adoc
rename to modules/microshift-auto-recovery-example-ostree-systems.adoc
index ee1e6bcae380..ef6e8416bbc8 100644
--- a/modules/microshift-automation-example-ostree-systems.adoc
+++ b/modules/microshift-auto-recovery-example-ostree-systems.adoc
@@ -3,50 +3,60 @@
 // * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-automation-example-ostree-systems_{context}"]
-= Automating the integration process with systemd for OSTree systems
+[id="microshift-auto-recovery-ostree-systems_{context}"]
+= Using automatic recovery with {op-system-ostree}
+
+As a use case, consider the following example situation in which you want to automate the `auto-recovery` process for {op-system-ostree-first} systems that use systemd in the blueprint file.
 
 [IMPORTANT]
 ====
-You must include the entire `auto-recovery` process for OSTree systems that use `systemd` in the blueprint file.
+You must include the entire `auto-recovery` process for {op-system-ostree} systems that use `systemd` in the blueprint file.
 ====
 
-As a use case, consider the following example situation in which you want to automate the `auto-recovery` process for OSTree systems that use systemd.
+.Prerequisites
+
+* You installed Podman.
+* You installed the command-line `composer-cli` tool.
 
 .Procedure
 
+. Optional: Because the `composer-cli` can only create files in the `/etc` directory, package your files into an RPM that you include the blueprint.
+
 . Use the following example to create your blueprint file:
 +
 [source,terminal]
 ----
+[[customizations.directories]]
+path = "/etc/systemd/system/microshift.service.d"
+
+[[customizations.directories]]
+path = "/etc/bin"
+
 [[customizations.files]]
-path = "/usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf"
+path = "/etc/systemd/system/microshift.service.d/10-auto-recovery.conf"
 data = """
 [Unit]
 OnFailure=microshift-auto-recovery.service
 """
 
 [[customizations.files]]
-path = "/usr/lib/systemd/system/microshift-auto-recovery.service"
+path = "/etc/systemd/system/microshift-auto-recovery.service"
 data = """
 [Unit]
 Description=MicroShift auto-recovery
-
 [Service]
 Type=oneshot
-ExecStart=/usr/bin/microshift-auto-recovery
-
+ExecStart=/etc/bin/microshift-auto-recovery
 [Install]
 WantedBy=multi-user.target
 """
 
 [[customizations.files]]
-path = "/usr/bin/microshift-auto-recovery"
+path = "/etc/bin/microshift-auto-recovery"
 mode = "0755"
 data = """
 #!/usr/bin/env bash
 set -xeuo pipefail
-
 # If greenboot uses a non-default file for clearing boot_counter, use boot_success instead.
 if grep -q  "/boot/grubenv" /usr/libexec/greenboot/greenboot-grub2-set-success; then
     if grub2-editenv - list | grep -q ^boot_success=0; then
@@ -61,12 +71,11 @@ else
         exit 0
     fi
 fi
-
 /usr/bin/microshift restore --auto-recovery /var/lib/microshift-auto-recovery
 /usr/bin/systemctl reset-failed microshift
 /usr/bin/systemctl start microshift
-
 echo "DONE"
 """
 ----
+
 . For the next steps, see link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/embedding_in_a_rhel_for_edge_image/microshift-embed-in-rpm-ostree#preparing-for-image-building_microshift-embed-in-rpm-ostree[Preparing for image building].
\ No newline at end of file
diff --git a/modules/microshift-automation-example-rpm-systems.adoc b/modules/microshift-auto-recovery-example-rpm-systems.adoc
similarity index 75%
rename from modules/microshift-automation-example-rpm-systems.adoc
rename to modules/microshift-auto-recovery-example-rpm-systems.adoc
index e6703592607e..81f8a77ab6db 100644
--- a/modules/microshift-automation-example-rpm-systems.adoc
+++ b/modules/microshift-auto-recovery-example-rpm-systems.adoc
@@ -3,19 +3,16 @@
 // * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-automation-example-rpm-systems_{context}"]
-= Automating the integration process with systemd for RPM systems
+[id="microshift-auto-recovery-rpm-systems_{context}"]
+= Using automatic recovery in RPM systems
 
-[NOTE]
-====
-When the `microshift.service` enters a failed state, `systemd` starts the `microshift-auto-recovery.service` unit. This unit executes the `auto-recovery` restore process and restarts {microshift-short}.
-====
+When {microshift-short} enters a failed state, the systemd service starts the `microshift-auto-recovery.service` unit. This unit executes the `auto-recovery` restore process.
 
-As a use case, consider the following example situation in which you want to automate the `auto-recovery` process for RPM systems that use systemd.
+As a use case, consider the following example situation in which you want to automate the automatic recovery process for RPM systems that use the systemd service.
 
 .Procedure
 
-. Create a directory for the `microshift.service` by running the following command:
+. Create a directory for the `microshift` systemd service by running the following command:
 +
 [source,terminal]
 ----
@@ -28,8 +25,11 @@ $ sudo mkdir -p /usr/lib/systemd/system/microshift.service.d
 $ sudo tee /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf > /dev/null <<'EOF'
 [Unit]
 OnFailure=microshift-auto-recovery.service
+StartLimitIntervalSec=25s # <1>
 EOF
 ----
+<1> Increase the `StartLimitInterval` value from the default `10s` to a larger value for slower systems. A value that is too low can result in systemd never marking the `microshift` systemd service as failed, which means that the `OnFailure=` service does not get triggered.
+
 . Create the `microshift-auto-recovery.service` file by running the following command:
 +
 [source,terminal]
@@ -46,6 +46,7 @@ ExecStart=/usr/bin/microshift-auto-recovery
 WantedBy=multi-user.target
 EOF
 ----
+
 . Create the `microshift-auto-recovery` script by running the following command:
 +
 [source,terminal]
@@ -76,12 +77,14 @@ fi
 echo "DONE"
 EOF
 ----
+
 . Make the script executable by running the following command:
 +
 [source,terminal]
 ----
 $ sudo chmod +x /usr/bin/microshift-auto-recovery
 ----
+
 . Reload the system configuration by running the following command:
 +
 [source,terminal]
diff --git a/modules/microshift-auto-recovery-manual-backups.adoc b/modules/microshift-auto-recovery-manual-backups.adoc
new file mode 100644
index 000000000000..aee6a8db6580
--- /dev/null
+++ b/modules/microshift-auto-recovery-manual-backups.adoc
@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-auto-recovery-manual-backups_{context}"]
+= Modifying backup and restore commands to automate data recovery
+
+Use automatic recovery options to store all of your backups in a single directory, then automatically select the latest one to restore. Modifying existing `backup` and `restore` commands enables you to set up automatic recovery.
+
+The `--auto-recovery` option treats the `PATH` argument as a path to a directory that holds all the backups for automated recovery, and not just as a path to a particular backup file. You can use the `--auto-recovery` option with both `backup` and `restore` commands.
+
+* For example, if you use the automatic recovery option with `restore`, such as in `microshift restore --auto-recovery PATH`, running the modified command automatically selects and restores the most recent backup.
+
+* If you use the same option in the `microshift backup` command, such as in `microshift backup --auto-recovery PATH`, a new backup is created in the PATH.
+
+* By default, `microshift restore --auto-recovery PATH` creates a backup of the failed {microshift-short} data in `PATH/failed`. You can add the `--dont-save-failed` option to disable the creation of failed backup data.
+
+[IMPORTANT]
+====
+You can only use the `--dont-save-failed` option with the `restore` command.
+====
\ No newline at end of file
diff --git a/modules/microshift-automation-example-bootc-systems.adoc b/modules/microshift-automation-example-bootc-systems.adoc
deleted file mode 100644
index 302cf4e09958..000000000000
--- a/modules/microshift-automation-example-bootc-systems.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// Module included in the following assemblies:
-//
-// * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="microshift-automation-example-bootc-systems_{context}"]
-= Automating the integration process with systemd for bootc systems
-
-[IMPORTANT]
-====
-You must include the entire `auto-recovery` process for bootc systems that use `systemd` in the container file.
-====
-
-As a use case, consider the following example situation in which you want to automate the `auto-recovery` process for bootc systems that use systemd.
-
-.Prerequisites
-
-* You have created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the "Automating the integration process with systemd for RPM systems" section.
-* You have created the `microshift-auto-recovery` script as explained in the "Automating the integration process with systemd for RPM systems" section.
-
-.Procedure
-
-* Use the following example to update your Containerfile that you use to prepare the bootc image.
-+
-[source,text]
-----
-RUN mkdir -p /usr/lib/systemd/system/microshift.service.d
-COPY ./auto-rec/10-auto-recovery.conf /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf
-COPY ./auto-rec/microshift-auto-recovery.service /usr/lib/systemd/system/
-COPY ./auto-rec/microshift-auto-recovery /usr/bin/
-RUN chmod +x /usr/bin/microshift-auto-recovery && systemctl daemon-reload
-----
diff --git a/modules/microshift-ca-adding-bundle-ostree.adoc b/modules/microshift-ca-adding-bundle-ostree.adoc
index 04d1dc8fc692..9c912abeee5d 100644
--- a/modules/microshift-ca-adding-bundle-ostree.adoc
+++ b/modules/microshift-ca-adding-bundle-ostree.adoc
@@ -10,7 +10,7 @@ You can include additional trusted certificate authorities (CAs) to the {op-syst
 
 [NOTE]
 ====
-This procedure requires you to configure the CA bundle customizations in the blueprint, and then add steps to your kickstart file to enable the bundle. In the following steps, `data` is the key, and `<value>` represents the PEM-encoded certificate.
+This procedure requires you to configure the CA bundle customizations in the blueprint, and then add steps to your Kickstart file to enable the bundle. In the following steps, `data` is the key, and `<value>` represents the PEM-encoded certificate.
 ====
 
 .Prerequisites
@@ -46,10 +46,10 @@ data = "<value>"
 ----
 $ sudo update-ca-trust
 ----
-
++
 [NOTE]
 ====
-The `update-ca-trust` command might be included in the `%post` section of a kickstart file used for MicroShift host installation so that all the necessary certificate trust is enabled on the first boot. You must configure the CA bundle customizations in the blueprint before adding steps to your kickstart file to enable the bundle.
+The `update-ca-trust` command might be included in the `%post` section of a Kickstart file used for {microshift-short} host installation so that all the necessary certificate trust is enabled on the first boot. You must configure the CA bundle customizations in the blueprint before adding steps to your Kickstart file to enable the bundle.
 
 [source,terminal]
 ----
diff --git a/modules/microshift-config-parameters-table.adoc b/modules/microshift-config-parameters-table.adoc
index c1ec7b480ed5..d16685c5646f 100644
--- a/modules/microshift-config-parameters-table.adoc
+++ b/modules/microshift-config-parameters-table.adoc
@@ -53,9 +53,21 @@ The following table explains {microshift-short} configuration YAML parameters an
 |Fully qualified domain names (FQDNs), wildcards such as `*.domain.com`, or IP addresses.
 |Subject Alternative Names for API server certificates. SANs indicate all of the domain names and IP addresses that are secured by a certificate.
 
+|`tls`
+|`list`
+|Defines the transport later protocol (TLS) used and the cipher suites allowed. Provides security for the exposed {microshift-short} API server and internal control plane endpoints.
+
+|`tls.cipherSuites`
+|`string`
+|Lists the allowed cipher suites that the API server accepts and serves. Defaults to the cipher suites allowed with the TLS specification set in the `tls.minVersion` parameter.
+
+|`tls.minVersion`
+|`VersionTLS12` or `VersionTLS13`
+|Specifies the minimum version of TLS to serve from the API serve. Default is value is `VersionTLS12`. TLS 1.3 ciphers are preset and not configurable.
+
 |`debugging.logLevel`
 |`Normal`, `Debug`, `Trace`, or `TraceAll`
-|Log verbosity. Default is `Normal`.
+|Log verbosity. Default value is is `Normal`.
 
 |`dns.baseDomain`
 |`valid domain`
@@ -259,5 +271,13 @@ container_memory_working_set_bytes{container=`router`,namespace=`openshift-ingre
 
 |`storage.optionalCsiComponents`
 |`array`
-|Default value is null or an empty array. A null or empty array defaults to deploying `snapshot-controller` and `snapshot-webhook`. Expected values are `csi-snapshot-controller`, `csi-snapshot-webhook`, or `none`. An entry of `none` is mutually exclusive with all other values.
+|Default value is null or an empty array. A null or empty array defaults to deploying `snapshot-controller`. Expected values are `csi-snapshot-controller` or `none`. A value of `none` is mutually exclusive with all other values.
+
+|`telemetry.endpoint`
+|`https://infogw.api.openshift.com`
+|The endpoint where telemetry data is sent. No user or private data is included in the metrics reported. Default value is `https://infogw.api.openshift.com`.
+
+|`telemetry.status`
+|`Enabled`
+|Telemetry status, which can be `Enabled` or `Disabled`. The default value is `Enabled`.
 |===
diff --git a/modules/microshift-configuring-hosts-for-mirror.adoc b/modules/microshift-configuring-hosts-for-mirror.adoc
index 2bf752f9cbf0..bbf7b625ae4c 100644
--- a/modules/microshift-configuring-hosts-for-mirror.adoc
+++ b/modules/microshift-configuring-hosts-for-mirror.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="microshift-configuring-hosts-for-mirror_{context}"]
diff --git a/modules/microshift-creating-backups.adoc b/modules/microshift-creating-backups-auto-recovery.adoc
similarity index 86%
rename from modules/microshift-creating-backups.adoc
rename to modules/microshift-creating-backups-auto-recovery.adoc
index b683a9c1e19f..8e70d579d6fb 100644
--- a/modules/microshift-creating-backups.adoc
+++ b/modules/microshift-creating-backups-auto-recovery.adoc
@@ -3,10 +3,10 @@
 // * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-creating-backups_{context}"]
+[id="microshift-creating-backups-auto-recovery_{context}"]
 = Creating backups using the auto-recovery feature
 
-Use the following procedure to create backups.
+Use the following procedure to create backups using automatic recovery options.
 
 [NOTE]
 ====
@@ -15,14 +15,13 @@ Creating backups require stopping {microshift-short}, so you must determine the
 
 .Prerequisites
 
-* You have stopped {microshift-short}.
+* You stopped {microshift-short}.
 
 .Procedure
 
 * Create and store backups in the directory you choose by running the following command:
 +
-[source,terminal]
-[subs="+quotes"]
+[source,terminal,subs="+quotes"]
 ----
 $ sudo microshift backup --auto-recovery _<path_of_directory>_ <1>
 ----
@@ -30,11 +29,10 @@ $ sudo microshift backup --auto-recovery _<path_of_directory>_ <1>
 +
 [NOTE]
 ====
-The `--auto-recovery` option modifies the interpretation of the `PATH` argument from the final backup path to a directory that holds all the backups for automated recovery.
+The `--auto-recovery` option modifies the interpretation of the `PATH` argument from the final backup path to a directory that holds all of the backups for automated recovery.
 ====
 +
 .Example output
-+
 [source,terminal]
 ----
 ??? I1104 09:18:52.100725    8906 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}]
@@ -49,11 +47,10 @@ The `--auto-recovery` option modifies the interpretation of the `PATH` argument
 
 .Verification
 
-* To verify that the backup has been created, view the directory you chose to store backups by running the following command:
+* Verify that the backup you created exists in your customized storage directory by running the following command:
 +
-[source,terminal]
-[subs="+quotes"]
+[source,terminal,subs="+quotes"]
 ----
-$ ls -la _<path_of_directory>_ <1>
+$ sudo ls -la _<path_of_directory>_ <1>
 ----
 <1> Replace `_<path_of_directory>_` with the path of the directory that stores backups. For example, `/var/lib/microshift-auto-recovery`.
\ No newline at end of file
diff --git a/modules/microshift-creating-ostree-iso.adoc b/modules/microshift-creating-ostree-iso.adoc
index 8b5343ff0dce..9ee4fc79bebe 100644
--- a/modules/microshift-creating-ostree-iso.adoc
+++ b/modules/microshift-creating-ostree-iso.adoc
@@ -5,15 +5,16 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="microshift-creating-ostree-iso_{context}"]
-= Creating the {op-system-ostree} image
+= Creating the {op-system-ostree} image with image builder
 
 Use the following procedure to create the ISO. The {op-system-ostree} Installer image pulls the commit from the running container and creates an installable boot ISO with a Kickstart file configured to use the embedded `rpm-ostree` commit.
 
 .Prerequisites
-* Your build host meets the Image Builder system requirements.
-* You have installed and set up Image Builder and the `composer-cli` tool.
-* You have root-user access to your build host.
-* You have installed the `podman` tool.
+
+* Your build host meets the image builder system requirements.
+* You installed and set up image builder and the `composer-cli` tool.
+* You root-user access to your build host.
+* You installed the `podman` tool.
 
 .Procedure
 
@@ -35,7 +36,7 @@ $ sudo composer-cli compose status
 ----
 +
 .Example output of a running build
-
++
 [source,terminal]
 ----
 ID                                     Status     Time                     Blueprint                 Version   Type               Size
@@ -43,7 +44,7 @@ cc3377ec-4643-4483-b0e7-6b0ad0ae6332   RUNNING    Wed Jun 7 12:26:23 2023  micro
 ----
 +
 .Example output of a completed build
-
++
 [source,terminal]
 ----
 ID                                     Status     Time                      Blueprint              Version   Type               Size
diff --git a/modules/microshift-default-settings.adoc b/modules/microshift-default-settings.adoc
index c2af0084a011..b06fef9712ed 100644
--- a/modules/microshift-default-settings.adoc
+++ b/modules/microshift-default-settings.adoc
@@ -31,6 +31,10 @@ apiServer:
       names:
         - ""
   subjectAltNames: []
+  tls:
+    cipherSuites:
+            - ""
+    minVersion: VersionTLS12
 debugging:
   logLevel: "Normal"
 dns:
@@ -86,8 +90,11 @@ storage:
   driver: "" # <3>
   optionalCsiComponents: # <4>
     - ""
+telemetry:
+    endpoint: https://infogw.api.openshift.com
+    status: Enabled
 ----
 <1> Calculated based on the address of the service network.
 <2> The IP address of the default route.
 <3> Default null value deploys Logical Volume Managed Storage (LVMS).
-<4> Default null value deploys `snapshot-controller` and `snapshot-webhook`.
\ No newline at end of file
+<4> Default null value deploys `snapshot-controller`.
\ No newline at end of file
diff --git a/modules/microshift-deploying-a-load-balancer.adoc b/modules/microshift-deploying-a-load-balancer.adoc
index 4779a68b6ef1..fe6cd1574ff9 100644
--- a/modules/microshift-deploying-a-load-balancer.adoc
+++ b/modules/microshift-deploying-a-load-balancer.adoc
@@ -29,7 +29,6 @@ $ oc get pods -A
 NAMESPACE                            NAME                                                     READY   STATUS   RESTARTS  AGE
 default                              i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr  1/1     Running	   0		   46m
 kube-system                          csi-snapshot-controller-5c6586d546-lprv4                 1/1     Running	   0		   51m
-kube-system                          csi-snapshot-webhook-6bf8ddc7f5-kz6k9                    1/1     Running	   0		   51m
 openshift-dns                        dns-default-45jl7                                        2/2     Running	   0		   50m
 openshift-dns                        node-resolver-7wmzf                                      1/1     Running	   0		   51m
 openshift-ingress                    router-default-78b86fbf9d-qvj9s                          1/1     Running 	 0		   51m
diff --git a/modules/microshift-disabling-lvms-csi-snapshot.adoc b/modules/microshift-disabling-lvms-csi-snapshot.adoc
index 23d6c8986547..ac34f7aa4956 100644
--- a/modules/microshift-disabling-lvms-csi-snapshot.adoc
+++ b/modules/microshift-disabling-lvms-csi-snapshot.adoc
@@ -32,11 +32,11 @@ This procedure is for users who are defining the configuration file before insta
 <1> Accepted values are:
 * Not defining `optionalCsiComponents`.
 * Specifying `optionalCsiComponents` field with an empty value (`[]`) or a single empty string element (`[""]`).
-* Specifying `optionalCsiComponents` with one of the accepted values which are `snapshot-controller`, `snapshot-webhook`, or `none`. `none` is mutually exclusive with all other values.
+* Specifying `optionalCsiComponents` with one of the accepted values which are `snapshot-controller`, or `none`. A value of `none` is mutually exclusive with all other values.
 +
 [NOTE]
 ====
-If the `optionalCsiComponents` value is empty or null, {microshift-short} defaults to deploying snapshot-controller and snapshot-webhook.
+If the `optionalCsiComponents` value is empty or null, {microshift-short} defaults to deploying snapshot-controller.
 ====
 
 . After the `optionalCsiComponents` field is specified with a supported value in the `config.yaml`, start {microshift-short} by running the following command:
diff --git a/modules/microshift-disconnected-host-procedure.adoc b/modules/microshift-disconnected-host-procedure.adoc
index e1f2dca52e02..5b8845189320 100644
--- a/modules/microshift-disconnected-host-procedure.adoc
+++ b/modules/microshift-disconnected-host-procedure.adoc
@@ -95,7 +95,7 @@ $ sudo systemctl reboot <1>
 
 At this point, network access to the {microshift-short} host has been severed. If you have access to the host terminal, you can use the host CLI to verify that the cluster has started in a stable state.
 
-. Verify that the {microshift-short} cluster is running by entering the following command:
+. Verify that the {microshift-short} cluster is running by entering the following commands:
 +
 [source,terminal]
 ----
@@ -108,7 +108,6 @@ $ sudo -E oc get pods -A
 ----
 NAMESPACE                  NAME                                       READY   STATUS    RESTARTS      AGE
 kube-system                csi-snapshot-controller-74d566564f-66n2f   1/1     Running   0             1m
-kube-system                csi-snapshot-webhook-69bdff8879-xs6mb      1/1     Running   0             1m
 openshift-dns              dns-default-dxglm                          2/2     Running   0             1m
 openshift-dns              node-resolver-dbf5v                        1/1     Running   0             1m
 openshift-ingress          router-default-8575d888d8-xmq9p            1/1     Running   0             1m
diff --git a/modules/microshift-download-iso-prep-for-use.adoc b/modules/microshift-download-iso-prep-for-use.adoc
index e42ee4b1053b..99d6757a172e 100644
--- a/modules/microshift-download-iso-prep-for-use.adoc
+++ b/modules/microshift-download-iso-prep-for-use.adoc
@@ -27,3 +27,8 @@ $ sudo chown $(whoami). ${BUILDID}-installer.iso
 ----
 $ sudo chmod a+r ${BUILDID}-installer.iso
 ----
+
+.Next steps
+
+* Provision a virtual machine with a Kickstart file.
+//Q: We don't actually finish the procedures showing launching the virtual machine and using this ISO. Should we include those procedure or link to them more constructively?
diff --git a/modules/microshift-downloading-container-images.adoc b/modules/microshift-downloading-container-images.adoc
index 274f08208912..077c16fca78b 100644
--- a/modules/microshift-downloading-container-images.adoc
+++ b/modules/microshift-downloading-container-images.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="microshift-downloading-container-images_{context}"]
@@ -11,7 +11,7 @@ After you have located the container list and completed the mirroring prerequisi
 .Prerequisites
 
 * You are logged into a host with access to the internet.
-* You have ensured that the `.pull-secret-mirror.json` file and `microshift-containers` directory contents are available locally.
+* The `.pull-secret-mirror.json` file and `microshift-containers` directory contents are available locally.
 
 .Procedure
 
@@ -61,5 +61,3 @@ while read -r src_img ; do
 
 done < "${IMAGE_LIST_FILE}"
 ----
-
-. Transfer the image set to the target environment, such as air-gapped site. Then you can upload the image set into the mirror registry.
\ No newline at end of file
diff --git a/modules/microshift-embed-app-rpms-tutorial.adoc b/modules/microshift-embed-app-rpms-tutorial.adoc
index 8614bf8a3480..d6dda97e1684 100644
--- a/modules/microshift-embed-app-rpms-tutorial.adoc
+++ b/modules/microshift-embed-app-rpms-tutorial.adoc
@@ -21,20 +21,20 @@ image:468_RHbM_install_workflow_1023_1.png[title="Embedding MicroShift in a RHEL
 
 Reviewing these steps can help you understand the steps needed to embed an application:
 
-. To embed {microshift-short} on {op-system-ostree}, you added the {microshift-short} repositories to Image Builder.
+. To embed {microshift-short} on {op-system-ostree}, you added the {microshift-short} repositories to image builder.
 
 . You created a blueprint that declared all the RPMs, container images, files and customizations you needed, including the addition of {microshift-short}.
 
-. You added the blueprint to Image Builder and ran a build with the Image Builder CLI tool (`composer-cli`). This step created `rpm-ostree` commits, which were used to create the container image. This image contained {op-system-ostree}.
+. You added the blueprint to image builder and ran a build with the image builder CLI tool (`composer-cli`). This step created `rpm-ostree` commits, which were used to create the container image. This image contained {op-system-ostree}.
 
-. You added the installer blueprint to Image Builder to create an `rpm-ostree` image (ISO) to boot from. This build contained both {op-system-ostree} and {microshift-short}.
+. You added the installer blueprint to image builder to create an `rpm-ostree` image (ISO) to boot from. This build contained both {op-system-ostree} and {microshift-short}.
 
 . You downloaded the ISO with {microshift-short} embedded, prepared it for use, provisioned it, then installed it onto your edge devices.
 
 [id="microshift-embed-app-rpms-workflow_{context}"]
 == Embed application RPMs workflow
 
-After you have set up a build host that meets the Image Builder requirements, you can add your application in the form of a directory of manifests to the image. After those steps, the simplest way to embed your application or workload into a new ISO is to create your own RPMs that include the manifests. Your application RPMs contain all of the configuration files describing your deployment.
+After you have set up a build host that meets the image builder requirements, you can add your application in the form of a directory of manifests to the image. After those steps, the simplest way to embed your application or workload into a new ISO is to create your own RPMs that include the manifests. Your application RPMs contain all of the configuration files describing your deployment.
 
 The following "Embedding applications workflow" image shows how Kubernetes application manifests and RPM spec files are combined in a single application RPM build. This build becomes the RPM artifact included in the workflow for embedding {microshift-short} in an ostree commit.
 
diff --git a/modules/microshift-embed-images-offline-use.adoc b/modules/microshift-embed-images-offline-use.adoc
index 2cf3959031e6..5af0d3d3b5a9 100644
--- a/modules/microshift-embed-images-offline-use.adoc
+++ b/modules/microshift-embed-images-offline-use.adoc
@@ -32,7 +32,7 @@ $ sudo composer-cli blueprints push <my_blueprint>.toml
 
 . If your workload containers are located in a private repository, you must provide image builder with the necessary pull secrets:
 
-.. Set the `auth_file_path` in the `[containers]` section of the `osbuilder worker` configuration in the `/etc/osbuild-worker/osbuild-worker.toml` file to point to the pull secret.
+.. Set the `auth_file_path` in the `[containers]` section in the `/etc/osbuild-worker/osbuild-worker.toml` configuration file to point to the pull secret.
 
 .. If needed, create a directory and file for the pull secret, for example:
 +
diff --git a/modules/microshift-provisioning-ostree.adoc b/modules/microshift-embed-kickstart-in-iso.adoc
similarity index 56%
rename from modules/microshift-provisioning-ostree.adoc
rename to modules/microshift-embed-kickstart-in-iso.adoc
index 8c4d4c93e189..5df45ea3b236 100644
--- a/modules/microshift-provisioning-ostree.adoc
+++ b/modules/microshift-embed-kickstart-in-iso.adoc
@@ -1,40 +1,24 @@
 // Module included in the following assemblies:
 //
-// microshift/microshift-embed-into-rpm-ostree.adoc
+// microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="provisioning-a-machine_{context}"]
-= Provisioning a machine for {microshift-short}
+[id="microshift-embed-kickstart-iso_{context}"]
+= Embedding a Kickstart file in an ISO
 
-Provision a machine with your {op-system-ostree} image by using the procedures from the {op-system-ostree} documentation.
-
-To use {microshift-short}, you must provision the system so that it meets the following requirements:
-
-* The machine you are provisioning must meet the system requirements for installing {microshift-short}.
-* The file system must have a logical volume manager (LVM) volume group (VG) with sufficient capacity for the persistent volumes (PVs) of your workload.
-* A pull secret from the https://console.redhat.com/openshift/install/pull-secret[Red Hat Hybrid Cloud Console] must be present as `/etc/crio/openshift-pull-secret` and have root user-only read/write permissions.
-* The firewall must be configured with the required settings.
-
-[NOTE]
-====
-If you are using a Kickstart such as the {op-system-ostree} Installer (ISO) image, you can update your Kickstart file to meet the provisioning requirements.
-====
+You can use the Kickstart file provided with {microshift-short}, or you can update an existing {op-system-ostree} Installer (ISO) Kickstart file. When ready, embed the Kickstart file into the ISO. Your Kickstart file must include detailed instructions about how to create a user and how to fetch and deploy the {op-system-ostree} image.
 
 .Prerequisites
 
-. You have created a {op-system-ostree} Installer (ISO) image containing your {op-system-ostree} commit with {product-title}.
-.. This requirement includes the steps of composing an RFE Container image, creating the RFE Installer blueprint, starting the RFE container, and composing the RFE Installer image.
-. Create a Kickstart file or use an existing one. In the Kickstart file, you must include:
-.. Detailed instructions about how to create a user.
-.. How to fetch and deploy the {op-system-ostree} image.
+* You created a {op-system-ostree} Installer (ISO) image containing your {op-system-ostree} commit with {microshift-short}.
 
-For more information, read "Additional resources."
+* You have an existing Kickstart file ready for updating. You can use the `microshift-starter.ks` Kickstart file provided with the {microshift-short} RPMs.
 
 .Procedure
 
 . In the main section of the Kickstart file, update the setup of the filesystem such that it contains an LVM volume group called `rhel` with at least 10GB system root. Leave free space for the LVMS CSI driver to use for storing the data for your workloads.
 +
-.Example kickstart snippet for configuring the filesystem
+.Example Kickstart file snippet for configuring the filesystem
 [source,text]
 ----
 # Partition disk such that it contains an LVM volume group called `rhel` with a
@@ -68,7 +52,7 @@ user --name=<YOUR_USER_NAME> \
 
 . In the `%post` section of the Kickstart file, add your pull secret and the mandatory firewall rules.
 +
-.Example Kickstart snippet for adding the pull secret and firewall rules
+.Example Kickstart file snippet for adding the pull secret and firewall rules
 [source,terminal]
 ----
 %post --log=/var/log/anaconda/post-install.log --erroronfail
@@ -93,7 +77,7 @@ firewall-offline-cmd --zone=trusted --add-source=169.254.169.1
 $ sudo yum install -y lorax
 ----
 
-. Update the Kickstart file in the ISO with your new Kickstart file by running the following command:
+. Update the ISO with your new Kickstart file by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/microshift-embed-microshift-image-offline-deploy.adoc b/modules/microshift-embed-microshift-image-offline-deploy.adoc
index 8141f2e5d4a4..b5ef404d7a53 100644
--- a/modules/microshift-embed-microshift-image-offline-deploy.adoc
+++ b/modules/microshift-embed-microshift-image-offline-deploy.adoc
@@ -7,15 +7,15 @@
 [id="microshift-embed-microshift-image-offline-deployment_{context}"]
 = Embedding {microshift-short} containers for offline deployments
 
-You can use image builder to create `rpm-ostree` system images with embedded {microshift-short} container images. To embed container images, you must add the image references to your image builder blueprint.
+You can use image builder to create {op-system-ostree} images with embedded {microshift-short} container images. To embed container images, you must add the image references to your image builder blueprint file.
 
 .Prerequisites
 
 * You have root-user access to your build host.
 * Your build host meets the image builder system requirements.
-* You have installed and set up image builder and the `composer-cli` tool.
-* You have created a {op-system-ostree} image blueprint.
-* You have installed jq.
+* You installed and set up image builder and the `composer-cli` tool.
+* You created a {op-system-ostree} image blueprint.
+* You installed jq.
 
 .Procedure
 
@@ -25,17 +25,17 @@ You can use image builder to create `rpm-ostree` system images with embedded {mi
 
 .. Install the `microshift-release-info` RPM package by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ sudo dnf install -y microshift-release-info-<release_version>
+$ sudo dnf install -y microshift-release-info-_<release_version>_
 ----
-Replace `<release_version>` with the numerical value of the release you are deploying, using the entire version number, such as `4.18.1`.
+Replace `_<release_version>_` with the numerical value of the release you are deploying, using the entire version number, such as `4.19.1`.
 
 .. List the contents of the `/usr/share/microshift/release` directory to verify the presence of the release information files by running the following command:
 +
 [source,terminal]
 ----
-$ ls /usr/share/microshift/release
+$ sudo ls /usr/share/microshift/release
 ----
 +
 .Example output
@@ -45,50 +45,49 @@ release-x86_64.json
 release-aarch64.json
 ----
 +
-If you installed the `microshift-release-info` RPM, you can proceed to step 4.
+If you installed the `microshift-release-info` RPM, proceed to step 4.
 
 . If you did not complete step 2, download and unpack the `microshift-release-info` RPM without installing it:
 
 .. Download the RPM package by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ sudo dnf download microshift-release-info-<release_version>
+$ sudo dnf download microshift-release-info-_<release_version>_ # <1>
 ----
-Replace `<release_version>` with the numerical value of the release you are deploying, using the entire version number, such as `4.18.1`.
+<1> Replace `_<release_version>_` with the numerical value of the release you are deploying, using the entire version number, such as `4.19.1`.
 +
-.Example rpm
-[source,terminal]
+.Example RPM output
+[source,terminal,subs="+quotes"]
 ----
-microshift-release-info-4.18.1.*.el9.noarch.rpm <1>
+microshift-release-info-4.18.1.-202511101230.p0.g7dc6a00.assembly.4.18.1.el9.noarch.rpm
 ----
-<1> The `*` represents the date and commit ID. Your output should contain both, for example `-202511101230.p0.g7dc6a00.assembly.4.18.1`.
 
 .. Unpack the RPM package without installing it by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ rpm2cpio <my_microshift_release_info> | cpio -idmv <1>
+$ rpm2cpio _<my_microshift_release_info>_ | cpio -idmv # <1>
 ./usr/share/microshift/release/release-aarch64.json
 ./usr/share/microshift/release/release-x86_64.json
 ----
-<1> Replace `<my_microshift_release_info>` with the name of the RPM package from the previous step.
+<1> Replace `_<my_microshift_release_info>_` with the name of the RPM package from the previous step.
 
 . Define the location of your JSON file, which contains the container reference information, by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ RELEASE_FILE=</path/to/your/release-$(uname -m).json>
+$ RELEASE_FILE=_</path/to/your/release-$(uname -m).json>_ # <1>
 ----
-Replace `</path/to/your/release-$(uname -m).json>` with the full path to your JSON file. Be sure to use the file needed for your architecture.
+<1> Replace `_</path/to/your/release-$(uname -m).json>_` with the full path to your JSON file. Be sure to use the file needed for your architecture.
 
 . Define the location of your TOML file, which contains instructions for building the image, by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ BLUEPRINT_FILE=</path/to/your/blueprint.toml>
+$ BLUEPRINT_FILE=_</path/to/your/blueprint.toml>_ # <1>
 ----
-Replace `</path/to/your/blueprint.toml>` with the full path to your JSON file.
+<1> Replace `_</path/to/your/blueprint.toml>_` with the full path to your TOML file.
 
 . Generate and then embed the container image references in your blueprint TOML file by running the following command:
 +
@@ -97,7 +96,7 @@ Replace `</path/to/your/blueprint.toml>` with the full path to your JSON file.
 $  jq -r '.images | .[] | ("[[containers]]\nsource = \"" + . + "\"\n")' "${RELEASE_FILE}" >> "${BLUEPRINT_FILE}"
 ----
 +
-.Example resulting `<my_blueprint.toml>` fragment showing container references
+.Example resulting TOML fragment showing container references
 [source,terminal]
 ----
 [[containers]]
@@ -107,12 +106,12 @@ source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:82cfef91557f9a70
 source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:82cfef91557f9a70cff5a90accba45841a37524e9b93f98a97b20f6b2b69e5db"
 ----
 
-. You can manually embed any container image by adding it to the image builder blueprint using the following example:
+. You can manually embed any container image by adding it to an image builder blueprint file using the following example:
 +
-.Example section for manually embedding container image to image builder
-[source,terminal]
+.Example section for manually embedding container image to a blueprint
+[source,text,subs="+quotes"]
 ----
 [[containers]]
-source = "<my_image_pullspec_with_tag_or_digest>"
+source = "_<my_image_pullspec_with_tag_or_digest>_"
 ----
-Replace `<my_image_pullspec_with_tag_or_digest>` with the exact reference to a container image used by the {microshift-short} version you are deploying.
+Replace `_<my_image_pullspec_with_tag_or_digest>_` with the exact reference to a container image used by the {microshift-short} version you are deploying.
diff --git a/modules/microshift-embed-ostree-enable-eus-repos.adoc b/modules/microshift-embed-ostree-enable-eus-repos.adoc
new file mode 100644
index 000000000000..d45b4573dd1a
--- /dev/null
+++ b/modules/microshift-embed-ostree-enable-eus-repos.adoc
@@ -0,0 +1,101 @@
+// Module included in the following assemblies:
+//
+// * microshift_install_rpm_ostree/microshift-embed-into-rpm-ostree.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-enable-eus-repos_{context}"]
+= Enabling extended support repositories for image building
+
+If you have an extended support (EUS) release of {microshift-short} or {op-system-base-full}, you must enable the {op-system-base} EUS repositories for image builder to use. If you do not have an EUS version, you can skip these steps.
+
+.Prerequisites
+
+* You have an EUS version of {microshift-short} or {op-system-base} or are updating to one.
+* You have root-user access to your build host.
+* You reviewed the link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/getting_ready_to_install_microshift/microshift-install-get-ready#get-ready-install-rhde-compatibility-table_microshift-install-get-ready[{op-system-bundle} release compatibility matrix].
+
+include::snippets/microshift-unsupported-config-warn.adoc[leveloffset=+1]
+
+.Procedure
+
+. Create the `/etc/osbuild-composer/repositories` directory by running the following command:
++
+[source,terminal]
+----
+$ sudo mkdir -p /etc/osbuild-composer/repositories
+----
+
+. Copy the `/usr/share/osbuild-composer/repositories/rhel-{op-system-version}.json` file into the `/etc/osbuild-composer/repositories` directory by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo cp /usr/share/osbuild-composer/repositories/rhel-{op-system-version}.json /etc/osbuild-composer/repositories/rhel-{op-system-version}.json
+----
+
+. Update the `baseos` source by modifying the `/etc/osbuild-composer/repositories/rhel-{op-system-version}.json` file with the following values:
++
+[source,terminal,subs="attributes+"]
+----
+# ...
+"baseurl": "https://cdn.redhat.com/content/eus/rhel{op-system-version-major}/{op-system-version}//baseos/os", # <1>
+# ...
+----
+<1> You can replace _{op-system-version-major}_ with the major {op-system-base} version you are using if different from the value in this example, and replace _{op-system-version}_ with the _<major.minor>_ version. Be certain that the {op-system-base} version you choose is compatible with the {microshift-short} version you are using.
+
+. Optional: Apply the `baseos` update by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo sed -i "s,dist/rhel{op-system-version-major}/{op-system-version}/$(uname -m)/baseos/,eus/rhel{op-system-version-major}/{op-system-version}/$(uname -m)/baseos/,g" \
+/etc/osbuild-composer/repositories/rhel-{op-system-version}.json # <1>
+----
+<1> You can replace _{op-system-version-major}_ with the major {op-system-base} version you are using if different from the value in this example, and replace _{op-system-version}_ with the _<major.minor>_ version. Be certain that the {op-system-base} version you choose is compatible with the {microshift-short} version you are using.
+
+. Update the `appstream` source by modifying the `/etc/osbuild-composer/repositories/rhel-<major.minor>.json` file with the following values:
++
+[source,terminal,subs="attributes+"]
+----
+# ...
+"baseurl": "https://cdn.redhat.com/content/eus/rhel{op-system-version-major}/{op-system-version}//appstream/os", # <1>
+# ...
+----
+<1> You can replace _{op-system-version-major}_ with the major {op-system-base} version you are using if different from the value in this example, and replace _{op-system-version}_ with the _<major.minor>_ version. Be certain that the {op-system-base} version you choose is compatible with the {microshift-short} version you are using.
+
+. Optional. Apply the `appstream` update by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo sed -i "s,dist/rhel{op-system-version-major}/{op-system-version}/$(uname -m)/appstream/,eus/rhel{op-system-version-major}/{op-system-version}/$(uname -m)/appstream/,g" \
+/etc/osbuild-composer/repositories/rhel-{op-system-version}.json # <1>
+----
+<1> You can replace _{op-system-version-major}_ with the major {op-system-base} version you are using if different from the value in this example, and replace _{op-system-version}_ with the _<major.minor>_ version. Be certain that the {op-system-base} version you choose is compatible with the {microshift-short} version you are using.
+
+.Verification
+
+You can verify the repositories by using the `composer-cli` tool to display information about the source.
+
+. Verify the `baseos` source by running the following command:
++
+[source,terminal]
+----
+$ sudo composer-cli sources info baseos | grep 'url ='
+----
+.Example output
++
+[source,text,subs="attributes+"]
+----
+url = "https://cdn.redhat.com/content/eus/rhel{op-system-version-major}/{op-system-version}/x86_64/baseos/os"
+----
+
+. Verify the `appstream` source by running the following command:
++
+[source,terminal]
+----
+$ sudo composer-cli sources info appstream | grep 'url ='
+----
+.Example output
++
+[source,text,subs="attributes+"]
+----
+url = "https://cdn.redhat.com/content/eus/rhel{op-system-version-major}/{op-system-version}/x86_64/appstream/os"
+----
\ No newline at end of file
diff --git a/modules/microshift-embed-microshift-update-osbuilder-worker.adoc b/modules/microshift-embed-registry-auth-image-building.adoc
similarity index 56%
rename from modules/microshift-embed-microshift-update-osbuilder-worker.adoc
rename to modules/microshift-embed-registry-auth-image-building.adoc
index 51efbafc5798..2d8f6b4f2dfb 100644
--- a/modules/microshift-embed-microshift-update-osbuilder-worker.adoc
+++ b/modules/microshift-embed-registry-auth-image-building.adoc
@@ -3,10 +3,10 @@
 // microshift_running_applications/embed-microshift-offline-deploy.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-embed-microshift-update-osbuilder-worker_{context}"]
-= Updating osbuilder worker configuration to prepare for image building
+[id="microshift-embed-registry-auth-image-building_{context}"]
+= Adding registry authentication to prepare for image building
 
-After you have updated the blueprint, you must update the osbuilder worker configuration to prepare for building the image with embedded {microshift-short} containers.
+After you have updated the blueprint, you must add authentication for the container registries to build the image with embedded {microshift-short} containers. To do this, update one of the systemd service files that are part of the Image Builder configuration.
 
 .Prerequisites
 
@@ -21,7 +21,7 @@ You can create an `/etc/osbuild-worker/osbuild-worker.toml` directory and config
 
 .Procedure
 
-. Add a pull secret for authenticating to the registry by setting the `auth_file_path` in the `[containers]` section of the `/etc/osbuild-worker/osbuild-worker.toml` osbuilder worker configuration file:
+. Add a pull secret for authenticating to the registry by setting the `auth_file_path` in the `[containers]` section of the `/etc/osbuild-worker/osbuild-worker.toml` configuration file:
 +
 [source,terminal]
 ----
@@ -29,4 +29,4 @@ You can create an `/etc/osbuild-worker/osbuild-worker.toml` directory and config
 auth_file_path = "/etc/osbuild-worker/pull-secret.json"
 ----
 
-. Restart the `osbuild-worker` to apply configuration changes by restarting the host. Restarting the host ensures that all `osbuild-worker` services currently running are restarted.
+. Restart the host to apply configuration changes.
diff --git a/modules/microshift-firewall-allow-traffic.adoc b/modules/microshift-firewall-allow-traffic.adoc
index 4036bfbd51dc..aeb9dc34b9b8 100644
--- a/modules/microshift-firewall-allow-traffic.adoc
+++ b/modules/microshift-firewall-allow-traffic.adoc
@@ -32,3 +32,10 @@ $ sudo firewall-offline-cmd --permanent --zone=trusted --add-source=<custom IP r
 ----
 $ sudo firewall-offline-cmd --permanent --zone=trusted --add-source=169.254.169.1
 ----
+
+. If you are using a load balancer, allow the IPv6 traffic through the firewall by running the following command:
++
+[source,terminal]
+----
+$ sudo firewall-cmd --permanent --zone=trusted --add-source=fd01::/48
+----
\ No newline at end of file
diff --git a/modules/microshift-firewall-apply-settings.adoc b/modules/microshift-firewall-apply-settings.adoc
index c47eb52254b6..11ac80a187bd 100644
--- a/modules/microshift-firewall-apply-settings.adoc
+++ b/modules/microshift-firewall-apply-settings.adoc
@@ -11,7 +11,7 @@ To apply firewall settings, use the following one-step procedure:
 .Procedure
 
 * After you have finished configuring network access through the firewall, run the following command to restart the firewall and apply the settings:
-
++
 [source,terminal]
 ----
 $ sudo firewall-cmd --reload
diff --git a/modules/microshift-get-mirror-reg-container-image-list.adoc b/modules/microshift-get-mirror-reg-container-image-list.adoc
index 6e65827d3d9d..801a193a6de4 100644
--- a/modules/microshift-get-mirror-reg-container-image-list.adoc
+++ b/modules/microshift-get-mirror-reg-container-image-list.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="microshift-get-mirror-reg-container-image-list_{context}"]
diff --git a/modules/microshift-get-rpm-release-info.adoc b/modules/microshift-get-rpm-release-info.adoc
index e85f06a2c1a7..f480fa726ff2 100644
--- a/modules/microshift-get-rpm-release-info.adoc
+++ b/modules/microshift-get-rpm-release-info.adoc
@@ -42,8 +42,7 @@ microshift-release-info-0:4.17.9-202408220842.p0.gefa92a2.assembly.4.17.9.el9.no
 . Download the RPM package you want by running the following command:
 +
 --
-[subs="+quotes"]
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
 $ sudo dnf download microshift-release-info-_<release_version>_ # <1>
 ----
@@ -52,18 +51,16 @@ $ sudo dnf download microshift-release-info-_<release_version>_ # <1>
 +
 --
 .Example output
-[subs="+quotes"]
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-microshift-release-info-4.17.1.-202311101230.p0.g7dc6a00.assembly.4.17.1.el9.noarch.rpm # <1>
+microshift-release-info-4.17.1.-202411101230.p0.g7dc6a00.assembly.4.17.1.el9.noarch.rpm # <1>
 ----
 <1> Your output should contain the date and commit ID.
 --
 
 . Unpack the RPM package without installing it by running the following command:
 +
-[subs="+quotes"]
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
 $ rpm2cpio _<microshift_release_info>_ | cpio -idmv # <1>
 ----
diff --git a/modules/microshift-greenboot-prerollback-log.adoc b/modules/microshift-greenboot-prerollback-log.adoc
index 4fe41dbe7f10..e7beb9c314c3 100644
--- a/modules/microshift-greenboot-prerollback-log.adoc
+++ b/modules/microshift-greenboot-prerollback-log.adoc
@@ -31,10 +31,10 @@ boot_indeterminate=0
 boot_counter=0
 The ostree status:
 * rhel c0baa75d9b585f3dd989a9cf05f647eb7ca27ee0dbd4b94fe8c93ed3a4b9e4a5.0
-    Version: 9.1
+    Version: 9.6
     origin: <unknown origin type>
   rhel 6869c1347b0e0ba1bbf0be750cdf32da5138a1fcbc5a4c6325ab9eb647b64663.0 (rollback)
-    Version: 9.1
+    Version: 9.6
     origin refspec: edge:rhel/9/x86_64/edge
 System rollback imminent - preparing MicroShift for a clean start
 Stopping MicroShift services
diff --git a/modules/microshift-info-collected-telemetry.adoc b/modules/microshift-info-collected-telemetry.adoc
new file mode 100644
index 000000000000..7f8d5d339326
--- /dev/null
+++ b/modules/microshift-info-collected-telemetry.adoc
@@ -0,0 +1,66 @@
+// Module included in the following assemblies:
+//
+// * microshift_support/microshift-remote-cluster-monitoring.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="microshift-info-collected-by-telemetry_{context}"]
+= Information collected by the {microshift-short} Telemetry API
+
+All metrics combined are generally under 2KB and not expected to consume cluster resources.
+
+The following information is collected by Telemetry:
+
+[id="microshift-telemetry-system-information_{context}"]
+== System information
+
+The system information describes the basic configuration of your {microshift-short} cluster and where it is running, for example:
+
+* Version information, including the {microshift-short} cluster version.
+* The {op-system-base-full} version.
+* The {op-system-base} deployment type.
+
+[id="microshift-telemetry-sizing-information_{context}"]
+== Sizing information
+
+Sizing information details the cluster capacity, for example:
+
+* The CPU cores {microshift-short} can use.
+* Architecture information.
+* The usable bytes of memory.
+
+[id="microshift-telemetry-usage-information_{context}"]
+== Usage information
+
+Usage information outlines what is happening in the cluster, for example:
+
+* The CPU usage in percentage.
+* The memory usage in percentage.
+* The number of Kubernetes objects by resource type (CRDs).
+* The number of running containers, namespaces, and running pods.
+* The number of routes, ingress, services.
+
+[NOTE]
+====
+Telemetry does not collect identifying information such as usernames or passwords. Red{nbsp}Hat does not intend to collect personal information. If Red{nbsp}Hat discovers that personal information has been inadvertently received, Red{nbsp}Hat deletes such information. To the extent that any Telemetry constitutes personal data, refer to the link:https://www.redhat.com/en/about/privacy-policy[Red{nbsp}Hat Privacy Statement] for more information about Red{nbsp}Hat's privacy practices.
+====
+
+[id="microshift-additional-details-rhm-data-use_{context}"]
+== Additional details about how remote health monitoring data is used
+
+Red{nbsp}Hat collects data about your use of the Red{nbsp}Hat product(s) for purposes such as providing support and troubleshooting, improving the offerings and user experience, responding to issues, and for billing purposes if applicable.
+
+.Collection safeguards
+
+Red{nbsp}Hat employs technical and organizational measures designed to protect Telemetry data.
+
+.Sharing
+
+Red{nbsp}Hat might share the data collected through the Telemetry API internally within Red{nbsp}Hat to improve your user experience. Red{nbsp}Hat might share Telemetry data with its business partners in an aggregated form that does not identify customers to help the partners better understand their markets and their customers' use of Red{nbsp}Hat offerings, or to ensure the successful integration of products jointly supported by those partners.
+
+.Third parties
+
+Red{nbsp}Hat might engage certain third parties to assist in the collection, analysis, and storage of Telemetry data.
+
+.User control: Disabling Telemetry data collection
+
+You can disable {microshift-short} Telemetry by following the instructions in the "Opting out of remote health reporting for {microshift-short}" section.
\ No newline at end of file
diff --git a/modules/microshift-install-rhel-image-mode-build-image.adoc b/modules/microshift-install-bootc-build-image.adoc
similarity index 66%
rename from modules/microshift-install-rhel-image-mode-build-image.adoc
rename to modules/microshift-install-bootc-build-image.adoc
index 0c5ab0a5b9a4..915ee9d2f5e3 100644
--- a/modules/microshift-install-rhel-image-mode-build-image.adoc
+++ b/modules/microshift-install-bootc-build-image.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// microshift_install_bootc/microshift-install-rhel-image-mode.adoc
+// microshift_install_bootc/microshift-install-rhel-bootc-image.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-rhel-image-mode-build-image_{context}"]
+[id="microshift-install-bootc-build-image_{context}"]
 = Building the bootc image
 
 Build your {op-system-base-full} that contains {microshift-short} as a bootable container image by using a Containerfile.
@@ -14,8 +14,9 @@ Image mode for {op-system-base} is Technology Preview. Using a bootc image in pr
 ====
 
 .Prerequisites
-* A {op-system-base-full} 9.4 host with an active Red Hat subscription for building {microshift-short} bootc images and running containers.
-* You are logged into the {op-system-base} 9.4 host using the user credentials that have `sudo` permissions.
+
+* A {op-system-base} {op-system-version} host with an active Red{nbsp}Hat subscription for building {microshift-short} bootc images and running containers.
+* You logged into the {op-system-base} {op-system-version} host by using the user credentials that have `sudo` permissions.
 * The `rhocp` and `fast-datapath` repositories are accessible in the host subscription. The repositories do not necessarily need to be enabled on the host.
 * You have a remote registry such as link:https://quay.io[Red Hat quay] for storing and accessing bootc images.
 
@@ -24,14 +25,14 @@ Image mode for {op-system-base} is Technology Preview. Using a bootc image in pr
 . Create a Containerfile that includes the following instructions:
 +
 .Example Containerfile for {op-system-base} image mode
-[source,text]
+[source,text,subs="attributes+"]
 ----
-FROM registry.redhat.io/rhel9/rhel-bootc:9.4
+FROM registry.redhat.io/rhel{op-system-version-major}/rhel-bootc:{op-system-version}
 
-ARG USHIFT_VER=4.17
+ARG USHIFT_VER={product-version}
 RUN dnf config-manager \
-        --set-enabled rhocp-${USHIFT_VER}-for-rhel-9-$(uname -m)-rpms \
-        --set-enabled fast-datapath-for-rhel-9-$(uname -m)-rpms
+        --set-enabled rhocp-${USHIFT_VER}-for-rhel-{op-system-version-major}-$(uname -m)-rpms \
+        --set-enabled fast-datapath-for-rhel-{op-system-version-major}-$(uname -m)-rpms
 RUN dnf install -y firewalld microshift && \
     systemctl enable microshift && \
     dnf clean all
@@ -71,31 +72,48 @@ RUN systemctl enable microshift-make-rshared.service
 Podman uses the host subscription information and repositories inside the container when building the container image. If the `rhocp` and `fast-datapath` repositories are not available on the host, the build fails.
 ====
 
-. Create a local bootc image by running the following image build command:
+. Set the `PULL_SECRET` environment variable:
 +
 [source,terminal]
 ----
 PULL_SECRET=~/.pull-secret.json
-USER_PASSWD=<your_redhat_user_password> # <1>
-IMAGE_NAME=microshift-4.17-bootc
+----
+
+. Configure the `USER_PASSWD` environment variable:
++
+[source,terminal,subs="+quotes"]
+----
+USER_PASSWD=_<redhat_user_password>_ <1>
+----
+<1> Replace _<redhat_user_password>_ with your password.
 
+. Configure the `IMAGE_NAME` environment variable:
++
+[source,terminal,subs="attributes+"]
+----
+IMAGE_NAME=microshift-{product-version}-bootc
+----
+
+. Create a local bootc image by running the following image build command:
++
+[source,terminal,subs="+quotes"]
+----
 $ sudo podman build --authfile "${PULL_SECRET}" -t "${IMAGE_NAME}" \
     --build-arg USER_PASSWD="${USER_PASSWD}" \
     -f Containerfile
 ----
-<1> Replace _<your_redhat_user_password>_ with your password.
 +
 [NOTE]
 ====
 How secrets are used during the image build:
 
-* The podman `--authfile` argument is required to pull the base `rhel-bootc:9.4` image from the `registry.redhat.io` registry.
+* The podman `--authfile` argument is required to pull the base `rhel-bootc:{op-system-version}` image from the `registry.redhat.io` registry.
 * The build `USER_PASSWD` argument is used to set a password for the `redhat` user.
 ====
 
 .Verification
 
-. Verify that the local {microshift} bootc image was created by running the following command:
+. Verify that the local {microshift-short} bootc image was created by running the following command:
 +
 [source,terminal]
 ----
@@ -103,8 +121,8 @@ $ sudo podman images "${IMAGE_NAME}"
 ----
 +
 .Example output
-[source,text]
+[source,text,subs="attributes+"]
 ----
 REPOSITORY                       TAG         IMAGE ID      CREATED        SIZE
-localhost/microshift-4.17-bootc  latest      193425283c00  2 minutes ago  2.31 GB
+localhost/microshift-{product-version}-bootc  latest      193425283c00  2 minutes ago  2.31 GB
 ----
diff --git a/modules/microshift-install-rhel-image-mode-conc.adoc b/modules/microshift-install-bootc-conc.adoc
similarity index 58%
rename from modules/microshift-install-rhel-image-mode-conc.adoc
rename to modules/microshift-install-bootc-conc.adoc
index d91384fd1fb7..3dd6e145f9b5 100644
--- a/modules/microshift-install-rhel-image-mode-conc.adoc
+++ b/modules/microshift-install-bootc-conc.adoc
@@ -1,10 +1,10 @@
 // Module included in the following assemblies:
 //
-// microshift_install_bootc/microshift-install-rhel-image-mode.adoc
+// microshift_install_bootc/microshift-about-rhel-image-mode
 
 :_mod-docs-content-type: CONCEPT
-[id="microshift-rhel-image-mode-conc_{context}"]
-= Image mode for {op-system-base-full}
+[id="microshift-bootc-conc_{context}"]
+= About image mode for {op-system-base-full}
 
 Image mode for {op-system-base-full} is a Technology Preview deployment method that uses a container-native approach to build, deploy, and manage the operating system as a bootc image. By using bootc, you can build, deploy, and manage the operating system as if it is any other container.
 
@@ -17,23 +17,3 @@ Image mode splits the creation and installation of software changes into two ste
 * In the build-system step, a Podman build inspects the RPM files available for installation, determines any dependencies, and creates an ordered list of chained steps to complete, with the end result being a new operating system available to install.
 
 * In the running-target-system step, a bootc update downloads, unpacks, and makes the new operating system bootable alongside the currently running system. Local configuration changes are carried forward to the new operating system, but do not take effect until the system is rebooted and the new operating system image replaces the running image.
-
-[id="microshift-install-rhel-image-mode-conc_{context}"]
-== Using image mode for {op-system-base} with {microshift-short}
-
-To use image mode for {op-system-base}, ensure that the following resources are available:
-
-* A {op-system-base} 9.4 host with an active Red Hat subscription for building {microshift-short} bootc images.
-* A remote registry for storing and accessing bootc images.
-* You can use image mode for RHEL with a {microshift-short} cluster on AArch64 or x86_64 system architectures.
-
-The workflow for using image mode with {microshift-short} includes the following steps:
-
-. Build the {microshift-short} bootc image.
-. Publish the image.
-. Run the image. This step includes configuring {microshift-short} networking and storage.
-
-[IMPORTANT]
-====
-The `rpm-ostree` file system is not supported in image mode and must not be used to make changes to deployments that use image mode.
-====
diff --git a/modules/microshift-install-bootc-creating-vm.adoc b/modules/microshift-install-bootc-creating-vm.adoc
new file mode 100644
index 000000000000..0eb6942f94c0
--- /dev/null
+++ b/modules/microshift-install-bootc-creating-vm.adoc
@@ -0,0 +1,81 @@
+// Module included in the following assemblies:
+//
+// microshift_install_bootc/microshift-install-running-bootc-image-in-VM.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-install-bootc-creating-vm_{context}"]
+= Creating a virtual machine
+
+You can create a virtual machine by using the {op-system-base-full} boot ISO image.
+
+.Prerequisites
+
+* You created the Kickstart file.
+
+* You installed the {oc-first}.
+
+* You have `redhat` credentials.
+
+.Procedure
+
+. Download the {op-system-base-full} boot ISO image from the link:https://developers.redhat.com/products/rhel/download[Download Red{nbsp}Hat Enterprise Linux].
+
+. Copy the downloaded file to the `/var/lib/libvirt/images` directory.
+
+. Use your values to configure the following environment variables:
++
+[source,terminal,subs="attributes+"]
+----
+VMNAME=microshift-{product-version}-bootc
+NETNAME=default
+----
+
+. Create a {op-system-base-full} virtual machine with 2 cores, 2GB of RAM and 20GB of storage by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo virt-install \
+    --name ${VMNAME} \
+    --vcpus 2 \
+    --memory 2048 \
+    --disk path=/var/lib/libvirt/images/${VMNAME}.qcow2,size=20 \
+    --network network=${NETNAME},model=virtio \
+    --events on_reboot=restart \
+    --location /var/lib/libvirt/images/rhel-{op-system-version}-$(uname -m)-boot.iso \
+    --initrd-inject kickstart.ks \
+    --extra-args "inst.ks=file://kickstart.ks" \
+    --wait
+----
++
+[NOTE]
+====
+The `sudo virt-install` command uses the Kickstart file to pull a bootc image from the remote registry and install the {op-system-base-full} operating system.
+====
+
+. Log in to the virtual machine by using your `redhat` credentials.
+
+.Verification
+
+. Verify that all the {microshift-short} pods are running without error, by running the following command:
++
+[source,terminal]
+----
+$ watch sudo oc get pods -A \
+    --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig
+----
++
+.Example output
+[source,text]
+----
+NAMESPACE                  NAME                                       READY   STATUS    RESTARTS      AGE
+kube-system                csi-snapshot-controller-7cfb9df49c-kc9dx   1/1     Running   0             31s
+kube-system                csi-snapshot-webhook-5c6b978878-jzk5r      1/1     Running   0             28s
+openshift-dns              dns-default-rpnlt                          2/2     Running   0             14s
+openshift-dns              node-resolver-rxvdk                        1/1     Running   0             31s
+openshift-ingress          router-default-69cd7b5545-7zcw7            1/1     Running   0             29s
+openshift-ovn-kubernetes   ovnkube-master-c7hlh                       4/4     Running   1 (16s ago)   31s
+openshift-ovn-kubernetes   ovnkube-node-mkpht                         1/1     Running   1 (17s ago)   31s
+openshift-service-ca       service-ca-5d5d96459d-5pd5s                1/1     Running   0             28s
+openshift-storage          topolvm-controller-677cbfcdb9-28dqr        5/5     Running   0             31s
+openshift-storage          topolvm-node-6fzbl                         3/3     Running   0             14s
+----
\ No newline at end of file
diff --git a/modules/microshift-install-bootc-get-published-image.adoc b/modules/microshift-install-bootc-get-published-image.adoc
new file mode 100644
index 000000000000..e007a2cf5586
--- /dev/null
+++ b/modules/microshift-install-bootc-get-published-image.adoc
@@ -0,0 +1,41 @@
+// Module included in the following assemblies:
+//
+// microshift_install_bootc/microshift-install-rhel-bootc-image.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-install-bootc-get-published-image_{context}"]
+= Getting the published bootc image for {microshift-short}
+
+You can find and use the {microshift-short} container images to install {op-system-base-full}.
+
+.Prerequisites
+
+* You have an x86_64 or AArch64 platform.
+
+* You have access to the `registry.redhat.io` registry.
+
+.Procedure
+
+. Navigate to the link:https://catalog.redhat.com/[Red{nbsp}Hat Ecosystem Catalog].
+
+. Search for the {microshift-short} container image by using the `microshift-bootc` keyword.
+
+. Open the container image page of the {microshift-short} container image.
+
+. See the `Overview` and `Technical Information` tabs to get more details about the image.
+
+. Select the `Get this image` tab to view instructions for downloading the image.
+
+. Get access to the latest image on x86_64 and AArch64 platforms by logging into the registry using the following command:
++
+[source,terminal]
+----
+$ sudo podman login registry.redhat.io
+----
+
+. Download the bootc image by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ podman pull registry.redhat.io/openshift4/microshift-bootc-rhel{op-system-version-major}:v{product-version}
+----
diff --git a/modules/microshift-install-bootc-prepare-kickstart.adoc b/modules/microshift-install-bootc-prepare-kickstart.adoc
new file mode 100644
index 000000000000..19a35e119788
--- /dev/null
+++ b/modules/microshift-install-bootc-prepare-kickstart.adoc
@@ -0,0 +1,92 @@
+// Module included in the following assemblies:
+//
+// microshift_install_bootc/microshift-install-running-bootc-image-in-VM.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-install-bootc-prepare-kickstart_{context}"]
+= Creating the Kickstart file
+
+You must create the Kickstart file to use during installation.
+
+.Prerequisites
+
+* You have root-user access.
+* You are logged in to the physical hypervisor host.
+
+.Procedure
+
+. Set the `AUTH_CONFIG` environment variable to reference the secret file in the `kickstart.ks` file to authenticate private container registry access by running the following command:
++
+[source,terminal]
+----
+$ AUTH_CONFIG=~/.quay-auth.json
+----
+
+. Set the `PULL_SECRET` environment variable to reference the secret files in the `kickstart.ks` file to authenticate the {OCP} registry access by running the following command:
++
+[source,terminal]
+----
+$ PULL_SECRET=~/.pull-secret.json
+----
+
+. Set the `IMAGE_REF` environment variable to reference the image mode for your container image to use during installation by running the following command:
++
+[source,terminal,subs="attributes+,quotes"]
+----
+$ IMAGE_REF="quay.io/_<myorg>/<mypath>_/microshift-{product-version}-bootc" <1>
+----
+<1> Replace _<myorg/<mypath>_ with your remote registry organization name and path.
+
+. Create the `kickstart.ks` file to use during installation by running the following script:
++
+[source,terminal]
+----
+$ cat > kickstart.ks <<EOFKS
+lang en_US.UTF-8
+keyboard us
+timezone UTC
+text
+reboot
+
+# Partition the disk with hardware-specific boot and swap partitions, adding an
+# LVM volume that contains a 10GB+ system root. The remainder of the volume will
+# be used by the CSI driver for storing data.
+zerombr
+clearpart --all --initlabel
+# Create boot and swap partitions as required by the current hardware platform
+reqpart --add-boot
+# Add an LVM volume group and allocate a system root logical volume
+part pv.01 --grow
+volgroup rhel pv.01
+logvol / --vgname=rhel --fstype=xfs --size=10240 --name=root
+
+# Lock root user account
+rootpw --lock
+
+# Configure network to use DHCP and activate on boot
+network --bootproto=dhcp --device=link --activate --onboot=on
+
+%pre-install --log=/dev/console --erroronfail
+
+# Create a 'bootc' image registry authentication file
+mkdir -p /etc/ostree
+cat > /etc/ostree/auth.json <<'EOF'
+$(cat "${AUTH_CONFIG}")
+EOF
+
+%end
+
+# Pull a 'bootc' image from a remote registry
+ostreecontainer --url "${IMAGE_REF}"
+
+%post --log=/dev/console --erroronfail
+
+# Create an OpenShift pull secret file
+cat > /etc/crio/openshift-pull-secret <<'EOF'
+$(cat "${PULL_SECRET}")
+EOF
+chmod 600 /etc/crio/openshift-pull-secret
+
+%end
+EOFKS
+----
diff --git a/modules/microshift-install-rhel-image-mode-publish-image.adoc b/modules/microshift-install-bootc-publish-image.adoc
similarity index 57%
rename from modules/microshift-install-rhel-image-mode-publish-image.adoc
rename to modules/microshift-install-bootc-publish-image.adoc
index 0ac51b1579bf..68f1fa7f26b6 100644
--- a/modules/microshift-install-rhel-image-mode-publish-image.adoc
+++ b/modules/microshift-install-bootc-publish-image.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// microshift_install_bootc/microshift-install-rhel-image-mode.adoc
+// microshift_install_bootc/microshift-install-rhel-bootc-image.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-rhel-image-mode-publish-image_{context}"]
+[id="microshift-bootc-publish-image_{context}"]
 = Publishing the bootc image to the remote registry
 
 Publish your bootc image to the remote registry so that the image can be used for running the container on another host, or for when you want to install a new operating system with the bootc image layer.
@@ -16,27 +16,43 @@ Publish your bootc image to the remote registry so that the image can be used fo
 
 .Procedure
 
+. Set the `REGISTRY_URL` variable for the image by running the following command:
++
+[source,terminal,subs="+quotes"]
+----
+$ REGISTRY_URL=_<quay.io>_ # <1>
+----
+<1> Replace _<quay.io>_ with the URL for your image registry.
+
 . Log in to your remote registry by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
+----
+$ sudo podman login "${REGISTRY_URL}"
 ----
-REGISTRY_URL=quay.io
 
-$ sudo podman login "${REGISTRY_URL}" # <1>
+. Set the `IMAGE_NAME` variable for the image by running the following command:
++
+[source,terminal,subs="attributes+,quotes"]
+----
+$ IMAGE_NAME=_<microshift-{product-version}-bootc>_ # <1>
 ----
-<1> Replace _REGISTRY_URL_ with the URL for your registry.
+<1> Replace _<microshift-{product-version}-bootc>_ with the name of the image you want to publish.
+
+. Set the `REGISTRY_IMG` variable for the image by running the following command:
++
+[source,terminal,subs="+quotes"]
+----
+$ REGISTRY_IMG=_<myorg/mypath>_/"${IMAGE_NAME}" # <1>
+----
+<1> Replace _<myorg/mypath>_ with your remote registry organization name and path.
 
 . Publish the image by running the following command:
 +
 [source,terminal]
 ----
-REGISTRY_IMG=<myorg/mypath>/"${IMAGE_NAME}" # <1> <2>
-IMAGE_NAME=<microshift-4.17-bootc> # <3>
-
 $ sudo podman push localhost/"${IMAGE_NAME}" "${REGISTRY_URL}/${REGISTRY_IMG}"
 ----
-<1> Replace _<myorg/mypath>_ with your remote registry organization name and path.
-<2> Replace _<microshift-4.17-bootc>_ with the name of the image you want to publish.
 
 .Verification
 
diff --git a/modules/microshift-install-bootc-workflow.adoc b/modules/microshift-install-bootc-workflow.adoc
new file mode 100644
index 000000000000..b5f424786875
--- /dev/null
+++ b/modules/microshift-install-bootc-workflow.adoc
@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// microshift_install_bootc/microshift-about-rhel-image-mode
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-install-rhel-image-mode-conc_{context}"]
+= The image mode for {op-system-base} with {microshift-short} workflow
+
+To use image mode for {op-system-base}, ensure that the following resources are available:
+
+* A {op-system-base} {op-system-version} host with an active Red{nbsp}Hat subscription for building {microshift-short} bootc images.
+* A remote registry for storing and accessing bootc images.
+* You can use image mode for RHEL with a {microshift-short} cluster on AArch64 or x86_64 system architectures.
+
+The workflow for using image mode with {microshift-short} includes the following steps:
+
+. Find and use a prebuilt {microshift-short} container image to install {op-system-base-full}.
+. Build a custom {microshift-short} container image if the prebuilt {microshift-short} container image requires customization.
+. Run the container image.
+
+[IMPORTANT]
+====
+The `rpm-ostree` file system is not supported in image mode. Do not use the `rpm-ostree` file system to modify deployments that use image mode.
+====
diff --git a/modules/microshift-install-rpms.adoc b/modules/microshift-install-rpms.adoc
index 13f25a9182f6..2a9900dd5481 100644
--- a/modules/microshift-install-rpms.adoc
+++ b/modules/microshift-install-rpms.adoc
@@ -15,13 +15,29 @@ Use the following procedure to install {microshift-short} from an RPM package.
 
 .Procedure
 
-. As a root user, enable the {microshift-short} repositories by running the following command:
+. For all lifecycles, enable the repository for your release by running the following command:
 +
 [source,terminal,subs="attributes+"]
 ----
 $ sudo subscription-manager repos \
-    --enable rhocp-{ocp-version}-for-{rhel-major}-$(uname -m)-rpms \
-    --enable fast-datapath-for-{rhel-major}-$(uname -m)-rpms
+    --enable rhocp-{ocp-version}-for-rhel-{op-system-version-major}-$(uname -m)-rpms \
+    --enable fast-datapath-for-rhel-{op-system-version-major}-$(uname -m)-rpms
+----
+
+. For extended support (EUS) releases, also enable the EUS repositories by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo subscription-manager repos \
+    --enable rhel-{op-system-version-major}-for-$(uname -m)-appstream-eus-rpms \
+    --enable rhel-{op-system-version-major}-for-$(uname -m)-baseos-eus-rpms
+----
+
+. Avoid unintended future updates into an unsupported configuration by locking your operating system version with the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ sudo subscription-manager release --set={op-system-version}
 ----
 
 . Install {microshift-short} by running the following command:
@@ -71,4 +87,4 @@ $ sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1
 $ sudo firewall-cmd --reload
 ----
 
-If the Volume Group (VG) that you have prepared for {microshift-short} used the default name `rhel`, no further configuration is necessary. If you have used a different name, or if you want to change more configuration settings, see the Configuring {microshift-short} section.
+. If the Volume Group (VG) that you have prepared for {microshift-short} used the default name `rhel`, no further configuration is necessary. If you have used a different name, or if you want to change more configuration settings, see the "Using the {microshift-short} configuration file" section.
diff --git a/modules/microshift-kickstart-bootc-install.adoc b/modules/microshift-kickstart-bootc-install.adoc
new file mode 100644
index 000000000000..3d36ddc94618
--- /dev/null
+++ b/modules/microshift-kickstart-bootc-install.adoc
@@ -0,0 +1,55 @@
+// Module included in the following assemblies:
+//
+// microshift/microshift-.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-kickstart-bootc-install_{context}"]
+= Creating a Kickstart file for installing {microshift-short} on image mode for RHEL
+
+You can use the Kickstart file provided with {microshift-short} for an image mode for RHEL installation.
+
+.Prerequisites
+
+* You set up the {microshift-short} Kickstart file.
+* You have the information needed to set required and optional variables.
+
+.Procedure
+
+. Set the required `BOOTC_IMAGE_URL` variable value to point to an image used in the RHEL Kickstart file installation process by running the following command:
++
+[source,terminal,subs="+quotes"]
+----
+$ export BOOTC_IMAGE_URL=_<myregistry>/<myorg>/<mypath>_/microshift-image:tag # <1>
+----
+<1> Replace _<myregistry>_,_<myorg>_, and _<mypath>_ with your information.
+
+* The `BOOTC_IMAGE_URL` variable contains a reference to the image that is installed with the `ostreecontainer` command. You can specify a z-stream release other than the latest by using the tag if required.
+
+. Optional. Add variables and values for registry authentication and configuration by using the following commands:
++
+.Example commands setting optional variables
++
+* Set the `AUTH_CONFIG` variable to authenticate access to the `BOOTC_IMAGE_URL` image by running the following command:
++
+[source,terminal]
+----
+$ export AUTH_CONFIG="$(cat ~/.quay-auth.json)" # <1>
+----
+<1> See the `containers-auth.json(5)` manual page for more information about this file format.
++
+* Set the `REGISTRY_CONFIG` variable to configure access to the registry containing the `BOOTC_IMAGE_URL` image by running the following command:
++
+[source,terminal]
+----
+$ export REGISTRY_CONFIG="$(cat ~/.quay-config.conf)" # <1>
+----
+<1> See the `containers-registries.conf(5)` manual page for more information about this file format.
+
+. Create the `kickstart.ks` file to be used during the installation by running the following command:
++
+[source,terminal]
+----
+envsubst < \
+    /usr/share/microshift/kickstart/kickstart-bootc.ks.template > \
+    "${HOME}/kickstart.ks"
+----
diff --git a/modules/microshift-kickstart-ostree-install.adoc b/modules/microshift-kickstart-ostree-install.adoc
new file mode 100644
index 000000000000..b129e1b2aef6
--- /dev/null
+++ b/modules/microshift-kickstart-ostree-install.adoc
@@ -0,0 +1,59 @@
+// Module included in the following assemblies:
+//
+// microshift/microshift-.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-kickstart-ostree-install_{context}"]
+= Creating a Kickstart file for a {microshift-short} {op-system-ostree} installation
+
+Use the Kickstart file provided with {microshift-short} to provision a {op-system-ostree}-based virtual machine.
+
+.Prerequisites
+
+* You set up the {microshift-short} Kickstart file.
+* You have the information needed to set required and optional variables.
+
+.Procedure
+
+. Add the following required variables to create an {op-system-ostree} Kickstart file:
++
+.Example commands setting required variables.
++
+* The `OSTREE_SERVER_URL` variable contains an `rpm-ostree` server URL that is passed to the `ostreesetup` Kickstart command.
++
+[source,terminal,subs="+quotes"]
+----
+$ export OSTREE_SERVER_URL="_<http://my_ostree_server_url>_" # <1>
+----
+<1> Replace _<http://my_ostree_server_url>_ with your server URL.
++
+* The `OSTREE_COMMIT_REF` variable contains an `rpm-ostree` commit reference that is installed from the server.
++
+[source,terminal,subs="+quotes"]
+----
+$ export OSTREE_COMMIT_REF="_<myostree_commit_reference>_" # <1>
+----
+<1> Replace _<myostree_commit_reference>_ with the `rpm-ostree` commit reference.
+
+. Optional. Add the following variable for server authentication:
++
+* The `AUTH_CONFIG` contents are copied to `/etc/ostree/auth.json` at the pre-install stage to authenticate access to the `OSTREE_SERVER_URL` server. If no server authentication is required, skip this setting.
++
+[source,terminal]
+----
+$ export AUTH_CONFIG="$(cat ~/.ostree-auth.json)"
+----
+
+. Run the following command to create the `kickstart.ks` file to be used during the installation:
++
+[source,terminal]
+----
+envsubst < \
+    /usr/share/microshift/kickstart/kickstart-ostree.ks.template > \
+    "${HOME}/kickstart.ks"
+----
+
+[NOTE]
+====
+The {microshift-short} version specified in the `rpm-ostree` commit is installed. To change the version of {microshift-short}, you must create a new commit.
+====
\ No newline at end of file
diff --git a/modules/microshift-kickstart-prep.adoc b/modules/microshift-kickstart-prep.adoc
new file mode 100644
index 000000000000..37e70958def1
--- /dev/null
+++ b/modules/microshift-kickstart-prep.adoc
@@ -0,0 +1,64 @@
+// Module included in the following assemblies:
+//
+// microshift/microshift-kickstart-prep.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-kickstart-prep_{context}"]
+= Setting up the {microshift-short} Kickstart file
+
+You can use the Kickstart file provided with {microshift-short} to provision a host by following the instructions for your install type. The ISO you created in the previous steps then runs on the host that you provision with your Kickstart file. To get started with the {microshift-short} Kickstart file, begin with the following procedure.
+
+.Prerequisites
+
+* The host you are provisioning must meet the system requirements for installing {microshift-short}.
+* A pull secret from `~/.pull-secret.json` must be present and have read permissions for the current user.
+
+.Procedure
+
+. Install the `microshift-release-info` RPM package containing the sample Kickstart files that are in the `/usr/share/microshift/kickstart` directory by running the following command:
++
+[source,terminal]
+----
+$ sudo dnf install -y microshift-release-info
+----
+
+. Install the utilities used during the Kickstart file creation by running the following command:
++
+[source,terminal]
+----
+$ sudo dnf install -y openssl gettext
+----
+
+. Set the variables pointing to secrets included in `kickstart.ks`.
+
+* The `PULL_SECRET` file contents are copied to the `/etc/crio/openshift-pull-secret` directory at the post-installation stage to authenticate {ocp} container registry access.
++
+.Example command setting the `PULL_SECRET` variable:
+[source,terminal]
+----
+$ export PULL_SECRET="$(cat ~/.pull-secret.json)"
+----
+
+* Set a password in the `PASSWD_TEXT` variable to use in the`USER_PASSWD` setting by running the following command:
++
+.Example command setting the `PASSWD_TEXT` variable.
+[source,terminal,subs="+quotes"]
+----
+$ PASSWD_TEXT=_<redhat_user_plain_text_password>_ <1>
+----
+<1> Replace _<redhat_user_plain_text_password>_ with the password you want to use.
+
+* The `USER_PASSWD` setting is used as an encrypted password for the `redhat` user for logging into the host. Encrypt your password string using the SHA-512 encryption standard.
++
+.Example command setting the `USER_PASSWD` variable.
+[source,terminal]
+----
+$ export USER_PASSWD="$(openssl passwd -6 "${PASSWD_TEXT}")"  # <1>
+----
+<1> Only the encrypted password is included in the Kickstart file. The plain text password is not.
+
+.Next steps
+
+* Follow the instructions for your installation type to create a working Kickstart file from the provided template. Instructions for RPM-based, {op-system-ostree}, and {op-system-image} installations follow this procedure.
+
+* Optional. Create a virtual machine (VM) using the Kickstart file. Creating a VM allows you to test and validate the values in your Kickstart file.
diff --git a/modules/microshift-kickstart-rpm-install.adoc b/modules/microshift-kickstart-rpm-install.adoc
new file mode 100644
index 000000000000..5ee1519723ff
--- /dev/null
+++ b/modules/microshift-kickstart-rpm-install.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// microshift/microshift-kickstart-prep.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-kickstart-rpm-install_{context}"]
+= Creating a Kickstart file for a {microshift-short} RPM installation
+
+Use the Kickstart file provided with {microshift-short} to provision an RPM-based virtual machine.
+
+.Prerequisites
+
+* You set up the {microshift-short} Kickstart file.
+* You know the link:https://console.redhat.com/insights/connector/activation-keys[Activation Keys] and organization ID to activate your Red{nbsp}Hat subscription.
+* You have the information needed to set the `BOOTC_IMAGE_URL`, `AUTH_CONFIG`, and `REGISTRY_CONFIG` required variables.
+
+[IMPORTANT]
+====
+The subscription must include access to the `rhocp-4.x-for-rhel-{op-system-version-major}-$(uname -m)-rpms` and `fast-datapath-for-rhel-{op-system-version-major}-$(uname -m)-rpms` RPM repositories.
+====
+
+.Procedure
+
+. Add the following variables to create an RPM Kickstart file:
++
+.Example commands setting the Kickstart file variables.
++
+* The `RHSM_ORG` variable contains a Red{nbsp}Hat Subscription Manager organization ID for the subscription registration command in the Kickstart file.
++
+[source,terminal]
+----
+$ export RHSM_ORG="$(cat ~/.rhsm-activation-org)"
+----
++
+* The `RHSM_KEY` variable contains a Red{nbsp}Hat Subscription Manager activation key for the subscription registration command in the Kickstart file.
++
+[source,terminal]
+----
+$ export RHSM_KEY="$(cat ~/.rhsm-activation-key)"
+----
++
+* The `MICROSHIFT_VER` variable references the {microshift-short} version to install using the `4.y` format. The latest available `.z` version of the `4.y` version set in this variable is automatically installed.
++
+[source,terminal]
+----
+$ export MICROSHIFT_VER={product-version} # <1>
+----
+<1> The latest `.z` of the minor version that you set is installed.
+
+. Run the following command to create the `kickstart.ks` file to be used during the virtual machine installation:
++
+[source,terminal]
+----
+envsubst < \
+    /usr/share/microshift/kickstart/kickstart-rpm.ks.template > \
+    "${HOME}/kickstart.ks"
+----
diff --git a/modules/microshift-low-latency-config-yaml.adoc b/modules/microshift-low-latency-config-yaml.adoc
index a99d95043f67..657ba9ebb42f 100644
--- a/modules/microshift-low-latency-config-yaml.adoc
+++ b/modules/microshift-low-latency-config-yaml.adoc
@@ -44,7 +44,7 @@ kubelet: <1>
     memory.available: "100Mi" # <9>
     nodefs.available: "10%" # <10>
     nodefs.inodesFree: "5%" # <11>
-  evictionPressureTransitionPeriod: 0s
+  evictionPressureTransitionPeriod: 5m <12>
 # ...
 ----
 <1> If you change the CPU or memory managers in the kubelet configuration, you must remove files that cache the previous configuration. Restart the host to remove them automatically, or manually remove the `/var/lib/kubelet/cpu_manager_state` and `/var/lib/kubelet/memory_manager_state` files.
@@ -58,6 +58,7 @@ kubelet: <1>
 <9> In this example, the `evictionHard.memory.available` parameter means that the pods are evicted when the available memory of the node drops below 100MiB.
 <10> In this example, the `evictionHard.nodefs.available` parameter means that the pods are evicted when the main filesystem of the node has less than 10% available space.
 <11> In this example, the `evictionHard.nodefs.inodesFree` parameter means that the pods are evicted when more than 15% of the node's main filesystem's inodes are in use.
+<12> For container garbage collection: The duration to wait before transitioning out of an eviction pressure condition. Setting the `evictionPressureTransitionPeriod` parameter to `0` configures the default value of 5 minutes.
 
 .Verification
 
@@ -68,4 +69,4 @@ kubelet: <1>
 . Tune your operating system. For example, configure and activate a TuneD profile.
 . Optional: Configure automatic enablement of your TuneD profile.
 . Optional: If you are using the x86_64 architecture, you can install {op-system-rt-kernel}.
-. Prepare your {microshift-short} workloads for low latency.
\ No newline at end of file
+. Prepare your {microshift-short} workloads for low latency.
diff --git a/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc b/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc
index 7670ce3e1133..64ed2ba54adc 100644
--- a/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc
+++ b/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc
@@ -60,7 +60,7 @@ kubelet:
     memory.available: 100Mi
     nodefs.available: 10%
     nodefs.inodesFree: 5%
-  evictionPressureTransitionPeriod: 0s
+  evictionPressureTransitionPeriod: 5m
 """
 
 [[customizations.files]]
@@ -88,4 +88,4 @@ reboot_after_apply: True
 . Complete the image building process.
 . If you have not completed the previous steps for enabling low latency for your {microshift-short} cluster, do so now. Update the blueprint with the information gathered in those steps.
 . If you have not configured workload partitioning, do so now.
-. Prepare your {microshift-short} workloads for low latency.
\ No newline at end of file
+. Prepare your {microshift-short} workloads for low latency.
diff --git a/modules/microshift-low-latency-rhel-edge-blueprint-rtk.adoc b/modules/microshift-low-latency-rhel-edge-blueprint-rtk.adoc
index 30a8555c0729..9264f3a2d7e4 100644
--- a/modules/microshift-low-latency-rhel-edge-blueprint-rtk.adoc
+++ b/modules/microshift-low-latency-rhel-edge-blueprint-rtk.adoc
@@ -79,7 +79,7 @@ kubelet:
     memory.available: 100Mi
     nodefs.available: 10%
     nodefs.inodesFree: 5%
-  evictionPressureTransitionPeriod: 0s
+  evictionPressureTransitionPeriod: 5m
 """
 
 [[customizations.files]]
@@ -101,4 +101,4 @@ data = """
 profile: microshift-baseline
 reboot_after_apply: True
 """
-----
\ No newline at end of file
+----
diff --git a/modules/microshift-mirror-container-images.adoc b/modules/microshift-mirror-container-images.adoc
index 4c0ad71230f5..7c2418784246 100644
--- a/modules/microshift-mirror-container-images.adoc
+++ b/modules/microshift-mirror-container-images.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="microshift-mirror-container-images_{context}"]
diff --git a/modules/microshift-mirroring-prereqs.adoc b/modules/microshift-mirroring-prereqs.adoc
index 12e9d925e239..6ce9aed5150f 100644
--- a/modules/microshift-mirroring-prereqs.adoc
+++ b/modules/microshift-mirroring-prereqs.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/microshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="microshift-configuring-mirroring-prereqs_{context}"]
diff --git a/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc b/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc
index 509634f5f9eb..4fbfc4a22b4e 100644
--- a/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc
+++ b/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc
@@ -106,7 +106,6 @@ $ oc get pod -A -o wide
 ----
 NAMESPACE                  NAME                                      READY   STATUS    RESTARTS        AGE     IP                NODE           NOMINATED NODE   READINESS GATES
 kube-system                csi-snapshot-controller-bb7cb654b-7s5ql   1/1     Running   0               46m     10.42.0.6         microshift-9   <none>           <none>
-kube-system                csi-snapshot-webhook-95f475949-jrqv8      1/1     Running   0               46m     10.42.0.4         microshift-9   <none>           <none>
 openshift-dns              dns-default-zxkqn                         2/2     Running   0               46m     10.42.0.5         microshift-9   <none>           <none>
 openshift-dns              node-resolver-r2h5z                       1/1     Running   0               46m     192.168.113.117   microshift-9   <none>           <none>
 openshift-ingress          router-default-5b75594b4-228z7            1/1     Running   0               2m5s    10.42.0.3         microshift-9   <none>           <none>
diff --git a/modules/microshift-nw-ipv6-single-stack-config.adoc b/modules/microshift-nw-ipv6-single-stack-config.adoc
index bf924e03f589..80bb3b12a06d 100644
--- a/modules/microshift-nw-ipv6-single-stack-config.adoc
+++ b/modules/microshift-nw-ipv6-single-stack-config.adoc
@@ -81,7 +81,6 @@ $ oc get pod -A -o wide
 ----
 NAMESPACE                  NAME                                      READY   STATUS    RESTARTS   AGE   IP                      NODE           NOMINATED NODE   READINESS GATES
 kube-system                csi-snapshot-controller-bb7cb654b-rqrt6   1/1     Running   0          65s   fd01:0:0:1::5           microshift-9   <none>           <none>
-kube-system                csi-snapshot-webhook-95f475949-nbz8x      1/1     Running   0          61s   fd01:0:0:1::6           microshift-9   <none>           <none>
 openshift-dns              dns-default-cjn66                         2/2     Running   0          62s   fd01:0:0:1::9           microshift-9   <none>           <none>
 openshift-dns              node-resolver-ppnjb                       1/1     Running   0          63s   2001:db9:ca7:ff::1db8   microshift-9   <none>           <none>
 openshift-ingress          router-default-6d97d7b8b6-wdtmg           1/1     Running   0          61s   fd01:0:0:1::8           microshift-9   <none>           <none>
@@ -100,11 +99,10 @@ $ oc get svc -A
 ----
 +
 .Example output
-[source,terminal]
+[source,text]
 ----
 NAMESPACE           NAME                            TYPE           CLUSTER-IP   EXTERNAL-IP                                             PORT(S)                      AGE
 default             kubernetes                      ClusterIP      fd02::1      <none>                                                  443/TCP                      3m42s
-kube-system         csi-snapshot-webhook            ClusterIP      fd02::4c4f   <none>                                                  443/TCP                      3m20s
 openshift-dns       dns-default                     ClusterIP      fd02::a      <none>                                                  53/UDP,53/TCP,9154/TCP       2m58s
 openshift-ingress   router-default                  LoadBalancer   fd02::f2e6   2001:db9:ca7:ff::1db8,fd01:0:0:1::2,fd02::1:0,fd69::2   80:31133/TCP,443:31996/TCP   2m58s
 openshift-ingress   router-internal-default         ClusterIP      fd02::c55e   <none>                                                  80/TCP,443/TCP,1936/TCP      2m58s
diff --git a/modules/microshift-oc-mirror-creating-imageset-config.adoc b/modules/microshift-oc-mirror-creating-imageset-config.adoc
index 14dca3d81582..c591d832578f 100644
--- a/modules/microshift-oc-mirror-creating-imageset-config.adoc
+++ b/modules/microshift-oc-mirror-creating-imageset-config.adoc
@@ -26,7 +26,7 @@ Do not delete or modify the metadata that is generated by the oc-mirror plugin.
 --
 [source,terminal]
 ----
-$ oc mirror init <--registry <storage_backend> > imageset-config.yaml <1>
+$ oc mirror init --registry <storage_backend> > imageset-config.yaml <1>
 ----
 <1> Specifies the location of your storage backend, such as `example.com/mirror/oc-mirror-metadata`.
 --
@@ -43,10 +43,10 @@ storageConfig:
 mirror:
   platform: # <1>
     channels:
-    - name: stable-4.18
+    - name: stable-4.19
       type: ocp
   operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18
+  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
     packages:
     - name: serverless-operator
       channels:
@@ -72,7 +72,7 @@ storageConfig: <1>
     skipTLS: false
 mirror:
   operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18 <3>
+  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19 <3>
     packages:
     - name: amq-broker-rhel8 <4>
       channels:
diff --git a/modules/microshift-opt-out-telemetry.adoc b/modules/microshift-opt-out-telemetry.adoc
new file mode 100644
index 000000000000..2d2f210fef19
--- /dev/null
+++ b/modules/microshift-opt-out-telemetry.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// microshift_support/microshift-remote-cluster-monitoring.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-opt-out-telemetry_{context}"]
+= Opting out of Telemetry for {microshift-short}
+
+If your cluster is not connected to a network, or you do not want Telemetry gathered, you can easily opt out of Telemetry by disabling the parameter in the {microshift-short} configuration file.
+
+.Prerequisties
+
+* You installed {oc-first}.
+* You have root access to the cluster.
+
+.Procedure
+
+. If you have not done so, make a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory, renaming it `config.yaml`.
+
+. Keep the new {microshift-short} `config.yaml` in the `/etc/microshift/` directory. Your `config.yaml` file is read every time the {microshift-short} service starts.
++
+[NOTE]
+====
+After you create it, the `config.yaml` file takes precedence over built-in settings.
+====
+
+. Optional: Use a configuration snippet if you are using an existing {microshift-short} YAML. See "Using configuration snippets" in the _Additional resources_ section for more information.
+
+. Set the `telemetry.status` section of the {microshift-short} YAML with the `Disabled` value.
++
+.Example disabled Telemetry configuration
+[source,yaml]
+----
+apiServer:
+# ...
+telemetry:
+    endpoint: https://infogw.api.openshift.com
+    status: Disabled
+# ...
+----
+
+//Should the user also delete the endpoint, or does that not matter?
\ No newline at end of file
diff --git a/modules/microshift-preparing-for-image-building.adoc b/modules/microshift-preparing-for-image-building.adoc
index 62fc7effb95a..7708b296287b 100644
--- a/modules/microshift-preparing-for-image-building.adoc
+++ b/modules/microshift-preparing-for-image-building.adoc
@@ -6,8 +6,12 @@
 [id="preparing-for-image-building_{context}"]
 = Preparing for image building
 
-Read link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images[Composing, installing, and managing RHEL for Edge images].
+Use the image builder tool to compose customized {op-system-ostree-first} images optimized for edge deployments. You can run a {microshift-short} cluster with your applications on a {op-system-ostree} virtual machine for development and testing first, then use your whole solution in edge production environments.
 
-To build an {op-system-ostree-first} {op-system-version} image for a given CPU architecture, you need a {op-system-base} {op-system-version} build host of the same CPU architecture that meets the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/setting-up-image-builder_composing-installing-managing-rhel-for-edge-images#edge-image-builder-system-requirements_setting-up-image-builder[Image builder system requirements].
+Use the following {op-system-base} documentation to understand the full details of using {op-system-ostree}:
 
-Follow the instructions in link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/setting-up-image-builder_composing-installing-managing-rhel-for-edge-images#edge-installing-image-builder_setting-up-image-builder[Installing image builder] to install image builder and the `composer-cli` tool.
+* Read link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/introducing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images[Introduction to RHEL for Edge images].
+
+* To build an {op-system-ostree-first} {op-system-version} image for a given CPU architecture, you need a {op-system-base} {op-system-version} build host of the same CPU architecture that meets the link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/setting-up-image-builder_composing-installing-managing-rhel-for-edge-images#edge-image-builder-system-requirements_setting-up-image-builder[Image builder system requirements].
+
+* Follow the instructions in link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/setting-up-image-builder_composing-installing-managing-rhel-for-edge-images#edge-installing-image-builder_setting-up-image-builder[Installing image builder] to install image builder and the `composer-cli` tool.
diff --git a/modules/microshift-restoring-backups.adoc b/modules/microshift-restoring-backups-auto-recovery.adoc
similarity index 82%
rename from modules/microshift-restoring-backups.adoc
rename to modules/microshift-restoring-backups-auto-recovery.adoc
index ab20009bae51..4d4a8247fbaa 100644
--- a/modules/microshift-restoring-backups.adoc
+++ b/modules/microshift-restoring-backups-auto-recovery.adoc
@@ -3,12 +3,10 @@
 // * microshift/microshift_backup_and_restore/microshift-auto-recover-manual-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="microshift-restoring-backups_{context}"]
+[id="microshift-restoring-backups-auto-recovery_{context}"]
 = Restoring backups using the auto-recovery feature
 
-You can restore backups after system events that remove or damage required data.
-
-Use the following procedure to restore backups.
+You can restore backups after system events that remove or damage required data. Use the following procedure to restore backups using automatic recovery. Automatic recovery selects the most recent backup and restores it. Previously restored backups that used automatic recovery are moved to your `PATH/restored` directory.
 
 .Prerequisites
 
@@ -16,10 +14,9 @@ Use the following procedure to restore backups.
 
 .Procedure
 
-* Restore the backup from the directory in which you have stored the backups by running the following command:
+. Restore the latest backup from your backups directory by running the following command:
 +
-[source,terminal]
-[subs="+quotes"]
+[source,terminal,subs="+quotes"]
 ----
 $ sudo microshift restore --auto-recovery _<path_of_directory>_ <1>
 ----
@@ -27,12 +24,12 @@ $ sudo microshift restore --auto-recovery _<path_of_directory>_ <1>
 +
 [NOTE]
 ====
-The `--auto-recovery` option copies the {microshift-short} data to `/var/lib/microshift-auto-recovery/failed/` for later investigation, selects the most recent backup, and restores it.
-The `--dont-save-failed` option disables the backing up of failed {microshift-short} data.
+* The `--auto-recovery` option copies the {microshift-short} data to `/var/lib/microshift-auto-recovery/failed/` for later investigation, selects the most recent backup, and restores it.
+
+* The `--dont-save-failed` option disables the backing up of failed {microshift-short} data.
 ====
 +
 .Example output
-+
 [source,terminal]
 ----
 ??? I1104 09:19:28.617225    8950 state.go:80] "Read state from the disk" state={"LastBackup":"20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"}
@@ -57,12 +54,24 @@ The `--dont-save-failed` option disables the backing up of failed {microshift-sh
 ??? I1104 09:19:28.662983    8950 restore.go:141] "Auto-recovery restore completed".
 ----
 +
-[NOTE]
+[IMPORTANT]
 ====
-* The `restore` command does not start {microshift-short} after restoration. When you execute this command, {microshift-short} service has already failed or you need to stop it.
-* {microshift-short} does not monitor the disk space of any filesystem. You need to ensure your automation handles old backup removal.
+* The `restore` command does not restart {microshift-short} after restoration. When you execute this command, {microshift-short} service has already failed or you stopped it.
+
+* {microshift-short} does not monitor the disk space of any filesystem. You must ensure that your automation handles old backup removal. For example, you can add this process to the auto-recovery service or add another service that runs periodically.
 ====
 
+. Restart {microshift-short} by running the following command:
++
+[source,terminal]
+----
+$ sudo systemctl restart microshift
+----
+
 .Verification
 
-* Verify that {microshift-short} has started successfully.
\ No newline at end of file
+* Verify that {microshift-short} has started successfully by running the following command:
++
+--
+include::snippets/microshift-healthy-pods-snip.adoc[leveloffset=+1]
+--
\ No newline at end of file
diff --git a/modules/microshift-rhel-kickstarts-con.adoc b/modules/microshift-rhel-kickstarts-con.adoc
new file mode 100644
index 000000000000..c40ae49ca639
--- /dev/null
+++ b/modules/microshift-rhel-kickstarts-con.adoc
@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// microshift/microshift-install-kickstarts.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-rhel-kickstart_{context}"]
+= Kickstart files for embedding {microshift-short} with a {op-system-base} installation
+
+By using a Kickstart file, you automate a typical {op-system-base-full} installation by creating a single file containing all of the information required for success.
+
+* You can also automate your {microshift-short} installation by including {microshift-short} in the Kickstart file for the {op-system-base} type that you choose.
+* You can use a Kickstart file to provision virtual machines (VMs) or to complete a regular {op-system-base} installation for deployment on edge devices.
+
+For {microshift-short}, your Kickstart file must include information to provision the {op-system-base} system to meet the following requirements:
+
+* A {op-system-base} system you provision must meet the requirements for installing {microshift-short}.
+* The {op-system-base} file system must have a logical volume manager (LVM) volume group (VG) with sufficient capacity for the persistent volumes (PVs) of your workload.
+* A pull secret from the https://console.redhat.com/openshift/install/pull-secret[Red Hat Hybrid Cloud Console] must be present as `/etc/crio/openshift-pull-secret` and have root user-only read/write permissions.
\ No newline at end of file
diff --git a/modules/microshift-storage-backup-volume-snapshots.adoc b/modules/microshift-storage-backup-volume-snapshots.adoc
index 9efadaeda3d6..f4a8a586a33a 100644
--- a/modules/microshift-storage-backup-volume-snapshots.adoc
+++ b/modules/microshift-storage-backup-volume-snapshots.adoc
@@ -21,22 +21,26 @@ To find specific snapshots and copy them, use the following procedure.
 +
 [source,terminal]
 ----
-$ oc get volumesnapshot -n <namespace> <snapshot_name> -o 'jsonpath={.status.volumeSnapshotContentName}'
+$ oc get volumesnapshot -n <namespace> <snapshot_name> -o 'jsonpath={.status.volumeSnapshotContentName}' # <1>
 ----
+<1> Replace _<namespace>_ and _<snapshot_name>_ with the namespace and snapshot name you used.
 
 . Get the unique identity of the volume created on the storage backend by using the following command and inserting the name retrieved in the previous step:
 +
 [source,terminal]
 ----
-$ oc get volumesnapshotcontent snapcontent-<retrieved_volume_identity> -o 'jsonpath={.status.snapshotHandle}'
+$ oc get volumesnapshotcontent snapcontent-<retrieved_volume_identity> -o 'jsonpath={.status.snapshotHandle}' # <1>
 ----
+<1> Replace _<retrieved_volume_identity>_ with the volume identity.
 
 . Display the snapshots by using the unique identity of the volume you retrieved in the previous step to determine which one you want to backup by running the following command:
 +
 [source,terminal]
 ----
-$ sudo lvdisplay <retrieved_snapshot_handle>
+$ sudo lvdisplay <retrieved_volume_identity> # <1>
 ----
+<1> Replace _<retrieved_volume_identity>_ with the volume identity.
+
 +
 .Example output
 [source,terminal]
@@ -73,12 +77,14 @@ $ sudo mkdir /mnt/snapshot
 +
 [source,terminal]
 ----
-$ sudo mount /dev/<retrieved_snapshot_handle> /mnt/snapshot
+$ sudo mount /dev/<retrieved_snapshot_handle> /mnt/snapshot # <1>
 ----
+<1> Replace _<retrieved_snapshot_handle>_ with the device name.
 
 . Copy the files from the mounted location and store them in a secure location by running the following command:
 +
 [source,terminal]
 ----
-$ sudo cp -r /mnt/snapshot <destination>
-----
\ No newline at end of file
+$ sudo cp -r /mnt/snapshot <destination> # <1>
+----
+<1> Replace _<destination>_ with the path to the secure location.
\ No newline at end of file
diff --git a/modules/microshift-tls-config-con.adoc b/modules/microshift-tls-config-con.adoc
new file mode 100644
index 000000000000..586313c53527
--- /dev/null
+++ b/modules/microshift-tls-config-con.adoc
@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// * microshift_configurig/microshift_tls-config.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-tls-config-con_{context}"]
+= Using TLS with {microshift-short}
+
+Transport layer security (TLS) profiles provide a way for servers to regulate which ciphers a client can use when connecting to the server. Using TLS helps to ensure that {microshift-short} applications use cryptographic libraries that do not allow known insecure protocols, ciphers, or algorithms. You can use either the TLS 1.2 or TLS 1.3 security profiles with {microshift-short}.
+
+{microshift-short} API server cipher suites apply automatically to the following internal control plane components:
+
+* API server
+* Kubelet
+* Kube controller manager
+* Kube scheduler
+* etcd
+* Route controller manager
+
+The API server uses the configured minimum TLS version and the associated cipher suites. If you leave the cipher suites parameter empty, the defaults for the configured minimum version are used automatically.
+
+include::snippets/microshift-tls-ciphers.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/modules/microshift-tls-config-proc.adoc b/modules/microshift-tls-config-proc.adoc
new file mode 100644
index 000000000000..686869fff3c2
--- /dev/null
+++ b/modules/microshift-tls-config-proc.adoc
@@ -0,0 +1,59 @@
+// Module included in the following assemblies:
+//
+// * microshift_configurig/microshift_tls-config.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-tls-config-proc_{context}"]
+= Configuring TLS for {microshift-short}
+
+You can choose to use either the TLS 1.2 or TLS 1.3 security profiles with {microshift-short} for system hardening.
+
+.Prerequisites
+
+* You have access to the cluster as a root user.
+* {microshift-short} has either not started for the first time, or is stopped.
+* The OpenShift CLI (`oc`) is installed.
+* The certificate authority has issued the custom certificates (CAs).
+
+.Procedure
+
+. Make a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory, renaming it `config.yaml`.
+
+. Keep the new {microshift-short} `config.yaml` in the `/etc/microshift/` directory. Your `config.yaml` file is read every time the {microshift-short} service starts.
++
+[NOTE]
+====
+After you create it, the `config.yaml` file takes precedence over built-in settings.
+====
+
+. Optional: Use a configuration snippet if you are using an existing {microshift-short} YAML. See "Using configuration snippets" in the Additional resources section for more information.
+
+. Replace the default values in the `tls` section of the {microshift-short} YAML with your valid values.
++
+.Example TLS 1.2 configuration
+[source,yaml]
+----
+apiServer:
+# ...
+  tls:
+    cipherSuites: # <1>
+    - <cipher_suite_1> # <2>
+    - ...
+    minVersion: VersionTLS12 # <3>
+# ...
+----
+<1> Defaults to the suites of the configured `minVersion`. If `minVersion` is not configured, the default value is TLS 1.2.
+<2> Specify the cipher suites you want to use from the list of supported cipher suites. If you do not configure this list, all of the supported cipher suites are used. All clients connecting to the API server must support the configured cipher suites or the connections fail during the TLS handshake phase. Be sure to add the CA certificate bundle to the list of CA certificates that the TLS client or server trusts.
+<3> Specify `VersionTLS12` or `VersionTLS13`.
++
+[IMPORTANT]
+====
+When you choose TLS 1.3 as the minimum TLS version, only the default {microshift-short} cipher suites can be used. Additional cipher suites are not configurable. If other cipher suites to use with TLS 1.3 are configured, those suites are ignored and overwritten by the {microshift-short} defaults.
+====
+
+. Complete any other additional configurations that you require, then restart {microshift-short} by running the following command:
++
+[source,terminal]
+----
+$ sudo systemctl restart microshift
+----
\ No newline at end of file
diff --git a/modules/microshift-tls-default-cipher-suites.adoc b/modules/microshift-tls-default-cipher-suites.adoc
new file mode 100644
index 000000000000..9d60b5dfe20f
--- /dev/null
+++ b/modules/microshift-tls-default-cipher-suites.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * microshift_configurig/microshift_tls-config.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="microshift-default-cipher-suites_{context}"]
+= Default cipher suites
+
+Default cipher suites are included with {microshift-short} for both TLS 1.2 and TLS 1.3. The cipher suites for TLS 1.3 cannot be customized.
+
+include::snippets/microshift-tls-ciphers.adoc[leveloffset=+1]
diff --git a/modules/microshift-uninstalling-lvms-csi-snapshot.adoc b/modules/microshift-uninstalling-lvms-csi-snapshot.adoc
index 6dd8bd35473e..b4efeecbae8f 100644
--- a/modules/microshift-uninstalling-lvms-csi-snapshot.adoc
+++ b/modules/microshift-uninstalling-lvms-csi-snapshot.adoc
@@ -11,7 +11,7 @@ To uninstall the installed CSI snapshot implementation, use the following proced
 .Prerequisites
 
 * {microshift-short} is installed and running.
-* The CSI snapshot implementation is deployed on the MicroShift cluster.
+* The CSI snapshot implementation is deployed on the {microshift-short} cluster.
 
 .Procedure
 
@@ -19,12 +19,11 @@ To uninstall the installed CSI snapshot implementation, use the following proced
 +
 [source,terminal]
 ----
-$ oc delete -n kube-system deployment.apps/snapshot-controller deployment.apps/snapshot-webhook
+$ oc delete -n kube-system deployment.apps/snapshot-controller
 ----
 +
 .Example output
 [source,terminal]
 ----
 deployment.apps "snapshot-controller" deleted
-deployment.apps "snapshot-webhook" deleted
 ----
diff --git a/modules/microshift-updates-rhde-config-rhel-repos.adoc b/modules/microshift-updates-rhde-config-rhel-repos.adoc
new file mode 100644
index 000000000000..7df5a5069e3b
--- /dev/null
+++ b/modules/microshift-updates-rhde-config-rhel-repos.adoc
@@ -0,0 +1,80 @@
+// Module included in the following assemblies:
+//
+//microshift_updating/microshift-update-options.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-updates-rhde-config-rhel-repos_{context}"]
+= Keeping {microshift-short} and {op-system-base} in a supported configuration
+
+When using RPM updates, avoid creating an unsupported configuration or breaking your cluster by carefully managing your {op-system-base} repositories.
+
+.Prerequisites
+
+* You understand the support status of the version of {microshift-short} you are using.
+* You have root-user access to your build host.
+* You reviewed the link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/getting_ready_to_install_microshift/microshift-install-get-ready#get-ready-install-rhde-compatibility-table_microshift-install-get-ready[{op-system-bundle} release compatibility matrix].
+
+.Procedure
+
+. Avoid unintended updates by locking your operating system version by running the following command:
++
+[source,terminal,subs="+quotes"]
+----
+$ sudo subscription-manager release --set=_<x.y>_ # <1>
+----
+<1> Replace _<x.y>_ with the major and minor version of your compatible {op-system-base} system. For example, _9.6_.
+
+//this is the same command as above; is this correct?
+. Update both {microshift-short} and {op-system-base} versions by running the following command:
++
+[source,terminal]
+----
+$ sudo subscription-manager release --set={ocp-version} # <1>
+----
+<1> You can replace _{ocp-version}_ with the major and minor version of your compatible {op-system-base} system if it is not the same version given in this example.
+
+. If you are using an EUS {microshift-short} release, disable the {op-system-base} standard-support-scope repositories by running the following command:
++
+[source,terminal]
+----
+$ sudo subscription-manager repos \
+    --disable=rhel-{op-system-version-major}-for-$(uname -m)-appstream-rpms \ # <1>
+    --disable=rhel-{op-system-version-major}-for-$(uname -m)-baseos-rpms
+----
+<1> You can replace _{op-system-version-major}_ with the major version of your compatible {op-system-base} system if it is not same version given in this example.
+
+. After you disable the standard-support repositories, enable the {op-system-base} EUS repos by running the following command:
++
+[source,terminal]
+----
+$ sudo subscription-manager repos \
+    --enable rhel-{op-system-version-major}-for-$(uname -m)-appstream-eus-rpms \  # <1>
+    --enable rhel-{op-system-version-major}-for-$(uname -m)-baseos-eus-rpms
+----
+<1> You can replace _{op-system-version-major}_ with the major version of your compatible {op-system-base} system if it is not same version given in this example.
+
+.Verification
+
+*  List the repositories you have enabled for {op-system-base} by running the following command:
++
+[source,terminal]
+----
+$ sudo subscription-manager repos --list-enabled
+----
++
+.Example output
++
+[source,terminal]
+----
++----------------------------------------------------------+
+    Available Repositories in /etc/yum.repos.d/redhat.repo
++----------------------------------------------------------+
+Repo ID:   rhel-9-for-x86_64-baseos-eus-rpms
+Repo Name: Red Hat Enterprise Linux 9 for x86_64 - BaseOS - Extended Update Support (RPMs)
+Repo URL:  https://cdn.redhat.com/content/eus/rhel9/$releasever/x86_64/baseos/os
+Enabled:   1
+Repo ID:   rhel-9-for-x86_64-appstream-eus-rpms
+Repo Name: Red Hat Enterprise Linux 9 for x86_64 - AppStream - Extended Update Support (RPMs)
+Repo URL:  https://cdn.redhat.com/content/eus/rhel9/$releasever/x86_64/appstream/os
+Enabled:   1
+----
\ No newline at end of file
diff --git a/modules/microshift-updates-troubleshooting.adoc b/modules/microshift-updates-troubleshooting.adoc
index 4f2f32677a14..a3076ba256a6 100644
--- a/modules/microshift-updates-troubleshooting.adoc
+++ b/modules/microshift-updates-troubleshooting.adoc
@@ -22,17 +22,6 @@ Check the following compatibility table:
 
 include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+2]
 
-[id="microshift-version-compatibility_{context}"]
-=== Version compatibility
-Check the following update paths:
-
-*{product-title} update paths*
-
-* Generally Available Version 4.18.0 to 4.18.z on {op-system-base} 9.4
-* Generally Available Version 4.17.1 to 4.17.z on {op-system-base} 9.4
-* Generally Available Version 4.15.0 from {op-system-base} 9.2 to 4.16.0 on {op-system-base} 9.4
-* Generally Available Version 4.14.0 from {op-system-base} 9.2 to 4.15.0 on {op-system-base} 9.4
-
 [id="microshift-ostree-update-failed_{context}"]
 == OSTree update failed
 If you updated on an OSTree system, the Greenboot health check automatically logs and acts on system health. A failure can be indicated by a system rollback by Greenboot. In cases where the update failed, but Greenboot did not complete a system rollback, you can troubleshoot using the {op-system-ostree} documentation linked in the "Additional resources" section that follows this content.
diff --git a/modules/microshift-updating-rpms-ostree.adoc b/modules/microshift-updating-rpms-ostree.adoc
index db5c62e71d58..82222be303e4 100644
--- a/modules/microshift-updating-rpms-ostree.adoc
+++ b/modules/microshift-updating-rpms-ostree.adoc
@@ -54,11 +54,11 @@ $ sudo composer-cli sources add {rpm-repo-version}.toml
 
 . Build a new image of {op-system-ostree} that contains the new version of {microshift-short}. To determine the steps required, use the following documentation:
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/managing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images#proc_building-a-commit-update_managing-rhel-for-edge-images[Building a RHEL for Edge commit update]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/managing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images#proc_building-a-commit-update_managing-rhel-for-edge-images[Building a commit update]
 
 . Update the host to use the new image of {op-system-ostree}. To determine the steps required, use the following documentation:
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/managing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images#how-are-rhel-for-edge-image-updates-deployed_managing-rhel-for-edge-images[Deploying RHEL for Edge image updates]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/managing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images#how-are-rhel-for-edge-image-updates-deployed_managing-rhel-for-edge-images[How RHEL for Edge image updates are deployed]
 
 . Reboot the host to apply updates by running the following command:
 +
diff --git a/modules/microshift-updating-rpms-y.adoc b/modules/microshift-updating-rpms-y.adoc
index 56b147932b1d..e27f0363adec 100644
--- a/modules/microshift-updating-rpms-y.adoc
+++ b/modules/microshift-updating-rpms-y.adoc
@@ -8,6 +8,8 @@
 
 Updating a {microshift-short} minor version on non `rpm-ostree` systems such as {op-system-base-full} requires downloading then updating the RPMs. For example, use the following procedure to update from 4.16 to 4.18.
 
+include::snippets/microshift-unsupported-config-warn.adoc[leveloffset=+1]
+
 .Prerequisites
 * The system requirements for installing {microshift-short} have been met.
 * You have root user access to the host.
@@ -22,14 +24,35 @@ You cannot downgrade {microshift-short} with this process. Downgrades are not su
 
 .Procedure
 
-. Enable the {microshift-short} repositories by running the following command:
+. For all lifecycles, enable the repository for your release by running the following command:
 +
 [source,terminal,subs="attributes+"]
 ----
 $ sudo subscription-manager repos \
-    --enable rhocp-{ocp-version}-for-{rhel-major}-$(uname -m)-rpms \
-    --enable fast-datapath-for-{rhel-major}-$(uname -m)-rpms
+    --enable rhocp-<x.y>-for-<9>-$(uname -m)-rpms \ # <1>
+    --enable fast-datapath-for-<9>-$(uname -m)-rpms # <2>
+----
+<1> Replace _<x.y>_ and _<9>_ with the compatible versions of your {microshift-short} and {op-system-base-full}.
+<2> Replace  _<9>_ with the compatible version of {op-system-base}.
+
+. For extended support (EUS) releases, also enable the EUS repositories by running the following command:
++
+[source,terminal]
+----
+`$ sudo subscription-manager repos \
+    --enable rhel-<9>-for-x86_64-appstream-eus-rpms \ # <1>
+    --enable rhel-<9>-for-x86_64-baseos-eus-rpms` # <2>
+----
+<1> Replace _<9>_ with the compatible major version number of {op-system-base}.
+<2> Replace _<9>_ with the compatible major version number of {op-system-base}.
+
+. Avoid unintended future updates into an unsupported configuration by locking your operating system version with the following command:
++
+[source,terminal]
+----
+$ sudo subscription-manager release --set=<9.4> command. # <1>
 ----
+<1> Replace _<9.4>_ with the major and minor version of your compatible {op-system-base} system.
 
 . Update the {microshift-short} RPMs by running the following command:
 +
diff --git a/modules/microshift-updating-rpms-z.adoc b/modules/microshift-updating-rpms-z.adoc
index 4f8e4ea59062..8da81d244957 100644
--- a/modules/microshift-updating-rpms-z.adoc
+++ b/modules/microshift-updating-rpms-z.adoc
@@ -6,9 +6,12 @@
 [id="microshift-applying-patch-updates-rpms_{context}"]
 = Applying patch updates using RPMs
 
-Updating {microshift-short} on non `rpm-ostree` systems such as {op-system-base-full} requires downloading then updating the RPMs. For example, use the following procedure to upgrade from 4.18.1 to 4.18.2.
+Updating {microshift-short} on non `rpm-ostree` systems such as {op-system-base-full} requires downloading then updating the RPMs. For example, use the following procedure to upgrade from 4.19.1 to 4.19.2.
+
+include::snippets/microshift-unsupported-config-warn.adoc[leveloffset=+1]
 
 .Prerequisites
+
 * The system requirements for installing {microshift-short} have been met.
 * You have root user access to the host.
 * The version of {microshift-short} you have is compatible to upgrade to the version you are preparing to use.
@@ -21,13 +24,15 @@ You cannot downgrade {microshift-short} with this process. Downgrades are not su
 ====
 
 .Procedure
-* Update the {microshift-short} RPMs by running the following command:
+
+. Update the {microshift-short} RPMs by running the following command:
 +
 [source,terminal]
 ----
 $ sudo dnf update microshift
 ----
-* Restart {microshift-short} by running the following command:
+
+. Restart {microshift-short} by running the following command:
 +
 [source,terminal]
 ----
@@ -36,5 +41,5 @@ $ sudo systemctl restart microshift
 
 [NOTE]
 ====
-The system health check runs on this update type, but does not perform any actions. If the update fails, an error message appears with the instruction to check the logs.
+The greenboot system health check runs on this update type, but does not perform any actions. If the update fails, an error message appears with the instruction to check the logs.
 ====
\ No newline at end of file
diff --git a/modules/microshift-upload-cont2-mirror-script.adoc b/modules/microshift-upload-cont2-mirror-script.adoc
deleted file mode 100644
index d0bd0d378f18..000000000000
--- a/modules/microshift-upload-cont2-mirror-script.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-[source,sh]
-----
-# Use timestamp and counter as a tag on the target images to avoid
-# their overwrite by the 'latest' automatic tagging
-image_tag=mirror-$(date +%y%m%d%H%M%S)
-image_cnt=1
-
-pushd "${IMAGE_LOCAL_DIR}" >/dev/null
-while read -r src_manifest ; do
-   # Remove the manifest.json file name
-   src_img=$(dirname "${src_manifest}")
-   # Add the target registry prefix and remove SHA
-   dst_img="${TARGET_REGISTRY}/${src_img}"
-   dst_img=$(echo "${dst_img}" | awk -F'@' '{print $1}')
-
-   # Run the image upload command
-   echo "Uploading '${src_img}' to '${dst_img}'"
-   skopeo copy --all --quiet \
-      --preserve-digests \
-      --authfile "${IMAGE_PULL_FILE}" \
-      dir://"${IMAGE_LOCAL_DIR}/${src_img}" docker://"${dst_img}:${image_tag}-${image_cnt}"
-   # Increment the counter
-   (( image_cnt += 1 ))
-
-done < <(find . -type f -name manifest.json -printf '%P\n')
-popd >/dev/null
-----
\ No newline at end of file
diff --git a/modules/microshift-uploading-images-to-mirror.adoc b/modules/microshift-uploading-images-to-mirror.adoc
index 078f6e9c40b4..7e72ea5b147c 100644
--- a/modules/microshift-uploading-images-to-mirror.adoc
+++ b/modules/microshift-uploading-images-to-mirror.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * microshift/running_applications/microshift-deploy-with-mirror-registry.adoc
+// * microshift/pmicroshift_install_rpm_ostree/microshift-deploy-with-mirror-registry.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="microshift-uploading-container-images-to-mirror_{context}"]
@@ -39,38 +39,29 @@ $ IMAGE_LOCAL_DIR=~/microshift-containers
 
 . Set the environment variables pointing to the mirror registry URL for uploading the container images:
 +
-[source,terminal]
+[source,terminal,subs="+quotes"]
 ----
-$ TARGET_REGISTRY=<registry_host>:<port> <1>
+$ TARGET_REGISTRY=_<registry_host>:<port>_ # <1>
 ----
-<1> Replace `<registry_host>:<port>` with the host name and port of your mirror registry server.
+<1> Replace `_<registry_host>:<port>_` with the host name and port of your mirror registry server.
 
 . Run the following script to upload the container images to the `${TARGET_REGISTRY}` mirror registry:
 +
 [source,terminal]
 ----
-image_tag=mirror-$(date +%y%m%d%H%M%S)
-image_cnt=1
-   # Uses timestamp and counter as a tag on the target images to avoid
-   # their overwrite by the 'latest' automatic tagging
-
 pushd "${IMAGE_LOCAL_DIR}" >/dev/null
 while read -r src_manifest ; do
-   # Remove the manifest.json file name
-   src_img=$(dirname "${src_manifest}")
-   # Add the target registry prefix and remove SHA
-   dst_img="${TARGET_REGISTRY}/${src_img}"
-   dst_img=$(echo "${dst_img}" | awk -F'@' '{print $1}')
-
-   # Run the image upload command
-   echo "Uploading '${src_img}' to '${dst_img}'"
-   skopeo copy --all --quiet \
-      --preserve-digests \
-      --authfile "${IMAGE_PULL_FILE}" \
-      dir://"${IMAGE_LOCAL_DIR}/${src_img}" docker://"${dst_img}:${image_tag}-${image_cnt}"
-   # Increment the counter
-   (( image_cnt += 1 ))
-
+  local src_img
+  src_img=$(dirname "${src_manifest}")
+  # Add the target registry prefix and remove SHA
+  local -r dst_img="${TARGET_REGISTRY}/${src_img}"
+  local -r dst_img_no_tag="${TARGET_REGISTRY}/${src_img%%[@:]*}"
+  # Run the image upload
+  echo "Uploading '${src_img}' to '${dst_img}'"
+  skopeo copy --all --quiet \
+     --preserve-digests \
+     --authfile "${IMAGE_PULL_FILE}" \
+     dir://"${IMAGE_LOCAL_DIR}/${src_img}" docker://"${dst_img}"
 done < <(find . -type f -name manifest.json -printf '%P\n')
 popd >/dev/null
 ----
diff --git a/modules/migrate-sdn-ovn-osd.adoc b/modules/migrate-sdn-ovn-osd.adoc
new file mode 100644
index 000000000000..392a1edb07d4
--- /dev/null
+++ b/modules/migrate-sdn-ovn-osd.adoc
@@ -0,0 +1,111 @@
+// Module included in the following assemblies:
+//networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="migrate-sdn-ovn-ocm-cli_{context}"]
+= Initiating migration using the OpenShift Cluster Manager API command-line interface (ocm) CLI
+
+[WARNING]
+====
+You can only initiate migration on clusters that are version 4.16.24 and above.
+====
+
+.Prerequisites
+
+*  You installed the link:https://console.redhat.com/openshift/downloads[OpenShift Cluster Manager API command-line interface (`ocm`)].
+
+[IMPORTANT]
+====
+[subs="attributes+"]
+OpenShift Cluster Manager API command-line interface (`ocm`) is a Developer Preview feature only.
+For more information about the support scope of Red Hat Developer Preview features, see link:https://access.redhat.com/support/offerings/devpreview/[Developer Preview Support Scope].
+====
+
+.Procedure
+
+. Create a JSON file with the following content:
+
++
+[source,json]
+----
+{
+  "type": "sdnToOvn"
+}
+----
++
+
+** Optional: Within the JSON file, you can configure internal subnets using any or all of the options `join`, `masquerade`, and `transit`, along with a single CIDR per option, as shown in the following example:
++
+[source,json]
+----
+{
+  "type": "sdnToOvn",
+  "sdn_to_ovn": {
+    "transit_ipv4": "192.168.255.0/24",
+    "join_ipv4": "192.168.255.0/24",
+    "masquerade_ipv4": "192.168.255.0/24"
+  }
+}
+----
++
+[NOTE]
+====
+OVN-Kubernetes reserves the following IP address ranges:
+
+`100.64.0.0/16`. This IP address range is used for the `internalJoinSubnet` parameter of OVN-Kubernetes by default.
+
+`100.88.0.0/16`. This IP address range is used for the `internalTransSwitchSubnet` parameter of OVN-Kubernetes by default.
+
+If these IP addresses have been used by OpenShift SDN or any external networks that might communicate with this cluster, you must patch them to use a different IP address range before initiating the limited live migration. For more information, see _Patching OVN-Kubernetes address ranges_ in the _Additional resources_ section.
+====
++
+
+. To initiate the migration, run the following post request in a terminal window:
+
++
+[source,terminal]
+----
+$ ocm post /api/clusters_mgmt/v1/clusters/{cluster_id}/migrations <1>
+  --body=myjsonfile.json <2>
+----
+<1> Replace `{cluster_id}` with the ID of the cluster you want to migrate to the OVN-Kubernetes network plugin.
+<2> Replace `myjsonfile.json` with the name of the JSON file you created in the previous step.
++
+.Example output
++
+[source,json]
+----
+{
+  "kind": "ClusterMigration",
+  "href": "/api/clusters_mgmt/v1/clusters/2gnts65ra30sclb114p8qdc26g5c8o3e/migrations/2gois8j244rs0qrfu9ti2o790jssgh9i",
+  "id": "7sois8j244rs0qrhu9ti2o790jssgh9i",
+  "cluster_id": "2gnts65ra30sclb114p8qdc26g5c8o3e",
+  "type": "sdnToOvn",
+  "state": {
+    "value": "scheduled",
+    "description": ""
+  },
+  "sdn_to_ovn": {
+    "transit_ipv4": "100.65.0.0/16",
+    "join_ipv4": "100.66.0.0/16"
+  },
+  "creation_timestamp": "2025-02-05T14:56:34.878467542Z",
+  "updated_timestamp": "2025-02-05T14:56:34.878467542Z"
+}
+----
+
+// :_mod-docs-content-type: PROCEDURE
+// [id="verify-sdn-ovn-ocm_{context}"]
+// = Verify migration status using the OCM CLI
+
+.Verification
+
+* To check the status of the migration, run the following command:
+
++
+
+[source,terminal]
+----
+$ ocm get cluster <cluster_id>/migrations <1>
+----
+<1> Replace `<cluster_id>` with the ID of the cluster that the migration was applied to.
diff --git a/modules/migrate-sdn-ovn.adoc b/modules/migrate-sdn-ovn.adoc
new file mode 100644
index 000000000000..e32d9493d633
--- /dev/null
+++ b/modules/migrate-sdn-ovn.adoc
@@ -0,0 +1,38 @@
+// Module included in the following assemblies:
+//networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="migrate-sdn-ovn-cli_{context}"]
+= Initiating migration using the ROSA CLI
+
+[WARNING]
+====
+You can only initiate migration on clusters that are version 4.16.24 and above.
+====
+
+To initiate the migration, run the following command:
+[source,terminal]
+----
+$ rosa edit cluster -c <cluster_id> <1>
+  --network-type OVNKubernetes
+  --ovn-internal-subnets <configuration> <2>
+----
+<1> Replace `<cluster_id>` with the ID of the cluster you want to migrate to the OVN-Kubernetes network plugin.
+<2> Optional: Users can create key-value pairs to configure internal subnets using any or all of the options `join, masquerade, transit` along with a single CIDR per option. For example, `--ovn-internal-subnets="join=0.0.0.0/24,transit=0.0.0.0/24,masquerade=0.0.0.0/24"`.
+
+[IMPORTANT]
+====
+You cannot include the optional flag `--ovn-internal-subnets` in the command unless you define a value for the flag `--network-type`.
+====
+
+.Verification
+
+* To check the status of the migration, run the following command:
+
++
+
+[source,terminal]
+----
+$ rosa describe cluster -c <cluster_id> <1>
+----
+<1> Replace `<cluster_id>` with the ID of the cluster to check the migration status.
\ No newline at end of file
diff --git a/modules/migrating-from-x86-to-arm-cp.adoc b/modules/migrating-from-x86-to-arm-cp.adoc
new file mode 100644
index 000000000000..53edc992a438
--- /dev/null
+++ b/modules/migrating-from-x86-to-arm-cp.adoc
@@ -0,0 +1,113 @@
+// Module included in the following assemblies:
+//
+// * updating/updating_a_cluster/migrating-to-multi-payload.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="migrating-from-x86-to-arm64-cp_{context}"]
+= Migrating the x86 control plane to arm64 architecture on {aws-full}
+
+You can migrate the control plane in your cluster from `x86` to `arm64` architecture on {aws-first}.
+
+.Prerequisites
+
+* You have installed the {oc-first}.
+* You logged in to `oc` as a user with `cluster-admin` privileges.
+
+.Procedure
+
+. Check the architecture of the control plane nodes by running the following command:
++
+[source,terminal]
+----
+$ oc get nodes -o wide
+----
++
+.Example output
+[source,terminal]
+----
+NAME                          STATUS   ROLES                  AGE    VERSION   INTERNAL-IP EXTERNAL-IP   OS-IMAGE                                         KERNEL-VERSION                 CONTAINER-RUNTIME
+worker-001.example.com        Ready    worker                 100d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+worker-002.example.com        Ready    worker                 98d    v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+worker-003.example.com        Ready    worker                 98d    v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+master-001.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+master-002.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+master-003.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+----
++
+The `KERNEL-VERSION` field in the output indicates the architecture of the nodes.
+
+. Check that your cluster uses the multi payload by running the following command:
++
+[source,terminal]
+----
+$ oc adm release info -o jsonpath="{ .metadata.metadata}"
+----
++
+If you see the following output, the cluster is multi-architecture compatible.
++
+[source,terminal]
+----
+{
+ "release.openshift.io/architecture": "multi",
+ "url": "https://access.redhat.com/errata/<errata_version>"
+}
+----
++
+If the cluster is not using the multi payload, migrate the cluster to a multi-architecture cluster. For more information, see "Migrating to a cluster with multi-architecture compute machines". 
+
+. Update your image stream from single-architecture to multi-architecture by running the following command:
++
+--
+include::snippets/update-image-stream-to-multi-arch.adoc[]
+--
+
+. Get the `arm64` compatible Amazon Machine Image (AMI) for configuring the control plane machine set by running the following command:
++
+[source,terminal]
+----
+$ oc get configmap/coreos-bootimages -n openshift-machine-config-operator -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64.images.aws.regions."<aws_region>".image' <1>
+----
+<1> Replace `<aws_region>` with the {aws-short} region where the current cluster is installed. You can get the {aws-short} region for the installed cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get infrastructure cluster -o jsonpath='{.status.platformStatus.aws.region}'
+----
++
+.Example output
+[source,terminal]
+----
+ami-xxxxxxx
+----
+
+. Update the control plane machine set to support the `arm64` architecture by running the following command:
++
+[source,terminal]
+----
+$ oc edit controlplanemachineset.machine.openshift.io cluster -n openshift-machine-api
+----
++
+Update the `instanceType` field to a type that supports the `arm64` architecture, and set the `ami.id` field to an AMI that is compatible with the `arm64` architecture. For information about supported instance types, see "Tested instance types for {aws-short} on 64-bit ARM infrastructures".
++
+For more information about configuring the control plane machine set for {aws-short}, see "Control plane configuration options for {aws-full}".
+
+.Verification
+
+* Verify that the control plane nodes are now running on the `arm64` architecture:
++
+[source,terminal]
+----
+$ oc get nodes -o wide
+----
++
+.Example output
+[source,terminal]
+----
+NAME                          STATUS   ROLES                  AGE    VERSION   INTERNAL-IP EXTERNAL-IP   OS-IMAGE                                         KERNEL-VERSION                 CONTAINER-RUNTIME
+worker-001.example.com        Ready    worker                 100d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+worker-002.example.com        Ready    worker                 98d    v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+worker-003.example.com        Ready    worker                 98d    v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.x86_64    cri-o://1.30.x
+master-001.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.aarch64   cri-o://1.30.x
+master-002.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.aarch64   cri-o://1.30.x
+master-003.example.com        Ready    control-plane,master   120d   v1.30.7   10.x.x.x    <none>        Red Hat Enterprise Linux CoreOS 4xx.xx.xxxxx-0   5.x.x-xxx.x.x.el9_xx.aarch64   cri-o://1.30.x
+----
diff --git a/modules/migrating-to-multi-arch-cli.adoc b/modules/migrating-to-multi-arch-cli.adoc
index 4248aa267009..f9d33b4e46c4 100644
--- a/modules/migrating-to-multi-arch-cli.adoc
+++ b/modules/migrating-to-multi-arch-cli.adoc
@@ -65,23 +65,27 @@ $ oc adm upgrade --to-multi-arch
 $ oc adm upgrade
 ----
 +
+.Example output
+
+[source,terminal]
+----
+working towards ${VERSION}: 106 of 841 done (12% complete), waiting on machine-config
+----
++
 [IMPORTANT]
 ====
 Machine launches may fail as the cluster settles into the new state. To notice and recover when machines fail to launch, we recommend deploying machine health checks. For more information about machine health checks and how to deploy them, see _About machine health checks_.
 ====
 +
-//commenting this section out until https://issues.redhat.com/browse/OCPBUGS-8256 is resolved:
-//For `oc get co`, expect `AVAILABLE=True`, `PROGRESSING=False`, and `DEGRADED=False` on all cluster Operators.
-+
-//For `oc get mcp`, expect `UPDATED=True`, `UPDATING=False`, and `DEGRADED=False` on all machine config pools.
+. Optional: To retrieve more detailed information about the status of your update, monitor the migration by running the following command:
 +
-//For `oc adm upgrade`, here is an example of a response:
-+
-//[source,terminal]
-//----
-//working towards ${VERSION}: 106 of 841 done (12% complete), waiting on etcd, kube-apiserver
-//----
+[source,terminal]
+----
+$ oc adm upgrade status
+----
 +
+For more information about how to use the `oc adm upgrade status` command, see _Gathering cluster update status using oc adm upgrade status (Technology Preview)_.
+
 The migrations must be complete and all the cluster operators must be stable before you can add compute machine sets with different architectures to your cluster.
 
 
diff --git a/modules/migrating-to-virt.adoc b/modules/migrating-to-virt.adoc
new file mode 100644
index 000000000000..0c234845a35a
--- /dev/null
+++ b/modules/migrating-to-virt.adoc
@@ -0,0 +1,34 @@
+// Module included in the following assemblies:
+//
+// * virt/getting_started/virt-getting-started.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="migrating-to-virt_{context}"]
+= Migrating to {VirtProductName}
+
+To migrate virtual machines from an external provider such as {vmw-first}, {rh-openstack-first}, Red Hat Virtualization, or another {product-title} cluster, use the {mtv-first}. You can also migrate Open Virtual Appliance (OVA) files created by {vmw-full}.
+
+[NOTE]
+====
+{mtv-full} is not part of {VirtProductName} and requires separate installation. For this reason, all links in this procedure lead outside of {VirtProductName} documentation.
+====
+
+.Prerequisites
+* The {mtv-full} Operator link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/installing-the-operator_mtv#installing-the-operator_mtv[is installed].
+
+.Procedure
+. link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-vms-web-console_mtv#adding-source-providers[Configure the source provider].
++
+Select the source provider and enter any required information, such as the URL of the API endpoint or credentials needed to access the virtual machines.
+
+. link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-vms-web-console_mtv#creating-migration-plans-ui[Create a migration plan].
++
+Select from the list of available virtual machines, configure the target provider, and define storage and network mappings.
+
+. link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-vms-web-console_mtv#running-migration-plan_mtv[Run the migration plan].
++
+Watch the progress, view migration logs, or cancel the migration.
+
+. Optional: link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-vms-web-console_mtv#migration-plan-options-ui_mtv[Archive the migration plan].
++
+After confirming that the migration has completed successfully, you can archive the migration plan to delete the logs and clean up all temporary resources created during migration. You can permanently delete an archived migration plan.
diff --git a/modules/migration-migrating-on-prem-to-cloud.adoc b/modules/migration-migrating-on-prem-to-cloud.adoc
index b1917b80c60f..065ef4a7cc4d 100644
--- a/modules/migration-migrating-on-prem-to-cloud.adoc
+++ b/modules/migration-migrating-on-prem-to-cloud.adoc
@@ -4,7 +4,7 @@
 // * migration_toolkit_for_containers/advanced-migration-options-mtc.adoc
 :_mod-docs-content-type: PROCEDURE
 [id="migration-migrating-applications-on-prem-to-cloud_{context}"]
-= Migrating an application from on-premises to a cloud-based cluster
+= Migrating an application from on-premise to a cloud-based cluster
 
 You can migrate from a source cluster that is behind a firewall to a cloud-based destination cluster by establishing a network tunnel between the two clusters. The `crane tunnel-api` command establishes such a tunnel by creating a VPN tunnel on the source cluster and then connecting to a VPN server running on the destination cluster. The VPN server is exposed to the client using a load balancer address on the destination cluster.
 
diff --git a/modules/minimum-ibm-power-system-requirements.adoc b/modules/minimum-ibm-power-system-requirements.adoc
index 854857c795b8..c70486109322 100644
--- a/modules/minimum-ibm-power-system-requirements.adoc
+++ b/modules/minimum-ibm-power-system-requirements.adoc
@@ -11,11 +11,6 @@ You can install {product-title} version {product-version} on the following {ibm-
 
 * {ibm-power-name}9 or {ibm-power-name}10 processor-based systems
 
-[NOTE]
-====
-Support for {op-system} functionality for all {ibm-power-name}8 models, {ibm-power-name} AC922, {ibm-power-name} IC922, and {ibm-power-name} LC922 is deprecated in {product-title} {product-version}. Red Hat recommends that you use later hardware models.
-====
-
 [discrete]
 == Hardware requirements
 
@@ -35,7 +30,7 @@ On your {ibm-power-name} instance, set up:
 [discrete]
 == Disk storage for the {ibm-power-title} guest virtual machines
 
-* Local storage, or storage provisioned by the Virtual I/O Server using vSCSI, NPIV (N-Port ID Virtualization), Fibre Channel, or SSP (shared storage pools)
+* Local storage, or storage provisioned by the Virtual I/O Server using vSCSI, NPIV (N-Port ID Virtualization), Fibre Channel, Multipathing, or SSP (shared storage pools)
 
 [discrete]
 == Network for the PowerVM guest virtual machines
@@ -47,6 +42,6 @@ On your {ibm-power-name} instance, set up:
 [discrete]
 == Storage / main memory
 
-* 100 GB / 16 GB for {product-title} control plane machines
-* 100 GB / 8 GB for {product-title} compute machines
-* 100 GB / 16 GB for the temporary {product-title} bootstrap machine
+* 500 GB / 16 GB for {product-title} control plane machines
+* 500 GB / 8 GB for {product-title} compute machines
+* 500 GB / 16 GB for the temporary {product-title} bootstrap machine
diff --git a/modules/mirror-registry-localhost-update.adoc b/modules/mirror-registry-localhost-update.adoc
index da6248bd2dce..7971455fac44 100644
--- a/modules/mirror-registry-localhost-update.adoc
+++ b/modules/mirror-registry-localhost-update.adoc
@@ -16,7 +16,7 @@ When upgrading from version 1 to version 2, be aware of the following constraint
 ** You must not use the _mirror registry for Red{nbsp}Hat OpenShift_ user interface (UP).
 ** Do not access the `sqlite-storage` Podman volume during the upgrade.
 ** There is intermittent downtime of your mirror registry because it is restarted during the upgrade process.
-** PostgreSQL data is backed up under the `/$HOME/quay-instal/quay-postgres-backup/` directory for recovery.
+** PostgreSQL data is backed up under the `/$HOME/quay-install/quay-postgres-backup/` directory for recovery.
 ====
 
 .Prerequisites
diff --git a/modules/mirror-registry-release-notes.adoc b/modules/mirror-registry-release-notes.adoc
index 086da6993a02..acd0806200fd 100644
--- a/modules/mirror-registry-release-notes.adoc
+++ b/modules/mirror-registry-release-notes.adoc
@@ -94,7 +94,7 @@ New installations use SQLite by default. Before upgrading to version 2.0, see "U
 [id="mirror-registry-release-notes-1-3_{context}"]
 == Mirror registry for Red{nbsp}Hat OpenShift 1.3 release notes
 
-To view the _mirror registry for Red{nbsp}Hat OpenShift_ 1.3 release notes, see link:https://docs.openshift.com/container-platform/4.17/installing/disconnected_install/installing-mirroring-creating-registry.html#mirror-registry-release-notes-1-3_installing-mirroring-creating-registry[Mirror registry for Red{nbsp}Hat OpenShift 1.3 release notes].
+To view the _mirror registry for Red{nbsp}Hat OpenShift_ 1.3 release notes, see link:https://docs.openshift.com/container-platform/4.18/installing/disconnected_install/installing-mirroring-creating-registry.html#mirror-registry-release-notes-1-3_installing-mirroring-creating-registry[Mirror registry for Red{nbsp}Hat OpenShift 1.3 release notes].
 
 [id="mirror-registry-release-notes-1-2_{context}"]
 == Mirror registry for Red{nbsp}Hat OpenShift 1.2 release notes
diff --git a/modules/mirror-registry-remote-host-update.adoc b/modules/mirror-registry-remote-host-update.adoc
index ec7c347f56b6..857720e81645 100644
--- a/modules/mirror-registry-remote-host-update.adoc
+++ b/modules/mirror-registry-remote-host-update.adoc
@@ -16,7 +16,7 @@ When upgrading from version 1 to version 2, be aware of the following constraint
 ** You must not use the _mirror registry for Red{nbsp}Hat OpenShift_ user interface (UP).
 ** Do not access the `sqlite-storage` Podman volume during the upgrade.
 ** There is intermittent downtime of your mirror registry because it is restarted during the upgrade process.
-** PostgreSQL data is backed up under the `/$HOME/quay-instal/quay-postgres-backup/` directory for recovery.
+** PostgreSQL data is backed up under the `/$HOME/quay-install/quay-postgres-backup/` directory for recovery.
 ====
 
 .Prerequisites
diff --git a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc
index 224a4601aa0b..16d6aaaba09e 100644
--- a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc
+++ b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc
@@ -13,7 +13,7 @@ You can directly access web service API endpoints from the command line for the
 * Thanos Ruler
 * Thanos Querier
 
-[NOTE]
+[IMPORTANT]
 ====
 To access Thanos Ruler and Thanos Querier service APIs, the requesting account must have `get` permission on the namespaces resource, which can be granted by binding the `cluster-monitoring-view` cluster role to the account.
 ====
diff --git a/modules/monitoring-about-managing-alerts.adoc b/modules/monitoring-about-managing-alerts.adoc
new file mode 100644
index 000000000000..9ba92e54ed35
--- /dev/null
+++ b/modules/monitoring-about-managing-alerts.adoc
@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/managing-alerts.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="about-managing-alerts_{context}"]
+= Managing alerts
+
+In the {product-title}, the Alerting UI enables you to manage alerts, silences, and alerting rules.
+
+* *Alerting rules*. Alerting rules contain a set of conditions that outline a particular state within a cluster. Alerts are triggered when those conditions are true. An alerting rule can be assigned a severity that defines how the alerts are routed.
+* *Alerts*. An alert is fired when the conditions defined in an alerting rule are true. Alerts provide a notification that a set of circumstances are apparent within an {product-title} cluster.
+* *Silences*. A silence can be applied to an alert to prevent notifications from being sent when the conditions for an alert are true. You can mute an alert after the initial notification, while you work on resolving the issue.
+
+[NOTE]
+====
+The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to. For example, if you are logged in as a user with the `cluster-admin` role, you can access all alerts, silences, and alerting rules.
+====
diff --git a/modules/monitoring-about-monitoring-dashboards.adoc b/modules/monitoring-about-monitoring-dashboards.adoc
new file mode 100644
index 000000000000..83359b1694a9
--- /dev/null
+++ b/modules/monitoring-about-monitoring-dashboards.adoc
@@ -0,0 +1,28 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/reviewing-monitoring-dashboards.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="mon-dashboards-adm-perspective_{context}"]
+= Monitoring dashboards in the Administrator perspective
+
+Use the *Administrator* perspective to access dashboards for the core {product-title} components, including the following items:
+
+* API performance
+* etcd
+* Kubernetes compute resources
+* Kubernetes network resources
+* Prometheus
+* USE method dashboards relating to cluster and node performance
+* Node performance metrics
+
+.Example dashboard in the Administrator perspective
+image::monitoring-dashboard-administrator.png[]
+
+[id="mon-dashboards-dev-perspective_{context}"]
+= Monitoring dashboards in the Developer perspective
+
+In the *Developer* perspective, you can access only the Kubernetes compute resources dashboards:
+
+.Example dashboard in the Developer perspective
+image::observe-dashboard-developer.png[]
\ No newline at end of file
diff --git a/modules/monitoring-about-querying-metrics.adoc b/modules/monitoring-about-querying-metrics.adoc
deleted file mode 100644
index a8e465100147..000000000000
--- a/modules/monitoring-about-querying-metrics.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-// Module included in the following assemblies:
-//
-// * observability/monitoring/managing-metrics.adoc
-// * virt/support/virt-prometheus-queries.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="about-querying-metrics_{context}"]
-= Querying metrics
-
-The {product-title} monitoring dashboard enables you to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring.
-
-ifndef::openshift-dedicated,openshift-rosa[]
-As a cluster administrator, you can query metrics for all core {product-title} and user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-As a `dedicated-admin`, you can query one or more namespaces at a time for metrics about user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-
-As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.
diff --git a/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc b/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc
index 1131a8e800fa..f19154561933 100644
--- a/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc
+++ b/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc
@@ -6,22 +6,25 @@
 [id="about-specifying-limits-and-requests-for-monitoring-components_{context}"]
 = About specifying limits and requests for monitoring components
 
-You can configure resource limits and request settings for core platform monitoring components and for the components that monitor user-defined projects, including the following components:
+You can configure resource limits and requests for the following core platform monitoring components:
 
-* Alertmanager (for core platform monitoring and for user-defined projects)
+* Alertmanager
 * kube-state-metrics
 * monitoring-plugin
 * node-exporter
 * openshift-state-metrics
-* Prometheus (for core platform monitoring and for user-defined projects)
+* Prometheus
 * Metrics Server
 * Prometheus Operator and its admission webhook service
 * Telemeter Client
 * Thanos Querier
-* Thanos Ruler
 
-By defining resource limits, you limit a container's resource usage, which prevents the container from exceeding the specified maximum values for CPU and memory resources.
+You can configure resource limits and requests for the following components that monitor user-defined projects:
 
-By defining resource requests, you specify that a container can be scheduled only on a node that has enough CPU and memory resources available to match the requested resources.
+* Alertmanager
+* Prometheus
+* Thanos Ruler
 
+By defining the resource limits, you limit a container's resource usage, which prevents the container from exceeding the specified maximum values for CPU and memory resources.
 
+By defining the resource requests, you specify that a container can be scheduled only on a node that has enough CPU and memory resources available to match the requested resources.
\ No newline at end of file
diff --git a/modules/monitoring-accessing-the-alerting-ui.adoc b/modules/monitoring-accessing-the-alerting-ui.adoc
index 8ef40b41fd3a..8bf74e776a4c 100644
--- a/modules/monitoring-accessing-the-alerting-ui.adoc
+++ b/modules/monitoring-accessing-the-alerting-ui.adoc
@@ -4,18 +4,46 @@
 // * logging/logging_alerts/log-storage-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="monitoring-accessing-the-alerting-ui_{context}"]
-= Accessing the Alerting UI in the Administrator and Developer perspectives
 
-The Alerting UI is accessible through the *Administrator* perspective and the *Developer* perspective of the {product-title} web console.
+// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
 
-* In the *Administrator* perspective, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages.
+// tag::ADM[]
+[id="monitoring-accessing-the-alerting-ui-adm_{context}"]
+= Accessing the Alerting UI from the Administrator perspective
+// end::ADM[]
 
-//Next to the title of each of these pages is a link to the Alertmanager interface.
+// tag::DEV[]
+[id="monitoring-accessing-the-alerting-ui-dev_{context}"]
+= Accessing the Alerting UI from the Developer perspective
+// end::DEV[]
 
-* In the *Developer* perspective, go to *Observe* -> *<project_name>* -> *Alerts*. In this perspective, alerts, silences, and alerting rules are all managed from the *Alerts* page. The results shown in the *Alerts* page are specific to the selected project.
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::ADM[]
+:perspective: Administrator
+// end::ADM[]
+
+// tag::DEV[]
+:perspective: Developer
+// end::DEV[]
+
+The Alerting UI is accessible through the *{perspective}* perspective of the {product-title} web console.
+
+// tag::ADM[]
+* From the *Administrator* perspective, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages.
+// end::ADM[]
+
+// tag::DEV[]
+* From the *Developer* perspective, go to *Observe* and go to the *Alerts* tab.
+* Select the project that you want to manage alerts for from the *Project:* list. 
+
+In this perspective, alerts, silences, and alerting rules are all managed from the *Alerts* tab. The results shown in the *Alerts* tab are specific to the selected project.
 
 [NOTE]
 ====
 In the *Developer* perspective, you can select from core {product-title} and user-defined projects that you have access to in the *Project: <project_name>* list. However, alerts, silences, and alerting rules relating to core {product-title} projects are not displayed if you are not logged in as a cluster administrator.
 ====
+// end::DEV[]
+
+// Unset the source code block attributes just to be safe.
+:!perspective:
diff --git a/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc b/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc
index 9e01b79fc7c5..939b80561e5c 100644
--- a/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc
+++ b/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc
@@ -32,7 +32,7 @@ $ TOKEN=$(oc whoami -t)
 +
 [source,terminal]
 ----
-$ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.status.ingress[].host})
+$ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath='{.status.ingress[].host}')
 ----
 
 . Query the service API receivers for Alertmanager by running the following command:
diff --git a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc
index 17b599cd2cfe..383a6c45d3bb 100644
--- a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc
+++ b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc
@@ -2,64 +2,68 @@
 //
 // * observability/monitoring/configuring-the-monitoring-stack.adoc
 
-:_mod-docs-content-type: PROCEDURE
 [id="monitoring-adding-a-secret-to-the-alertmanager-configuration_{context}"]
-= Adding a secret to the Alertmanager configuration
+= Adding a secret to the Alertmanager configuration 
 
-ifndef::openshift-dedicated,openshift-rosa[]
-You can add secrets to the Alertmanager configuration for core platform monitoring components by editing the `cluster-monitoring-config` config map in the `openshift-monitoring` project.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-You can add secrets to the Alertmanager configuration for user-defined projects by editing the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project.
-endif::openshift-dedicated,openshift-rosa[]
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: alertmanagerMain
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: alertmanager
+// end::UWM[]
+
+You can add secrets to the Alertmanager configuration by editing the `{configmap-name}` config map in the `{namespace-name}` project.
 
 After you add a secret to the config map, the secret is mounted as a volume at `/etc/alertmanager/secrets/<secret_name>` within the `alertmanager` container for the Alertmanager pods.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` config map.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components in the `openshift-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` config map.
-** You have created the secret to be configured in Alertmanager in the `openshift-monitoring` project.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** You have created the secret to be configured in Alertmanager in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
-* You have created the secret to be configured in Alertmanager in the `openshift-user-workload-monitoring` project.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
+* You have created the secret to be configured in Alertmanager in the `{namespace-name}` project.
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object.
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To add a secret configuration to Alertmanager for core platform monitoring*:
-.. Edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add a `secrets:` section under `data/config.yaml/alertmanagerMain` with the following configuration:
+. Add a `secrets:` section under `data/config.yaml/{component}` with the following configuration:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    alertmanagerMain:
-      secrets: <1>
-      - <secret_name_1> <2>
+    {component}:
+      secrets: # <1>
+      - <secret_name_1> # <2>
       - <secret_name_2>
 ----
 <1> This section contains the secrets to be mounted into Alertmanager. The secrets must be located within the same namespace as the Alertmanager object.
@@ -67,67 +71,25 @@ data:
 +
 The following sample config map settings configure Alertmanager to use two `Secret` objects named `test-secret-basic-auth` and `test-secret-api-token`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    alertmanagerMain:
+    {component}:
       secrets:
       - test-secret-basic-auth
       - test-secret-api-token
 ----
 
-** *To add a secret configuration to Alertmanager for user-defined project monitoring*:
-endif::openshift-dedicated,openshift-rosa[]
-
-.. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add a `secrets:` section under `data/config.yaml/alertmanager/secrets` with the following configuration:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    alertmanager:
-      secrets: <1>
-      - <secret_name_1> <2>
-      - <secret_name_2>
-----
-<1> This section contains the secrets to be mounted into Alertmanager. The secrets must be located within the same namespace as the Alertmanager object.
-<2> The name of the `Secret` object that contains authentication credentials for the receiver. If you add multiple secrets, place each one on a new line.
-+
-The following sample config map settings configure Alertmanager to use two `Secret` objects named `test-secret` and `test-secret-api-token`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    alertmanager:
-      enabled: true
-      secrets:
-      - test-secret
-      - test-api-receiver-token
-----
-
 . Save the file to apply the changes. The new configuration is applied automatically.
 
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
+
diff --git a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc
index 947056f69d83..fdc40d052c6b 100644
--- a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc
+++ b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc
@@ -6,51 +6,63 @@
 [id="assigning-tolerations-to-monitoring-components_{context}"]
 = Assigning tolerations to monitoring components
 
-ifndef::openshift-dedicated,openshift-rosa[]
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples.
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: alertmanagerMain
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: thanosRuler
+// end::UWM[]
+
+// tag::CPM[]
 You can assign tolerations to any of the monitoring stack components to enable moving them to tainted nodes.
-endif::openshift-dedicated,openshift-rosa[]
+// end::CPM[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+// tag::UWM[]
 You can assign tolerations to the components that monitor user-defined projects, to enable moving them to tainted worker nodes. Scheduling is not permitted on control plane or infrastructure nodes.
-endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists in the `openshift-user-workload-monitoring` namespace. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To assign tolerations to a component that monitors core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Specify `tolerations` for the component:
+. Specify `tolerations` for the component:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
     <component>:
@@ -60,64 +72,18 @@ data:
 +
 Substitute `<component>` and `<toleration_specification>` accordingly.
 +
-For example, `oc adm taint nodes node1 key1=value1:NoSchedule` adds a taint to `node1` with the key `key1` and the value `value1`. This prevents monitoring components from deploying pods on `node1` unless a toleration is configured for that taint. The following example configures the `alertmanagerMain` component to tolerate the example taint:
+For example, `oc adm taint nodes node1 key1=value1:NoSchedule` adds a taint to `node1` with the key `key1` and the value `value1`. This prevents monitoring components from deploying pods on `node1` unless a toleration is configured for that taint. The following example configures the `{component}` component to tolerate the example taint:
 +
-[source,yaml,subs=quotes]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    alertmanagerMain:
-      tolerations:
-      - key: "key1"
-        operator: "Equal"
-        value: "value1"
-        effect: "NoSchedule"
-----
-
-** *To assign tolerations to a component that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Specify `tolerations` for the component:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>:
-      tolerations:
-        <toleration_specification>
-----
-+
-Substitute `<component>` and `<toleration_specification>` accordingly.
-+
-For example, `oc adm taint nodes node1 key1=value1:NoSchedule` adds a taint to `node1` with the key `key1` and the value `value1`. This prevents monitoring components from deploying pods on `node1` unless a toleration is configured for that taint. The following example configures the `thanosRuler` component to tolerate the example taint:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    thanosRuler:
+    {component}:
       tolerations:
       - key: "key1"
         operator: "Equal"
@@ -126,3 +92,8 @@ data:
 ----
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
\ No newline at end of file
diff --git a/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc b/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc
index e947f69ecc87..4a898913d870 100644
--- a/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc
+++ b/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc
@@ -6,106 +6,64 @@
 [id="attaching-additional-labels-to-your-time-series-and-alerts_{context}"]
 = Attaching additional labels to your time series and alerts
 
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: prometheus
+// end::UWM[]
+
 You can attach custom labels to all time series and alerts leaving Prometheus by using the external labels feature of Prometheus.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To attach custom labels to all time series and alerts leaving the Prometheus instance that monitors core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
-----
-
-.. Define a map of labels you want to add for every metric under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
-data:
-  config.yaml: |
-    prometheusK8s:
-      externalLabels:
-        <key>: <value> # <1>
-----
-+
-<1> Substitute `<key>: <value>` with a map of key-value pairs where `<key>` is a unique name for the new label and `<value>` is its value.
-+
-[WARNING]
-====
-* Do not use `prometheus` or `prometheus_replica` as key names, because they are reserved and will be overwritten.
-
-* Do not use `cluster` or `managed_cluster` as key names. Using them can cause issues where you are unable to see data in the developer dashboards.
-====
-+
-For example, to add metadata about the region and environment to all time series and alerts, use the following example:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
-data:
-  config.yaml: |
-    prometheusK8s:
-      externalLabels:
-        region: eu
-        environment: prod
-----
-
-.. Save the file to apply the changes. The new configuration is applied automatically.
-
-** *To attach custom labels to all time series and alerts leaving the Prometheus instance that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Define a map of labels you want to add for every metric under `data/config.yaml`:
+. Define labels you want to add for every metric under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheus:
+    {component}:
       externalLabels:
         <key>: <value> # <1>
 ----
-+
-<1> Substitute `<key>: <value>` with a map of key-value pairs where `<key>` is a unique name for the new label and `<value>` is its value.
+<1> Substitute `<key>: <value>` with key-value pairs where `<key>` is a unique name for the new label and `<value>` is its value.
 +
 [WARNING]
 ====
@@ -113,27 +71,34 @@ data:
 
 * Do not use `cluster` or `managed_cluster` as key names. Using them can cause issues where you are unable to see data in the developer dashboards.
 ====
+// tag::UWM[]
 +
 [NOTE]
 ====
 In the `openshift-user-workload-monitoring` project, Prometheus handles metrics and Thanos Ruler handles alerting and recording rules. Setting `externalLabels` for `prometheus` in the `user-workload-monitoring-config` `ConfigMap` object will only configure external labels for metrics and not for any rules.
 ====
+// end::UWM[]
 +
-For example, to add metadata about the region and environment to all time series and alerts related to user-defined projects, use the following example:
+For example, to add metadata about the region and environment to all time series and alerts, use the following example:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheus:
+    {component}:
       externalLabels:
         region: eu
         environment: prod
 ----
 
-.. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
diff --git a/modules/monitoring-choosing-a-metrics-collection-profile.adoc b/modules/monitoring-choosing-a-metrics-collection-profile.adoc
index 2ebf9722d235..af8199a5ebf6 100644
--- a/modules/monitoring-choosing-a-metrics-collection-profile.adoc
+++ b/modules/monitoring-choosing-a-metrics-collection-profile.adoc
@@ -6,6 +6,9 @@
 [id="choosing-a-metrics-collection-profile_{context}"]
 = Choosing a metrics collection profile
 
+:FeatureName: Metrics collection profile
+include::snippets/technology-preview.adoc[]
+
 To choose a metrics collection profile for core {product-title} monitoring components, edit the `cluster-monitoring-config` `ConfigMap` object.
 
 .Prerequisites
diff --git a/modules/monitoring-common-terms.adoc b/modules/monitoring-common-terms.adoc
index fb6bee41e943..e57dd7ac9e71 100644
--- a/modules/monitoring-common-terms.adoc
+++ b/modules/monitoring-common-terms.adoc
@@ -3,7 +3,7 @@
 // * observability/monitoring/monitoring-overview.adoc
 
 :_mod-docs-content-type: REFERENCE
-[id="openshift-monitoring-common-terms_{context}"]
+[id="monitoring-common-terms_{context}"]
 = Glossary of common terms for {product-title} monitoring
 
 This glossary defines common terms that are used in {product-title} architecture.
diff --git a/modules/monitoring-configurable-monitoring-components.adoc b/modules/monitoring-configurable-monitoring-components.adoc
index 173a0ad2e257..05c44693cbe5 100644
--- a/modules/monitoring-configurable-monitoring-components.adoc
+++ b/modules/monitoring-configurable-monitoring-components.adoc
@@ -2,53 +2,81 @@
 //
 // * observability/monitoring/configuring-the-monitoring-stack.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="configurable-monitoring-components_{context}"]
 = Configurable monitoring components
 
-This table shows the monitoring components you can configure and the keys used to specify the components in the
-ifndef::openshift-dedicated,openshift-rosa[]
-`cluster-monitoring-config` and
-endif::openshift-dedicated,openshift-rosa[]
-`user-workload-monitoring-config` `ConfigMap` objects.
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples.
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:alertmanager: alertmanagerMain
+:prometheus: prometheusK8s
+:thanosname: Thanos Querier
+:thanos: thanosQuerier
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:alertmanager: alertmanager
+:prometheus: prometheus
+:thanosname: Thanos Ruler
+:thanos: thanosRuler
+// end::UWM[]
+
+This table shows the monitoring components you can configure and the keys used to specify the components in the `{configmap-name}` config map.
 
+// tag::UWM[]
 ifdef::openshift-dedicated,openshift-rosa[]
 [WARNING]
 ====
-Do not modify the monitoring components in the `cluster-monitoring-config` `ConfigMap` object. Red Hat Site Reliability Engineers (SRE) use these components to monitor the core cluster components and Kubernetes services.
+Do not modify the monitoring components in the `cluster-monitoring-config` `ConfigMap` object. Red{nbsp}Hat Site Reliability Engineers (SRE) use these components to monitor the core cluster components and Kubernetes services.
 ====
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
-.Configurable monitoring components
+// tag::CPM[]
+.Configurable core platform monitoring components
+// end::CPM[]
+// tag::UWM[]
+.Configurable monitoring components for user-defined projects
+// end::UWM[]
 [options="header"]
 |====
-|Component |cluster-monitoring-config config map key |user-workload-monitoring-config config map key
-|Prometheus Operator |`prometheusOperator` |`prometheusOperator`
-|Prometheus |`prometheusK8s` |`prometheus`
-|Alertmanager |`alertmanagerMain` | `alertmanager`
-|kube-state-metrics |`kubeStateMetrics` |
-|monitoring-plugin | `monitoringPlugin` |
-|openshift-state-metrics |`openshiftStateMetrics` |
-|Telemeter Client |`telemeterClient` |
-|Metrics Server |`metricsServer` |
-|Thanos Querier |`thanosQuerier` |
-|Thanos Ruler | |`thanosRuler`
+|Component |{configmap-name} config map key
+|Prometheus Operator |`prometheusOperator`
+|Prometheus |`{prometheus}`
+|Alertmanager |`{alertmanager}`
+|{thanosname} | `{thanos}`
+// tag::CPM[]
+|kube-state-metrics |`kubeStateMetrics`
+|monitoring-plugin | `monitoringPlugin`
+|openshift-state-metrics |`openshiftStateMetrics`
+|Telemeter Client |`telemeterClient`
+|Metrics Server |`metricsServer`
+// end::CPM[]
 |====
 
-[NOTE]
+ifndef::openshift-dedicated,openshift-rosa[]
+[WARNING]
 ====
-The Prometheus key is called `prometheusK8s` in the `cluster-monitoring-config` `ConfigMap` object and `prometheus` in the `user-workload-monitoring-config` `ConfigMap` object.
+Different configuration changes to the `ConfigMap` object result in different outcomes:
+
+* The pods are not redeployed. Therefore, there is no service outage.
+
+* The affected pods are redeployed:
+
+** For single-node clusters, this results in temporary service outage.
+
+** For multi-node clusters, because of high-availability, the affected pods are gradually rolled out and the monitoring stack remains available.
+
+** Configuring and resizing a persistent volume always results in a service outage, regardless of high availability.
+
+Each procedure that requires a change in the config map includes its expected outcome.
 ====
 endif::openshift-dedicated,openshift-rosa[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
-.Configurable monitoring components
-[options="header"]
-|===
-|Component |user-workload-monitoring-config config map key
-|Alertmanager |`alertmanager`
-|Prometheus Operator |`prometheusOperator`
-|Prometheus |`prometheus`
-|Thanos Ruler |`thanosRuler`
-|===
-endif::openshift-dedicated,openshift-rosa[]
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!alertmanager:
+:!prometheus:
+:!thanosname:
+:!thanos:
diff --git a/modules/monitoring-configuring-a-persistent-volume-claim.adoc b/modules/monitoring-configuring-a-persistent-volume-claim.adoc
index 68a6a40c3d5c..0a382019fc98 100644
--- a/modules/monitoring-configuring-a-persistent-volume-claim.adoc
+++ b/modules/monitoring-configuring-a-persistent-volume-claim.adoc
@@ -4,142 +4,111 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="configuring-a-persistent-volume-claim_{context}"]
-
 = Configuring a persistent volume claim
 
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: thanosRuler
+// end::UWM[]
+
 To use a persistent volume (PV) for monitoring components, you must configure a persistent volume claim (PVC).
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To configure a PVC for a component that monitors core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add your PVC configuration for the component under `data/config.yaml`:
+. Add your PVC configuration for the component under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    <component>: #<1>
+    <component>: # <1>
       volumeClaimTemplate:
         spec:
-          storageClassName: <storage_class> #<2>
+          storageClassName: <storage_class> # <2>
           resources:
             requests:
-              storage: <amount_of_storage> #<3>
+              storage: <amount_of_storage> # <3>
 ----
-<1> Specify the core monitoring component for which you want to configure the PVC.
+<1> Specify the monitoring component for which you want to configure the PVC.
 <2> Specify an existing storage class. If a storage class is not specified, the default storage class is used.
 <3> Specify the amount of required storage.
 +
-See the link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[Kubernetes documentation on PersistentVolumeClaims] for information on how to specify `volumeClaimTemplate`.
-+
-The following example configures a PVC that claims persistent storage for the Prometheus instance that monitors core {product-title} components:
+The following example configures a PVC that claims persistent storage for 
+// tag::CPM[]
+Prometheus:
+// end::CPM[]
+// tag::UWM[]
+Thanos Ruler:
+// end::UWM[]
 +
-[source,yaml]
+.Example PVC configuration
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       volumeClaimTemplate:
         spec:
           storageClassName: my-storage-class
           resources:
             requests:
+# tag::CPM[]
               storage: 40Gi
-----
-
-** *To configure a PVC for a component that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add your PVC configuration for the component under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>: #<1>
-      volumeClaimTemplate:
-        spec:
-          storageClassName: <storage_class> #<2>
-          resources:
-            requests:
-              storage: <amount_of_storage> #<3>
-----
-<1> Specify the component for user-defined monitoring for which you want to configure the PVC.
-<2> Specify an existing storage class. If a storage class is not specified, the default storage class is used.
-<3> Specify the amount of required storage.
-+
-See the link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[Kubernetes documentation on PersistentVolumeClaims] for information on how to specify `volumeClaimTemplate`.
-+
-The following example configures a PVC that claims persistent storage for Thanos Ruler:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    thanosRuler:
-      volumeClaimTemplate:
-        spec:
-          storageClassName: my-storage-class
-          resources:
-            requests:
+# end::CPM[]
+# tag::UWM[]
               storage: 10Gi
+# end::UWM[]
 ----
+// tag::UWM[]
 +
 [NOTE]
 ====
 Storage requirements for the `thanosRuler` component depend on the number of rules that are evaluated and how many samples each rule generates.
 ====
+// end::UWM[]
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed and the new storage configuration is applied.
 +
@@ -147,3 +116,8 @@ Storage requirements for the `thanosRuler` component depend on the number of rul
 ====
 When you update the config map with a PVC configuration, the affected `StatefulSet` object is recreated, resulting in a temporary service outage.
 ====
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
diff --git a/modules/monitoring-configuring-alert-receivers.adoc b/modules/monitoring-configuring-alert-routing-console.adoc
similarity index 83%
rename from modules/monitoring-configuring-alert-receivers.adoc
rename to modules/monitoring-configuring-alert-routing-console.adoc
index c8d560794b80..f1b7fae98f95 100644
--- a/modules/monitoring-configuring-alert-receivers.adoc
+++ b/modules/monitoring-configuring-alert-routing-console.adoc
@@ -4,10 +4,15 @@
 // * post_installation_configuration/configuring-alert-notifications.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="configuring-alert-receivers_{context}"]
-= Configuring alert receivers
+[id="configuring-alert-routing-console_{context}"]
+= Configuring alert routing with the {product-title} web console
 
-You can configure alert receivers to ensure that you learn about important issues with your cluster.
+You can configure alert routing through the {product-title} web console to ensure that you learn about important issues with your cluster. 
+
+[NOTE]
+====
+The {product-title} web console provides fewer settings to configure alert routing than the `alertmanager-main` secret. To configure alert routing with the access to more configuration settings, see "Configuring alert routing for default platform alerts".
+====
 
 .Prerequisites
 
diff --git a/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc b/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc
similarity index 91%
rename from modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc
rename to modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc
index d029f9f22b1d..859e6c7d2b20 100644
--- a/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc
+++ b/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc
@@ -3,14 +3,14 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="configuring-notifications-for-default-platform-alerts_{context}"]
-= Configuring notifications for default platform alerts
+[id="configuring-alert-routing-default-platform-alerts_{context}"]
+= Configuring alert routing for default platform alerts
 
 You can configure Alertmanager to send notifications. Customize where and how Alertmanager sends notifications about default platform alerts by editing the default configuration in the `alertmanager-main` secret in the `openshift-monitoring` namespace.
 
-[IMPORTANT]
+[NOTE]
 ====
-Alertmanager does not send notifications by default. It is recommended to configure Alertmanager to receive notifications by setting up notifications details in the `alertmanager-main` secret configuration file.
+All features of a supported version of upstream Alertmanager are also supported in an {product-title} Alertmanager configuration. To check all the configuration options of a supported version of upstream Alertmanager, see link:https://prometheus.io/docs/alerting/0.27/configuration/[Alertmanager configuration] (Prometheus documentation).
 ====
 
 .Prerequisites
diff --git a/modules/monitoring-creating-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc
similarity index 78%
rename from modules/monitoring-creating-alert-routing-for-user-defined-projects.adoc
rename to modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc
index 691f8d8e1c43..3c6d6f5ddee8 100644
--- a/modules/monitoring-creating-alert-routing-for-user-defined-projects.adoc
+++ b/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc
@@ -3,10 +3,9 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="creating-alert-routing-for-user-defined-projects_{context}"]
-= Creating alert routing for user-defined projects
+[id="configuring-alert-routing-for-user-defined-projects_{context}"]
+= Configuring alert routing for user-defined projects
 
-[role="_abstract"]
 If you are a non-administrator user who has been given the `alert-routing-edit` cluster role, you can create or edit alert routing for user-defined projects.
 
 .Prerequisites
@@ -43,13 +42,7 @@ spec:
     webhookConfigs:
     - url: https://example.org/post
 ----
-+
-[NOTE]
-====
-For user-defined alerting rules, user-defined routing is scoped to the namespace in which the resource is defined.
-For example, a routing configuration defined in the `AlertmanagerConfig` object for namespace `ns1` only applies to `PrometheusRules` resources in the same namespace.
-====
-+
+
 . Save the file.
 
 . Apply the resource to the cluster:
diff --git a/modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc b/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc
similarity index 74%
rename from modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc
rename to modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc
index d8852a26d3bd..a2b4197754c4 100644
--- a/modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc
+++ b/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc
@@ -3,19 +3,25 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="configuring-notifications-for-user-defined-alerts_{context}"]
-= Configuring notifications for user-defined alerts
+[id="configuring-alert-routing-user-defined-alerts-secret_{context}"]
+= Configuring alert routing for user-defined projects with the Alertmanager secret
 
 If you have enabled a separate instance of Alertmanager that is dedicated to user-defined alert routing, you can customize where and how the instance sends notifications by editing the `alertmanager-user-workload` secret in the `openshift-user-workload-monitoring` namespace.
 
+[NOTE]
+====
+All features of a supported version of upstream Alertmanager are also supported in an {product-title} Alertmanager configuration. To check all the configuration options of a supported version of upstream Alertmanager, see link:https://prometheus.io/docs/alerting/0.27/configuration/[Alertmanager configuration] (Prometheus documentation).
+====
+
 .Prerequisites
 
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have enabled a separate instance of Alertmanager for user-defined alert routing.
+endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-rosa,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 endif::[]
-ifndef::openshift-rosa,openshift-dedicated[]
-* You have access to the cluster as a user with the `cluster-admin` cluster role.
-endif::[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/monitoring-configuring-external-alertmanagers.adoc b/modules/monitoring-configuring-external-alertmanagers.adoc
index c3918c134ab5..5619c62b23a3 100644
--- a/modules/monitoring-configuring-external-alertmanagers.adoc
+++ b/modules/monitoring-configuring-external-alertmanagers.adoc
@@ -6,141 +6,103 @@
 [id="monitoring-configuring-external-alertmanagers_{context}"]
 = Configuring external Alertmanager instances
 
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+:component-name: Prometheus
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: thanosRuler
+:component-name: Thanos Ruler
+// end::UWM[]
+
 The {product-title} monitoring stack includes a local Alertmanager instance that routes alerts from Prometheus.
-ifndef::openshift-dedicated,openshift-rosa[]
-You can add external Alertmanager instances to route alerts for core {product-title} projects or user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+
+// tag::CPM[]
+You can add external Alertmanager instances to route alerts for core {product-title} projects.
+// end::CPM[]
+// tag::UWM[]
 You can add external Alertmanager instances to route alerts for user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 
 If you add the same external Alertmanager configuration for multiple clusters and disable the local instance for each cluster, you can then manage alert routing for multiple clusters by using a single external Alertmanager instance.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components in the `openshift-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` config map.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object.
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To configure additional Alertmanagers for routing alerts from core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add an `additionalAlertmanagerConfigs:` section under `data/config.yaml/prometheusK8s`.
-
-.. Add the configuration details for additional Alertmanagers in this section:
+. Add an `additionalAlertmanagerConfigs` section with configuration details under 
+// tag::CPM[]
+`data/config.yaml/prometheusK8s`:
+// end::CPM[]
+// tag::UWM[]
+`data/config.yaml/<component>`:
+// end::UWM[]
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
+# tag::CPM[]
     prometheusK8s:
+# end::CPM[]
+# tag::UWM[]
+    <component>: # <2>
+# end::UWM[]
       additionalAlertmanagerConfigs:
-      - <alertmanager_specification>
+      - <alertmanager_specification> # <1>
 ----
-+
-For `<alertmanager_specification>`, substitute authentication and other configuration details for additional Alertmanager instances.
+<1> Substitute `<alertmanager_specification>` with authentication and other configuration details for additional Alertmanager instances.
 Currently supported authentication methods are bearer token (`bearerToken`) and client TLS (`tlsConfig`).
-The following sample config map configures an additional Alertmanager using a bearer token with client TLS authentication:
+// tag::UWM[]
+<2> Substitute `<component>` for one of two supported external Alertmanager components: `prometheus` or `thanosRuler`.
+// end::UWM[]
 +
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
-data:
-  config.yaml: |
-    prometheusK8s:
-      additionalAlertmanagerConfigs:
-      - scheme: https
-        pathPrefix: /
-        timeout: "30s"
-        apiVersion: v1
-        bearerToken:
-          name: alertmanager-bearer-token
-          key: token
-        tlsConfig:
-          key:
-            name: alertmanager-tls
-            key: tls.key
-          cert:
-            name: alertmanager-tls
-            key: tls.crt
-          ca:
-            name: alertmanager-tls
-            key: tls.ca
-        staticConfigs:
-        - external-alertmanager1-remote.com
-        - external-alertmanager1-remote2.com
-----
-
-** *To configure additional Alertmanager instances for routing alerts from user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-
-.. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
+The following sample config map configures an additional Alertmanager for {component-name} by using a bearer token with client TLS authentication:
 +
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add a `<component>/additionalAlertmanagerConfigs:` section under `data/config.yaml/`.
-
-.. Add the configuration details for additional Alertmanagers in this section:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>:
-      additionalAlertmanagerConfigs:
-      - <alertmanager_specification>
-----
-+
-For `<component>`, substitute one of two supported external Alertmanager components: `prometheus` or `thanosRuler`.
-+
-For `<alertmanager_specification>`, substitute authentication and other configuration details for additional Alertmanager instances. Currently supported authentication methods are bearer token (`bearerToken`) and client TLS (`tlsConfig`). The following sample config map configures an additional Alertmanager using Thanos Ruler with a bearer token and client TLS authentication:
-+
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    thanosRuler:
+    {component}:
       additionalAlertmanagerConfigs:
       - scheme: https
         pathPrefix: /
@@ -164,4 +126,10 @@ data:
         - external-alertmanager1-remote2.com
 ----
 
-. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
\ No newline at end of file
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
+:!component-name:
\ No newline at end of file
diff --git a/modules/monitoring-configuring-metrics-collection-profiles.adoc b/modules/monitoring-configuring-metrics-collection-profiles.adoc
index 63a30051f1c2..ac518fe893e5 100644
--- a/modules/monitoring-configuring-metrics-collection-profiles.adoc
+++ b/modules/monitoring-configuring-metrics-collection-profiles.adoc
@@ -4,17 +4,10 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="configuring-metrics-collection-profiles_{context}"]
-= Configuring metrics collection profiles
+= About metrics collection profiles
 
-[IMPORTANT]
-====
-[subs="attributes+"]
-Using a metrics collection profile is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete.
-Red Hat does not recommend using them in production.
-These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
-
-For more information about the support scope of Red Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview[https://access.redhat.com/support/offerings/techpreview].
-====
+:FeatureName: Metrics collection profile
+include::snippets/technology-preview.adoc[]
 
 By default, Prometheus collects metrics exposed by all default metrics targets in {product-title} components.
 However, you might want Prometheus to collect fewer metrics from a cluster in certain scenarios:
@@ -26,9 +19,6 @@ You can use a metrics collection profile to collect either the default amount of
 When you collect minimal metrics data, basic monitoring features such as alerting continue to work.
 At the same time, the CPU and memory resources required by Prometheus decrease.
 
-[id="about-metrics-collection-profiles_{context}"]
-== About metrics collection profiles
-
 You can enable one of two metrics collection profiles:
 
 * *full*: Prometheus collects metrics data exposed by all platform components. This setting is the default.
diff --git a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
index 812bc588a66a..c39fb11e5d63 100644
--- a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
+++ b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
@@ -6,60 +6,72 @@
 [id="configuring-pod-topology-spread-constraints_{context}"]
 = Configuring pod topology spread constraints
 
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+:component-name: Prometheus
+:label: prometheus
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: thanosRuler
+:component-name: Thanos Ruler
+:label: thanos-ruler
+// end::UWM[]
+
 You can configure pod topology spread constraints for 
-ifndef::openshift-dedicated,openshift-rosa[]
+// tag::CPM[]
 all the pods deployed by the {cmo-full}
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+// end::CPM[]
+// tag::UWM[]
 all the pods for user-defined monitoring
-endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 to control how pod replicas are scheduled to nodes across zones.
 This ensures that the pods are highly available and run more efficiently, because workloads are spread across nodes in different data centers or hierarchical infrastructure zones.
 
-You can configure pod topology spread constraints for monitoring pods by using 
-ifndef::openshift-dedicated,openshift-rosa[]
-the `cluster-monitoring-config` or 
-endif::openshift-dedicated,openshift-rosa[]
-the `user-workload-monitoring-config` config map.
+You can configure pod topology spread constraints for monitoring pods by using the `{configmap-name}` config map.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring pods for core {product-title} monitoring:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring pods for user-defined monitoring:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
+
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
-
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-ifndef::openshift-dedicated,openshift-rosa[]
-* *To configure pod topology spread constraints for core {product-title} monitoring:*
-
-. Edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
 . Add the following settings under the `data/config.yaml` field to configure pod topology spread constraints:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
     <component>: # <1>
@@ -82,87 +94,36 @@ Specify `ScheduleAnyway` if you want the scheduler to still schedule the pod but
 <5> Specify `labelSelector` to find matching pods. 
 Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.
 +
-.Example configuration for Prometheus
-[source,yaml]
+.Example configuration for {component-name}
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       topologySpreadConstraints:
       - maxSkew: 1
         topologyKey: monitoring
+# tag::CPM[]
         whenUnsatisfiable: DoNotSchedule
-        labelSelector:
-          matchLabels:
-            app.kubernetes.io/name: prometheus
-----
-
-. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
-
-* *To configure pod topology spread constraints for user-defined monitoring:*
-endif::openshift-dedicated,openshift-rosa[]
-
-. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-. Add the following settings under the `data/config.yaml` field to configure pod topology spread constraints:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>: # <1>
-      topologySpreadConstraints:
-      - maxSkew: <n> # <2>
-        topologyKey: <key> # <3>
-        whenUnsatisfiable: <value> # <4>
-        labelSelector: # <5>
-          <match_option>
-----
-<1> Specify a name of the component for which you want to set up pod topology spread constraints.
-<2> Specify a numeric value for `maxSkew`, which defines the degree to which pods are allowed to be unevenly distributed.
-<3> Specify a key of node labels for `topologyKey`.
-Nodes that have a label with this key and identical values are considered to be in the same topology.
-The scheduler tries to put a balanced number of pods into each domain.
-<4> Specify a value for `whenUnsatisfiable`.
-Available options are `DoNotSchedule` and `ScheduleAnyway`.
-Specify `DoNotSchedule` if you want the `maxSkew` value to define the maximum difference allowed between the number of matching pods in the target topology and the global minimum.
-Specify `ScheduleAnyway` if you want the scheduler to still schedule the pod but to give higher priority to nodes that might reduce the skew.
-<5> Specify `labelSelector` to find matching pods. 
-Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.
-+
-.Example configuration for Thanos Ruler
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    thanosRuler:
-      topologySpreadConstraints:
-      - maxSkew: 1
-        topologyKey: monitoring
+# end::CPM[]
+# tag::UWM[]
         whenUnsatisfiable: ScheduleAnyway
+# end::UWM[]
         labelSelector:
           matchLabels:
-            app.kubernetes.io/name: thanos-ruler
+            app.kubernetes.io/name: {label}
 ----
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
+:!component-name:
+:!label:
\ No newline at end of file
diff --git a/modules/monitoring-configuring-remote-write-storage.adoc b/modules/monitoring-configuring-remote-write-storage.adoc
index d7fbff7e7135..583d11f44d2f 100644
--- a/modules/monitoring-configuring-remote-write-storage.adoc
+++ b/modules/monitoring-configuring-remote-write-storage.adoc
@@ -6,22 +6,36 @@
 [id="configuring-remote-write-storage_{context}"]
 = Configuring remote write storage
 
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: prometheus
+// end::UWM[]
+
 You can configure remote write storage to enable Prometheus to send ingested metrics to remote systems for long-term storage. Doing so has no impact on how or for how long Prometheus stores metrics.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 * You have set up a remote write compatible endpoint (such as Thanos) and know the endpoint URL. See the link:https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage[Prometheus remote endpoints and storage documentation] for information about endpoints that are compatible with the remote write feature.
 +
@@ -29,13 +43,7 @@ endif::openshift-dedicated,openshift-rosa[]
 ====
 Red{nbsp}Hat only provides information for configuring remote write senders and does not offer guidance on configuring receiver endpoints. Customers are responsible for setting up their own endpoints that are remote-write compatible. Issues with endpoint receiver configurations are not included in Red{nbsp}Hat production support.
 ====
-* You have set up authentication credentials in a `Secret` object for the remote write endpoint. You must create the secret in the
-ifndef::openshift-dedicated,openshift-rosa[]
-same namespace as the Prometheus object for which you configure remote write: the `openshift-monitoring` namespace for default platform monitoring or the `openshift-user-workload-monitoring` namespace for user workload monitoring.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-`openshift-user-workload-monitoring` namespace.
-endif::openshift-dedicated,openshift-rosa[]
+* You have set up authentication credentials in a `Secret` object for the remote write endpoint. You must create the secret in the `{namespace-name}` namespace.
 +
 [WARNING]
 ====
@@ -44,49 +52,46 @@ To reduce security risks, use HTTPS and authentication to send metrics to an end
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To configure remote write for the Prometheus instance that monitors core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add a `remoteWrite:` section under `data/config.yaml/prometheusK8s`, as shown in the following example:
+. Add a `remoteWrite:` section under `data/config.yaml/{component}`, as shown in the following example:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       remoteWrite:
-      - url: "https://remote-write-endpoint.example.com" #<1>
-        <endpoint_authentication_credentials> #<2>
+      - url: "https://remote-write-endpoint.example.com" # <1>
+        <endpoint_authentication_credentials> # <2>
 ----
 <1> The URL of the remote write endpoint.
 <2> The authentication method and credentials for the endpoint.
 Currently supported authentication methods are AWS Signature Version 4, authentication using HTTP in an `Authorization` request header, Basic authentication, OAuth 2.0, and TLS client.
 See _Supported remote write authentication settings_ for sample configurations of supported authentication methods.
 
-.. Add write relabel configuration values after the authentication credentials:
+. Add write relabel configuration values after the authentication credentials:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         <endpoint_authentication_credentials>
@@ -96,16 +101,16 @@ data:
 <1> Add configuration for metrics that you want to send to the remote endpoint.
 +
 .Example of forwarding a single metric called `my_metric`
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         writeRelabelConfigs:
@@ -115,104 +120,16 @@ data:
 ----
 +
 .Example of forwarding metrics called `my_metric_1` and `my_metric_2` in `my_namespace` namespace
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com"
-        writeRelabelConfigs:
-        - sourceLabels: [__name__,namespace]
-          regex: '(my_metric_1|my_metric_2);my_namespace'
-          action: keep 
-----
-
-** *To configure remote write for the Prometheus instance that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add a `remoteWrite:` section under `data/config.yaml/prometheus`, as shown in the following example:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com" #<1>
-        <endpoint_authentication_credentials> #<2>
-----
-<1> The URL of the remote write endpoint.
-<2> The authentication method and credentials for the endpoint.
-Currently supported authentication methods are AWS Signature Version 4, authentication using HTTP an `Authorization` request header, basic authentication, OAuth 2.0, and TLS client.
-See _Supported remote write authentication settings_ below for sample configurations of supported authentication methods.
-
-.. Add write relabel configuration values after the authentication credentials:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com"
-        <endpoint_authentication_credentials>
-        writeRelabelConfigs:
-        - <your_write_relabel_configs> #<1>
-----
-<1> Add configuration for metrics that you want to send to the remote endpoint.
-+
-.Example of forwarding a single metric called `my_metric`
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com"
-        writeRelabelConfigs:
-        - sourceLabels: [__name__]
-          regex: 'my_metric'
-          action: keep
-----
-+
-.Example of forwarding metrics called `my_metric_1` and `my_metric_2` in `my_namespace` namespace
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         writeRelabelConfigs:
@@ -222,3 +139,8 @@ data:
 ----
 
 . Save the file to apply the changes. The new configuration is applied automatically.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
\ No newline at end of file
diff --git a/modules/monitoring-configuring-shiftstack-remotewrite.adoc b/modules/monitoring-configuring-shiftstack-remotewrite.adoc
new file mode 100644
index 000000000000..85929f3be14e
--- /dev/null
+++ b/modules/monitoring-configuring-shiftstack-remotewrite.adoc
@@ -0,0 +1,162 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/shiftstack-prometheus-configuration.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="monitoring-configuring-shiftstack-remotewrite_{context}"]
+= Remote writing to an external Prometheus instance
+
+Use remote write with both {rhoso-first} and {product-title} to push their metrics to an external Prometheus instance.
+
+.Prerequisites
+
+- You have access to an external Prometheus instance.
+- You have administrative access to {rhoso} and your cluster.
+- You have certificates for secure communication with mTLS.
+- Your Prometheus instance is configured for client TLS certificates and has been set up as a remote write receiver.
+- The Cluster Observability Operator is installed on your {rhoso} cluster.
+- The monitoring stack for your {rhoso} cluster is configured to collect the metrics that you are interested in.
+- Telemetry is enabled in the {rhoso} environment.
++
+[NOTE]
+====
+To verify that the telemetry service is operating normally, entering the following command:
+[source,shell]
+----
+$ oc -n openstack get monitoringstacks metric-storage -o yaml
+----
+The `monitoringstacks` CRD indicates whether telemetry is enabled correctly.
+====
+
+.Procedure
+
+// Steps 1, 2, 3, and 4 run on the OpenShift cluster hosting the RHOSO control plane. This configure RHOSO to send their metrics to an external prometheus.
+//
+// Steps 5, 6, 7, and 8 run on the tenant's OpenShift cluster. This configures the tenant OpenShift cluster to send their metrics to the same Prometheus instance.
+// Comment from before moving telemetry check to prereqs -- offset by 1.
+
+// on mgmt cluster
+
+. Configure your {rhoso} management cluster to send metrics to Prometheus:
+
+.. Create a secret that is named `mtls-bundle` in the `openstack` namespace that contains HTTPS client certificates for authentication to Prometheus by entering the following command:
++
+[source,shell]
+----
+$ oc --namespace openstack \
+    create secret generic mtls-bundle \
+        --from-file=./ca.crt \
+        --from-file=osp-client.crt \
+        --from-file=osp-client.key
+----
+
+.. Open the `controlplane` configuration for editing by running the following command:
++
+[source,shell]
+----
+$ oc -n openstack edit openstackcontrolplane/controlplane
+----
+
+.. With the configuration open, replace the `.spec.telemetry.template.metricStorage` section so that {rhoso} sends metrics to Prometheus. As an example:
++
+[source,yaml]
+----
+      metricStorage:
+        customMonitoringStack:
+          alertmanagerConfig:
+            disabled: false
+          logLevel: info
+          prometheusConfig:
+            scrapeInterval: 30s
+            remoteWrite:
+            - url: https://external-prometheus.example.com/api/v1/write # <1>
+              tlsConfig:
+                ca:
+                  secret:
+                    name: mtls-bundle
+                    key: ca.crt
+                cert:
+                  secret:
+                    name: mtls-bundle
+                    key: ocp-client.crt
+                keySecret:
+                  name: mtls-bundle
+                  key: ocp-client.key
+            replicas: 2
+          resourceSelector:
+            matchLabels:
+              service: metricStorage
+          resources:
+            limits:
+              cpu: 500m
+              memory: 512Mi
+            requests:
+              cpu: 100m
+              memory: 256Mi
+          retention: 1d # <2>
+        dashboardsEnabled: false
+        dataplaneNetwork: ctlplane
+        enabled: true
+        prometheusTls: {}
+----
+<1> Replace this URL with the URL of your Prometheus instance.
+<2> Set a retention period. Optionally, you can reduce retention for local metrics because of external collection.
+// run on tenant's openshift cluster
+. Configure the tenant cluster on which your workloads run to send metrics to Prometheus:
+
+.. Create a cluster monitoring config map as a YAML file. The map must include a remote write configuration and cluster identifiers. As an example:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: cluster-monitoring-config
+  namespace: openshift-monitoring
+data:
+  config.yaml: |
+    prometheusK8s:
+      retention: 1d # <1>
+      remoteWrite:
+      - url: "https://external-prometheus.example.com/api/v1/write"
+        writeRelabelConfigs:
+        - sourceLabels:
+          - __tmp_openshift_cluster_id__
+          targetLabel: cluster_id
+          action: replace
+        tlsConfig:
+          ca:
+            secret:
+              name: mtls-bundle
+              key: ca.crt
+          cert:
+            secret:
+              name: mtls-bundle
+              key: ocp-client.crt
+          keySecret:
+            name: mtls-bundle
+            key: ocp-client.key
+----
+<1> Set a retention period. Optionally, you can reduce retention for local metrics because of external collection.
+
+.. Save the config map as a file called `cluster-monitoring-config.yaml`.
+
+.. Create a secret that is named `mtls-bundle` in the `openshift-monitoring` namespace that contains HTTPS client certificates for authentication to Prometheus by entering the following command:
++
+[source,terminal]
+----
+$ oc --namespace openshift-monitoring \
+    create secret generic mtls-bundle \
+        --from-file=./ca.crt \
+        --from-file=ocp-client.crt \
+        --from-file=ocp-client.key
+----
+
+.. Apply the cluster monitoring configuration by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f cluster-monitoring-config.yaml
+----
+
+After the changes propagate, you can see aggregated metrics in your external Prometheus instance.
\ No newline at end of file
diff --git a/modules/monitoring-configuring-shiftstack-scraping.adoc b/modules/monitoring-configuring-shiftstack-scraping.adoc
new file mode 100644
index 000000000000..c2e6354fb11c
--- /dev/null
+++ b/modules/monitoring-configuring-shiftstack-scraping.adoc
@@ -0,0 +1,83 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/shiftstack-prometheus-configuration.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="monitoring-configuring-shiftstack-scraping_{context}"]
+= Collecting cluster metrics from the federation endpoint
+
+You can employ the federation endpoint of your {product-title} cluster to make metrics available to a {rhoso-first} cluster to practice pull-based monitoring.
+
+.Prerequisites
+
+- You have administrative access to {rhoso} and the tenant cluster that is running on it.
+- Telemetry is enabled in the {rhoso} environment.
+- The Cluster Observability Operator is installed on your cluster.
+- The monitoring stack for your cluster is configured.
+- Your cluster has its federation endpoint exposed.
+
+.Procedure
+
+. Connect to your cluster by using a username and password; do not log in by using a `kubeconfig` file that was generated by the installation program.
+
+. To retrieve a token from the {product-title} cluster, run the following command on it:
++
+[source,terminal]
+----
+$ oc whoami -t
+----
+
+. Make the token available as a secret in the `openstack` namespace in the {rhoso} management cluster by running the following command:
++
+[source,terminal]
+----
+$ oc -n openstack create secret generic ocp-federated --from-literal=token=<the_token_fetched_previously>
+----
+
+. To get the Prometheus federation route URL from your {product-title} cluster, run the following command:
++
+[source,terminal]
+----
+$ oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath={'.status.ingress[].host'}
+----
+
+. Write a manifest for a scrape configuration and save it as a file called `cluster-scrape-config.yaml`. As an example:
++
+[source,yaml]
+----
+apiVersion: monitoring.rhobs/v1alpha1
+kind: ScrapeConfig
+metadata:
+  labels:
+    service: metricStorage
+  name: sos1-federated
+  namespace: openstack
+spec:
+  params:
+    'match[]':
+    - '{__name__=~"kube_node_info|kube_persistentvolume_info|cluster:master_nodes"}' # <1>
+  metricsPath: '/federate'
+  authorization:
+    type: Bearer
+    credentials:
+      name: ocp-federated # <2>
+      key: token
+  scheme: HTTPS # or HTTP
+  scrapeInterval: 30s # <3>
+  staticConfigs:
+  - targets:
+    - prometheus-k8s-federate-openshift-monitoring.apps.openshift.example # <4>
+----
+<1> Add metrics here. In this example, only the metrics `kube_node_info`, `kube_persistentvolume_info`, and `cluster:master_nodes` are requested.
+<2> Insert the previously generated secret name here.
+<3> Limit scraping to fewer than 1000 samples for each request with a maximum frequency of once every 30 seconds.
+<4> Insert the URL you fetched previously here. If the endpoint is HTTPS and uses a custom certificate authority, add a `tlsConfig` section after it.
+
+. While connected to the {rhoso} management cluster, apply the manifest by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f cluster-scrape-config.yaml
+----
+
+After the config propagates, the cluster metrics are accessible for querying in the {product-title} UI in RHOSO.
diff --git a/modules/monitoring-limiting-scrape-samples-in-user-defined-projects.adoc b/modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc
similarity index 100%
rename from modules/monitoring-limiting-scrape-samples-in-user-defined-projects.adoc
rename to modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc
diff --git a/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc b/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc
index 703d00388835..61100fca2561 100644
--- a/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc
+++ b/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc
@@ -59,3 +59,64 @@ $ oc -n ns1-coo get monitoringstack
 NAME                         AGE
 example-coo-monitoring-stack   81m
 ----
+
+. Run the following comand to retrieve information about the active targets from Prometheus and filter the output to list only targets labeled with `app=prometheus-coo-example-app`. This verifies which targets are discovered and actively monitored by Prometheus with this specific label.
++
+[source,terminal]
+----
+$ oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/targets' | jq '.data.activeTargets[].discoveredLabels | select(.__meta_kubernetes_endpoints_label_app=="prometheus-coo-example-app")'
+----
++
+.Example output
+[source,json]
+----
+{
+  "__address__": "10.129.2.25:8080",
+  "__meta_kubernetes_endpoint_address_target_kind": "Pod",
+  "__meta_kubernetes_endpoint_address_target_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
+  "__meta_kubernetes_endpoint_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz",
+  "__meta_kubernetes_endpoint_port_name": "web",
+  "__meta_kubernetes_endpoint_port_protocol": "TCP",
+  "__meta_kubernetes_endpoint_ready": "true",
+  "__meta_kubernetes_endpoints_annotation_endpoints_kubernetes_io_last_change_trigger_time": "2024-11-05T11:24:09Z",
+  "__meta_kubernetes_endpoints_annotationpresent_endpoints_kubernetes_io_last_change_trigger_time": "true",
+  "__meta_kubernetes_endpoints_label_app": "prometheus-coo-example-app",
+  "__meta_kubernetes_endpoints_labelpresent_app": "true",
+  "__meta_kubernetes_endpoints_name": "prometheus-coo-example-app",
+  "__meta_kubernetes_namespace": "ns1-coo",
+  "__meta_kubernetes_pod_annotation_k8s_ovn_org_pod_networks": "{\"default\":{\"ip_addresses\":[\"10.129.2.25/23\"],\"mac_address\":\"0a:58:0a:81:02:19\",\"gateway_ips\":[\"10.129.2.1\"],\"routes\":[{\"dest\":\"10.128.0.0/14\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"172.30.0.0/16\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"100.64.0.0/16\",\"nextHop\":\"10.129.2.1\"}],\"ip_address\":\"10.129.2.25/23\",\"gateway_ip\":\"10.129.2.1\",\"role\":\"primary\"}}",
+  "__meta_kubernetes_pod_annotation_k8s_v1_cni_cncf_io_network_status": "[{\n    \"name\": \"ovn-kubernetes\",\n    \"interface\": \"eth0\",\n    \"ips\": [\n        \"10.129.2.25\"\n    ],\n    \"mac\": \"0a:58:0a:81:02:19\",\n    \"default\": true,\n    \"dns\": {}\n}]",
+  "__meta_kubernetes_pod_annotation_openshift_io_scc": "restricted-v2",
+  "__meta_kubernetes_pod_annotation_seccomp_security_alpha_kubernetes_io_pod": "runtime/default",
+  "__meta_kubernetes_pod_annotationpresent_k8s_ovn_org_pod_networks": "true",
+  "__meta_kubernetes_pod_annotationpresent_k8s_v1_cni_cncf_io_network_status": "true",
+  "__meta_kubernetes_pod_annotationpresent_openshift_io_scc": "true",
+  "__meta_kubernetes_pod_annotationpresent_seccomp_security_alpha_kubernetes_io_pod": "true",
+  "__meta_kubernetes_pod_controller_kind": "ReplicaSet",
+  "__meta_kubernetes_pod_controller_name": "prometheus-coo-example-app-5d8cd498c7",
+  "__meta_kubernetes_pod_host_ip": "10.0.128.2",
+  "__meta_kubernetes_pod_ip": "10.129.2.25",
+  "__meta_kubernetes_pod_label_app": "prometheus-coo-example-app",
+  "__meta_kubernetes_pod_label_pod_template_hash": "5d8cd498c7",
+  "__meta_kubernetes_pod_labelpresent_app": "true",
+  "__meta_kubernetes_pod_labelpresent_pod_template_hash": "true",
+  "__meta_kubernetes_pod_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
+  "__meta_kubernetes_pod_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz",
+  "__meta_kubernetes_pod_phase": "Running",
+  "__meta_kubernetes_pod_ready": "true",
+  "__meta_kubernetes_pod_uid": "054c11b6-9a76-4827-a860-47f3a4596871",
+  "__meta_kubernetes_service_label_app": "prometheus-coo-example-app",
+  "__meta_kubernetes_service_labelpresent_app": "true",
+  "__meta_kubernetes_service_name": "prometheus-coo-example-app",
+  "__metrics_path__": "/metrics",
+  "__scheme__": "http",
+  "__scrape_interval__": "30s",
+  "__scrape_timeout__": "10s",
+  "job": "serviceMonitor/ns1-coo/prometheus-coo-example-monitor/0"
+}
+----
++
+[NOTE]
+====
+The above example uses link:https://jqlang.github.io/jq/[`jq` command-line JSON processor] to format the output for convenience.
+====
diff --git a/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc
index e69f2455ff39..84364167cb63 100644
--- a/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc
+++ b/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc
@@ -16,7 +16,7 @@ To help users understand the impact and cause of the alert, ensure that your ale
 .Prerequisites
 
 * You have enabled monitoring for user-defined projects.
-* You are logged in as a user that has the `monitoring-rules-edit` cluster role for the project where you want to create an alerting rule.
+* You are logged in as a cluster administrator or as a user that has the `monitoring-rules-edit` cluster role for the project where you want to create an alerting rule.
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc
index b4e4aed3a113..1df3b1ec7a61 100644
--- a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc
+++ b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc
@@ -6,95 +6,99 @@
 [id="creating-cluster-id-labels-for-metrics_{context}"]
 = Creating cluster ID labels for metrics
 
-ifndef::openshift-dedicated,openshift-rosa[]
-You can create cluster ID labels for metrics for default platform monitoring and for user workload monitoring.
-
-For default platform monitoring, you add cluster ID labels for metrics in the `write_relabel` settings for remote write storage in the `cluster-monitoring-config` config map in the `openshift-monitoring` namespace.
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: prometheus
+// end::UWM[]
 
-For user workload monitoring, you edit the settings in the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` namespace.
+You can create cluster ID labels for metrics by adding the `write_relabel` settings for remote write storage in the `{configmap-name}` config map in the `{namespace-name}` namespace.
 
+ifndef::openshift-dedicated,openshift-rosa[]
+// tag::UWM[]
 [NOTE]
 ====
 When Prometheus scrapes user workload targets that expose a `namespace` label, the system stores this label as `exported_namespace`. 
 This behavior ensures that the final namespace label value is equal to the namespace of the target pod.
 You cannot override this default configuration by setting the value of the `honorLabels` field to `true` for `PodMonitor` or `ServiceMonitor` objects.
 ====
-
-endif::openshift-dedicated,openshift-rosa[]
-
-ifdef::openshift-dedicated,openshift-rosa[]
-You can create cluster ID labels for metrics by editing the settings in the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` namespace.
+// end::UWM[]
 endif::openshift-dedicated,openshift-rosa[]
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring default platform monitoring components:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects:*
-** You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` ConfigMap object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 * You have configured remote write storage.
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To create cluster ID labels for core {product-title} metrics:*
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. In the `writeRelabelConfigs:` section under `data/config.yaml/prometheusK8s/remoteWrite`, add cluster ID relabel configuration values:
+. In the `writeRelabelConfigs:` section under `data/config.yaml/{component}/remoteWrite`, add cluster ID relabel configuration values:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         <endpoint_authentication_credentials>
-        writeRelabelConfigs: <1>
-          - <relabel_config> <2>
+        writeRelabelConfigs: # <1>
+          - <relabel_config> # <2>
 ----
 <1> Add a list of write relabel configurations for metrics that you want to send to the remote endpoint.
 <2> Substitute the label configuration for the metrics sent to the remote write endpoint.
 +
-The following sample shows how to forward a metric with the cluster ID label `cluster_id` in default platform monitoring:
+The following sample shows how to forward a metric with the cluster ID label `cluster_id`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         writeRelabelConfigs:
         - sourceLabels:
-          - __tmp_openshift_cluster_id__ <1>
-          targetLabel: cluster_id <2>
-          action: replace <3>
+          - __tmp_openshift_cluster_id__ # <1>
+          targetLabel: cluster_id # <2>
+          action: replace # <3>
 ----
 <1> The system initially applies a temporary cluster ID source label named `+++__tmp_openshift_cluster_id__+++`. This temporary label gets replaced by the cluster ID label name that you specify.
 <2> Specify the name of the cluster ID label for metrics sent to remote write storage.
@@ -103,58 +107,9 @@ For the label name, do not use `+++__tmp_openshift_cluster_id__+++`. The final r
 <3> The `replace` write relabel action replaces the temporary label with the target label for outgoing metrics.
 This action is the default and is applied if no action is specified.
 
-** *To create cluster ID labels for user-defined project metrics:*
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. In the `writeRelabelConfigs:` section under `data/config.yaml/prometheus/remoteWrite`, add cluster ID relabel configuration values:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com"
-        <endpoint_authentication_credentials>
-        writeRelabelConfigs: <1>
-          - <relabel_config> <2>
-----
-<1> Add a list of write relabel configurations for metrics that you want to send to the remote endpoint.
-<2> Substitute the label configuration for the metrics sent to the remote write endpoint.
-+
-The following sample shows how to forward a metric with the cluster ID label `cluster_id` in user-workload monitoring:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      remoteWrite:
-      - url: "https://remote-write-endpoint.example.com"
-        writeRelabelConfigs:
-        - sourceLabels:
-          - __tmp_openshift_cluster_id__ <1>
-          targetLabel: cluster_id <2>
-          action: replace <3>
-----
-<1> The system initially applies a temporary cluster ID source label named `+++__tmp_openshift_cluster_id__+++`. This temporary label gets replaced by the cluster ID label name that you specify.
-<2> Specify the name of the cluster ID label for metrics sent to remote write storage. If you use a label name that already exists for a metric, that value is overwritten with the name of this cluster ID label. For the label name, do not use `+++__tmp_openshift_cluster_id__+++`. The final relabeling step removes labels that use this name.
-<3> The `replace` write relabel action replaces the temporary label with the target label for outgoing metrics. This action is the default and is applied if no action is specified.
-
 . Save the file to apply the changes. The new configuration is applied automatically.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
index 053fc78929bd..ace2e6bafb6b 100644
--- a/modules/monitoring-creating-cluster-monitoring-configmap.adoc
+++ b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
@@ -6,7 +6,7 @@
 [id="creating-cluster-monitoring-configmap_{context}"]
 = Creating a cluster monitoring config map
 
-You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack.
+You can configure the core {product-title} monitoring components by creating and updating the `cluster-monitoring-config` config map in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack.
 
 .Prerequisites
 
diff --git a/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc
index b645f8e9f122..0d053038f758 100644
--- a/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc
+++ b/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc
@@ -6,7 +6,9 @@
 [id="creating-cross-project-alerting-rules-for-user-defined-projects_{context}"]
 = Creating cross-project alerting rules for user-defined projects
 
-You can create alerting rules for user-defined projects that are not bound to their project of origin by configuring a project in the `user-workload-monitoring-config` config map. This allows you to create generic alerting rules that get applied to multiple user-defined projects instead of having individual `PrometheusRule` objects in each user project.
+You can create alerting rules that are not bound to their project of origin by configuring a project in the `user-workload-monitoring-config` config map. The `PrometheusRule` objects created in these projects are then applicable to all projects.
+
+Therefore, you can have generic alerting rules that apply to multiple user-defined projects instead of having individual `PrometheusRule` objects in each user project. You can filter which projects are included or excluded from the alerting rule by using PromQL queries in the `PrometheusRule` object.
 
 .Prerequisites
 
@@ -48,10 +50,10 @@ metadata:
   namespace: openshift-user-workload-monitoring
 data:
   config.yaml: |
-    namespacesWithoutLabelEnforcement: [ <namespace> ] # <1>
+    namespacesWithoutLabelEnforcement: [ <namespace1>, <namespace2> ] # <1>
     # ...
 ----
-<1> Specify one or more projects in which you want to create cross-project alerting rules. Prometheus and Thanos Ruler for user-defined monitoring do not enforce the `namespace` label in `PrometheusRule` objects created in these projects.
+<1> Specify one or more projects in which you want to create cross-project alerting rules. Prometheus and Thanos Ruler for user-defined monitoring do not enforce the `namespace` label in `PrometheusRule` objects created in these projects, making the `PrometheusRule` objects applicable to all projects.
 
 . Create a YAML file for alerting rules. In this example, it is called `example-cross-project-alerting-rule.yaml`.
 
@@ -65,7 +67,7 @@ apiVersion: monitoring.coreos.com/v1
 kind: PrometheusRule
 metadata:
   name: example-security
-namespace: ns1 #<1>
+  namespace: ns1 #<1>
 spec:
   groups:
     - name: pod-security-policy
@@ -81,7 +83,7 @@ spec:
 <1> Ensure that you specify the project that you defined in the `namespacesWithoutLabelEnforcement` field.
 <2> The name of the alerting rule you want to create.
 <3> The duration for which the condition should be true before an alert is fired.
-<4> The PromQL query expression that defines the new rule.
+<4> The PromQL query expression that defines the new rule. You can use label matchers on the `namespace` label to filter which projects are included or excluded from the alerting rule.
 <5> The message associated with the alert.
 <6> The severity that alerting rule assigns to the alert.
 +
diff --git a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc
index 313fed881400..1f6b77a2c8de 100644
--- a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc
+++ b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc
@@ -28,12 +28,12 @@ Using attributes that are bound to a limited set of possible values reduces the
 
 .Prerequisites
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
@@ -64,18 +64,18 @@ topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
 * *If the metrics relate to a core {product-title} project*, create a Red Hat support case on the link:https://access.redhat.com/[Red Hat Customer Portal].
 
 . Review the TSDB status using the Prometheus HTTP API by following these steps when logged in as a
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 cluster administrator:
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 `dedicated-admin`:
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 +
 .. Get the Prometheus API route URL by running the following command:
 +
 [source,terminal]
 ----
-$ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.status.ingress[].host})
+$ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath='{.status.ingress[].host}')
 ----
 +
 .. Extract an authentication token by running the following command:
diff --git a/modules/monitoring-editing-silences.adoc b/modules/monitoring-editing-silences.adoc
index be7588044bb5..c36592bf7f70 100644
--- a/modules/monitoring-editing-silences.adoc
+++ b/modules/monitoring-editing-silences.adoc
@@ -3,8 +3,18 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="editing-silences_{context}"]
-= Editing silences
+
+// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
+
+// tag::ADM[]
+[id="editing-silences-adm_{context}"]
+= Editing silences from the Administrator perspective
+// end::ADM[]
+
+// tag::DEV[]
+[id="editing-silences-dev_{context}"]
+= Editing silences from the Developer perspective
+// end::DEV[]
 
 You can edit a silence, which expires the existing silence and creates a new one with the changed configuration.
 
@@ -18,14 +28,23 @@ ifdef::openshift-dedicated,openshift-rosa[]
 endif::openshift-dedicated,openshift-rosa[]
 * If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
 ** The `cluster-monitoring-view` cluster role, which allows you to access Alertmanager.
+// tag::ADM[]
 ** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts in the *Administrator* perspective in the web console.
+// end::ADM[]
+// tag::DEV[]
 ** The `monitoring-rules-edit` cluster role, which permits you to create and silence alerts in the *Developer* perspective in the web console.
+// end::DEV[]
 
 .Procedure
 
-To edit a silence in the *Administrator* perspective:
+// tag::ADM[]
+. From the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Alerting* -> *Silences*.
+// end::ADM[]
 
-. Go to *Observe* -> *Alerting* -> *Silences*.
+// tag::DEV[]
+. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Silences* tab.
+. Select the project that you want to edit silences for from the *Project:* list. 
+// end::DEV[]
 
 . For the silence you want to modify, click {kebab} and select *Edit silence*.
 +
@@ -33,13 +52,7 @@ Alternatively, you can click *Actions* and select *Edit silence* on the *Silence
 
 . On the *Edit silence* page, make changes and click *Silence*. Doing so expires the existing silence and creates one with the updated configuration.
 
-To edit a silence in the *Developer* perspective:
 
-. Go to *Observe* -> *<project_name>* -> *Silences*.
 
-. For the silence you want to modify, click {kebab} and select *Edit silence*.
-+
-Alternatively, you can click *Actions* and select *Edit silence* on the *Silence details* page for a silence.
 
-. On the *Edit silence* page, make changes and click *Silence*. Doing so expires the existing silence and creates one with the updated configuration.
 
diff --git a/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc
new file mode 100644
index 000000000000..1948302436af
--- /dev/null
+++ b/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc
@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="enabling-alert-routing-for-user-defined-projects_{context}"]
+= Enabling alert routing for user-defined projects
+
+In {product-title}, an administrator can enable alert routing for user-defined projects.
+This process consists of the following steps:
+
+ifndef::openshift-dedicated,openshift-rosa[]
+* Enable alert routing for user-defined projects:
+** Use the default platform Alertmanager instance.
+** Use a separate Alertmanager instance only for user-defined projects.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* Enable alert routing for user-defined projects to use a separate Alertmanager instance.
+endif::openshift-dedicated,openshift-rosa[]
+* Grant users permission to configure alert routing for user-defined projects.
+
+After you complete these steps, developers and other users can configure custom alerts and alert routing for their user-defined projects.
\ No newline at end of file
diff --git a/modules/monitoring-example-remote-write-authentication-settings.adoc b/modules/monitoring-example-remote-write-authentication-settings.adoc
index f8271a0428a0..80c59a2a07a3 100644
--- a/modules/monitoring-example-remote-write-authentication-settings.adoc
+++ b/modules/monitoring-example-remote-write-authentication-settings.adoc
@@ -6,25 +6,25 @@
 [id="example-remote-write-authentication-settings_{context}"]
 = Example remote write authentication settings
 
-// Set attributes to distinguish between cluster monitoring examples and user workload monitoring examples.
-ifndef::openshift-dedicated,openshift-rosa[]
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+// tag::CPM[]
 :configmap-name: cluster-monitoring-config
 :namespace-name: openshift-monitoring
-:prometheus-instance: prometheusK8s
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
 :configmap-name: user-workload-monitoring-config
 :namespace-name: openshift-user-workload-monitoring
-:prometheus-instance: prometheus
-endif::openshift-dedicated,openshift-rosa[]
+:component: prometheus
+// end::UWM[]
 
 The following samples show different authentication settings you can use to connect to a remote write endpoint. Each sample also shows how to configure a corresponding `Secret` object that contains authentication credentials and other relevant settings. Each sample configures authentication for use with
-ifndef::openshift-dedicated,openshift-rosa[]
+// tag::CPM[]
 default platform monitoring
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-monitoring user-defined projects
-endif::openshift-dedicated,openshift-rosa[]
+// end::CPM[]
+// tag::UWM[]
+monitoring for user-defined projects
+// end::UWM[]
 in the `{namespace-name}` namespace.
 
 [id="remote-write-sample-yaml-aws-sigv4_{context}"]
@@ -58,7 +58,7 @@ metadata:
   namespace: {namespace-name}
 data:
   config.yaml: |
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://authorization.example.com/api/write"
         sigv4:
@@ -111,7 +111,7 @@ metadata:
   namespace: {namespace-name}
 data:
   config.yaml: |
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://basicauth.example.com/api/write"
         basicAuth:
@@ -156,7 +156,7 @@ metadata:
 data:
   config.yaml: |
     enableUserWorkload: true
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://authorization.example.com/api/write"
         authorization:
@@ -200,7 +200,7 @@ metadata:
   namespace: {namespace-name}
 data:
   config.yaml: |
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://test.example.com/api/write"
         oauth2:
@@ -258,7 +258,7 @@ metadata:
   namespace: {namespace-name}
 data:
   config.yaml: |
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com"
         tlsConfig:
@@ -280,5 +280,6 @@ data:
 <4> The key in the specified `Secret` object that contains the client key secret.
 
 // Unset the source code block attributes just to be safe.
+:!configmap-name:
 :!namespace-name:
-:!prometheus-instance:
+:!component:
diff --git a/modules/monitoring-example-remote-write-queue-configuration.adoc b/modules/monitoring-example-remote-write-queue-configuration.adoc
index 24c8f1d252fc..d616eaf6ab6f 100644
--- a/modules/monitoring-example-remote-write-queue-configuration.adoc
+++ b/modules/monitoring-example-remote-write-queue-configuration.adoc
@@ -6,25 +6,25 @@
 [id="example-remote-write-queue-configuration_{context}"]
 = Example remote write queue configuration
 
-// Set attributes to distinguish between cluster monitoring examples and user workload monitoring examples.
-ifndef::openshift-dedicated,openshift-rosa[]
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+// tag::CPM[]
 :configmap-name: cluster-monitoring-config
 :namespace-name: openshift-monitoring
-:prometheus-instance: prometheusK8s
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
 :configmap-name: user-workload-monitoring-config
 :namespace-name: openshift-user-workload-monitoring
-:prometheus-instance: prometheus
-endif::openshift-dedicated,openshift-rosa[]
+:component: prometheus
+// end::UWM[]
 
 You can use the `queueConfig` object for remote write to tune the remote write queue parameters. The following example shows the queue parameters with their default values for 
-ifndef::openshift-dedicated,openshift-rosa[]
+// tag::CPM[]
 default platform monitoring
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+// end::CPM[]
+// tag::UWM[]
 monitoring for user-defined projects
-endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 in the `{namespace-name}` namespace.
 
 .Example configuration of remote write parameters with default values
@@ -37,7 +37,7 @@ metadata:
   namespace: {namespace-name}
 data:
   config.yaml: |
-    {prometheus-instance}:
+    {component}:
       remoteWrite:
       - url: "https://remote-write-endpoint.example.com" 
         <endpoint_authentication_credentials>
@@ -63,6 +63,7 @@ data:
 <9> The samples that are older than the `sampleAgeLimit` limit are dropped from the queue. If the value is undefined or set to `0s`, the parameter is ignored.
 
 // Unset the source code block attributes just to be safe.
+:!configmap-name:
 :!namespace-name:
-:!prometheus-instance:
+:!component:
 
diff --git a/modules/monitoring-expiring-silences.adoc b/modules/monitoring-expiring-silences.adoc
index 2451560e2aa1..30d6351b0119 100644
--- a/modules/monitoring-expiring-silences.adoc
+++ b/modules/monitoring-expiring-silences.adoc
@@ -3,8 +3,18 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="expiring-silences_{context}"]
-= Expiring silences
+
+// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
+
+// tag::ADM[]
+[id="expiring-silences-adm_{context}"]
+= Expiring silences from the Administrator perspective
+// end::ADM[]
+
+// tag::DEV[]
+[id="expiring-silences-dev_{context}"]
+= Expiring silences from the Developer perspective
+// end::DEV[]
 
 You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently.
 
@@ -24,27 +34,29 @@ ifdef::openshift-dedicated,openshift-rosa[]
 endif::openshift-dedicated,openshift-rosa[]
 * If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
 ** The `cluster-monitoring-view` cluster role, which allows you to access Alertmanager.
+// tag::ADM[]
 ** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts in the *Administrator* perspective in the web console.
+// end::ADM[]
+// tag::DEV[]
 ** The `monitoring-rules-edit` cluster role, which permits you to create and silence alerts in the *Developer* perspective in the web console.
+// end::DEV[]
 
 .Procedure
 
-To expire a silence or silences in the *Administrator* perspective:
-
+// tag::ADM[]
 . Go to *Observe* -> *Alerting* -> *Silences*.
+// end::ADM[]
 
-. For the silence or silences you want to expire, select the checkbox in the corresponding row.
-
-. Click *Expire 1 silence* to expire a single selected silence or *Expire _<n>_ silences* to expire multiple selected silences, where _<n>_ is the number of silences you selected.
-+
-Alternatively, to expire a single silence you can click *Actions* and select *Expire silence* on the *Silence details* page for a silence.
+// tag::DEV[]
+. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Silences* tab.
 
-To expire a silence in the *Developer* perspective:
-
-. Go to *Observe* -> *<project_name>* -> *Silences*.
+. Select the project that you want to expire a silence for from the *Project:* list. 
+// end::DEV[]
 
 . For the silence or silences you want to expire, select the checkbox in the corresponding row.
 
 . Click *Expire 1 silence* to expire a single selected silence or *Expire _<n>_ silences* to expire multiple selected silences, where _<n>_ is the number of silences you selected.
 +
 Alternatively, to expire a single silence you can click *Actions* and select *Expire silence* on the *Silence details* page for a silence.
+
+
diff --git a/modules/monitoring-getting-detailed-information-about-a-target.adoc b/modules/monitoring-getting-detailed-information-about-a-target.adoc
index e2a9ad956638..2c6a78da1e77 100644
--- a/modules/monitoring-getting-detailed-information-about-a-target.adoc
+++ b/modules/monitoring-getting-detailed-information-about-a-target.adoc
@@ -6,7 +6,7 @@
 [id="getting-detailed-information-about-a-target_{context}"]
 = Getting detailed information about a metrics target
 
-In the *Administrator* perspective in the {product-title} web console, you can use the *Metrics targets* page to view, search, and filter the endpoints that are currently targeted for scraping, which helps you to identify and troubleshoot problems. For example, you can view the current status of targeted endpoints to see when {product-title} Monitoring is not able to scrape metrics from a targeted component.
+You can use the {product-title} web console to view, search, and filter the endpoints that are currently targeted for scraping, which helps you to identify and troubleshoot problems. For example, you can view the current status of targeted endpoints to see when {product-title} monitoring is not able to scrape metrics from a targeted component.
 
 ifndef::openshift-dedicated,openshift-rosa[]
 The *Metrics targets* page shows targets for default {product-title} projects and for user-defined projects.
@@ -26,26 +26,24 @@ endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 
-. In the *Administrator* perspective, select *Observe* -> *Targets*. The *Metrics targets* page opens with a list of all service endpoint targets that are being scraped for metrics.
+. In the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Targets*. The *Metrics targets* page opens with a list of all service endpoint targets that are being scraped for metrics.
 +
---
 This page shows details about targets for default {product-title} and user-defined projects. This page lists the following information for each target:
 
-* Service endpoint URL being scraped
-* ServiceMonitor component being monitored
-* The **up** or **down** status of the target
-* Namespace
-* Last scrape time
-* Duration of the last scrape
---
+** Service endpoint URL being scraped
+** The `ServiceMonitor` resource being monitored
+** The **up** or **down** status of the target
+** Namespace
+** Last scrape time
+** Duration of the last scrape
 
-. Optional: The list of metrics targets can be long. To find a specific target, do any of the following:
+. Optional: To find a specific target, perform any of the following actions:
 +
 |===
 |Option |Description
 
 |Filter the targets by status and source.
-a|Select filters in the *Filter* list.
+a|Choose filters in the *Filter* list.
 
 The following filtering options are available:
 
@@ -54,7 +52,7 @@ The following filtering options are available:
 ** **Down**. The target is currently down and not being scraped for metrics.
 
 * **Source** filters:
-** **Platform**. Platform-level targets relate only to default Red Hat OpenShift Service on AWS projects. These projects provide core Red Hat OpenShift Service on AWS functionality.
+** **Platform**. Platform-level targets relate only to default {product-rosa} projects. These projects provide core {product-rosa} functionality.
 ** **User**. User targets relate to user-defined projects. These projects are user-created and can be customized.
 
 |Search for a target by name or label. |Enter a search term in the **Text** or **Label** field next to the search box.
@@ -62,13 +60,12 @@ The following filtering options are available:
 |Sort the targets. |Click one or more of the **Endpoint Status**, **Namespace**, **Last Scrape**, and **Scrape Duration** column headers.
 |===
 
-. Click the URL in the **Endpoint** column for a target to navigate to its **Target details** page. This page provides information about the target, including the following:
-+
---
+. Click the URL in the **Endpoint** column for a target to go to its **Target details** page. This page provides information about the target, including the following information:
+
 ** The endpoint URL being scraped for metrics
 ** The current *Up* or *Down* status of the target
 ** A link to the namespace
-** A link to the ServiceMonitor details
+** A link to the `ServiceMonitor` resource details
 ** Labels attached to the target
 ** The most recent time that the target was scraped for metrics
---
+
diff --git a/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc b/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc
index ccd2d8c9e9c7..12470bac57e8 100644
--- a/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc
+++ b/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc
@@ -3,20 +3,33 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="getting-information-about-alerts-silences-and-alerting-rules_{context}"]
-= Getting information about alerts, silences, and alerting rules
+
+// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
+
+// tag::ADM[]
+[id="getting-information-about-alerts-silences-and-alerting-rules-adm_{context}"]
+= Getting information about alerts, silences, and alerting rules from the Administrator perspective
+// end::ADM[]
+
+// tag::DEV[]
+[id="getting-information-about-alerts-silences-and-alerting-rules-dev_{context}"]
+= Getting information about alerts, silences, and alerting rules from the Developer perspective
+// end::DEV[]
+
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
 
 The Alerting UI provides detailed information about alerts and their governing alerting rules and silences.
 
 .Prerequisites
 
-* You have access to the cluster as a developer or as a user with view permissions for the project that you are viewing alerts for.
+* You have access to the cluster as a user with view permissions for the project that you are viewing alerts for.
 
 .Procedure
 
-*To obtain information about alerts in the Administrator perspective*:
+// tag::ADM[]
+To obtain information about alerts:
 
-. Open the {product-title} web console and go to the *Observe* -> *Alerting* -> *Alerts* page.
+. From the *Administrator* perspective of the {product-title} web console, go to the *Observe* -> *Alerting* -> *Alerts* page.
 
 . Optional: Search for alerts by name by using the *Name* field in the search list.
 
@@ -32,9 +45,9 @@ The Alerting UI provides detailed information about alerts and their governing a
 * A link to its governing alerting rule
 * Silences for the alert, if any exist
 
-*To obtain information about silences in the Administrator perspective*:
+To obtain information about silences:
 
-. Go to the *Observe* -> *Alerting* -> *Silences* page.
+. From the *Administrator* perspective of the {product-title} web console, go to the *Observe* -> *Alerting* -> *Silences* page.
 
 . Optional: Filter the silences by name using the *Search by name* field.
 
@@ -50,9 +63,9 @@ The Alerting UI provides detailed information about alerts and their governing a
 * Silence state
 * Number and list of firing alerts
 
-*To obtain information about alerting rules in the Administrator perspective*:
+To obtain information about alerting rules:
 
-. Go to the *Observe* -> *Alerting* -> *Alerting rules* page.
+. From the *Administrator* perspective of the {product-title} web console, go to the *Observe* -> *Alerting* -> *Alerting rules* page.
 
 . Optional: Filter alerting rules by state, severity, and source by selecting filters in the *Filter* list.
 
@@ -65,10 +78,12 @@ The Alerting UI provides detailed information about alerts and their governing a
 * The time for which the condition should be true for an alert to fire.
 * A graph for each alert governed by the alerting rule, showing the value with which the alert is firing.
 * A table of all alerts governed by the alerting rule.
+// end::ADM[]
 
-*To obtain information about alerts, silences, and alerting rules in the Developer perspective*:
+// tag::DEV[]
+To obtain information about alerts, silences, and alerting rules:
 
-. Go to the *Observe* -> *<project_name>* -> *Alerts* page.
+. From the *Developer* perspective of the {product-title} web console, go to the *Observe* -> *<project_name>* -> *Alerts* page.
 
 . View details for an alert, silence, or an alerting rule:
 
@@ -88,3 +103,4 @@ The Alerting UI provides detailed information about alerts and their governing a
 ====
 Only alerts, silences, and alerting rules relating to the selected project are displayed in the *Developer* perspective.
 ====
+// end::DEV[]
\ No newline at end of file
diff --git a/modules/monitoring-granting-user-permissions-using-the-cli.adoc b/modules/monitoring-granting-user-permissions-using-the-cli.adoc
index ac4c1f370098..252daab6796f 100644
--- a/modules/monitoring-granting-user-permissions-using-the-cli.adoc
+++ b/modules/monitoring-granting-user-permissions-using-the-cli.adoc
@@ -6,7 +6,14 @@
 [id="granting-user-permissions-using-the-cli_{context}"]
 = Granting user permissions by using the CLI
 
-You can grant users permissions for the `openshift-monitoring` project or their own projects, by using the OpenShift CLI (`oc`).
+You can grant users permissions
+// tag::CPM[]
+for the `openshift-monitoring` project or
+// end::CPM[]
+// tag::UWM[]
+to monitor
+// end::UWM[]
+their own projects, by using the {oc-first}.
 
 [IMPORTANT]
 ====
@@ -17,7 +24,7 @@ Whichever role or cluster role you choose, you must bind it against a specific p
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
 * The user account that you are assigning the role to already exists.
-* You have installed the OpenShift CLI (`oc`).
+* You have installed the {oc-first}.
 
 .Procedure
 
diff --git a/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc
index c1d2e71a62c8..041ff50a7965 100644
--- a/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc
+++ b/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc
@@ -6,7 +6,6 @@
 [id="granting-users-permission-to-configure-alert-routing-for-user-defined-projects_{context}"]
 = Granting users permission to configure alert routing for user-defined projects
 
-[role="_abstract"]
 You can grant users permission to configure alert routing for user-defined projects.
 
 .Prerequisites
diff --git a/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc b/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc
index ec9f13cdec3c..8111de21a125 100644
--- a/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc
+++ b/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="granting-users-permission-to-monitor-user-defined-projects_{context}"]
-= Granting users permission to monitor user-defined projects
+= Granting users permissions for monitoring for user-defined projects
 
 As a cluster administrator, you can monitor all core {product-title} and user-defined projects.
 
@@ -53,5 +53,8 @@ You can grant the permissions by assigning one of the following monitoring roles
 |`alert-routing-edit` 
 |Users with this cluster role can create, update, and delete `AlertmanagerConfig` CRs for user-defined projects.
 |Can be bound with `RoleBinding` to any user project.
-|===
 
+|`pod-metrics-reader` 
+|Users with this cluster role can access Thanos API endpoints for user-defined projects.
+|Can be bound with `RoleBinding` to any user project.
+|===
diff --git a/modules/monitoring-installing-cluster-observability-operator-using-the-web-console.adoc b/modules/monitoring-installing-cluster-observability-operator-using-the-web-console.adoc
index f7a27719df78..362a575cead7 100644
--- a/modules/monitoring-installing-cluster-observability-operator-using-the-web-console.adoc
+++ b/modules/monitoring-installing-cluster-observability-operator-using-the-web-console.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 
-// * observability/monitoring/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
+// * observability/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="installing-the-cluster-observability-operator-in-the-web-console-_{context}"]
@@ -17,15 +17,16 @@ Install the {coo-first} from OperatorHub by using the {product-title} web consol
 . In the {product-title} web console, click *Operators* -> *OperatorHub*.
 . Type `cluster observability operator` in the *Filter by keyword* box.
 . Click  *{coo-full}* in the list of results.
-. Read the information about the Operator, and review the following default installation settings:
+. Read the information about the Operator, and configure the following installation settings:
 +
-* *Update channel* -> *development*
-* *Version* -> <most_recent_version>
+* *Update channel* -> *stable*
+* *Version* -> *1.0.0* or later
 * *Installation mode* -> *All namespaces on the cluster (default)*
-* *Installed Namespace* -> *openshift-operators*
+* *Installed Namespace* -> *Operator recommended Namespace: openshift-cluster-observability-operator*
+* Select *Enable Operator recommended cluster monitoring on this Namespace*
 * *Update approval* -> *Automatic*
 
-. Optional: Change default installation settings to suit your requirements.
+. Optional: You can change the installation settings to suit your requirements.
 For example, you can select to subscribe to a different update channel, to install an older released version of the Operator, or to require manual approval for updates to new versions of the Operator.
 . Click *Install*.
 
diff --git a/modules/monitoring-intro-enabling-monitoring-for-user-defined-projects.adoc b/modules/monitoring-intro-enabling-monitoring-for-user-defined-projects.adoc
new file mode 100644
index 000000000000..e0f8198cfeb2
--- /dev/null
+++ b/modules/monitoring-intro-enabling-monitoring-for-user-defined-projects.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="intro-enabling-monitoring-for-user-defined-projects_{context}"]
+= Enabling monitoring for user-defined projects
+
+In {product-title}, you can enable monitoring for user-defined projects in addition to the default platform monitoring. You can monitor your own projects in {product-title} without the need for an additional monitoring solution. Using this feature centralizes monitoring for core platform components and user-defined projects.
+
+include::snippets/monitoring-custom-prometheus-note.adoc[]
diff --git a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
index 7820be33adf4..af462e9efe0d 100644
--- a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
+++ b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
@@ -11,20 +11,48 @@
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-* You have installed the OpenShift CLI (`oc`).
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+* You have installed the {oc-first}.
 * You have enabled and configured monitoring for user-defined projects.
 * You have created a `ServiceMonitor` resource.
 
 .Procedure
 
-. *Check that the corresponding labels match* in the service and `ServiceMonitor` resource configurations.
-.. Obtain the label defined in the service. The following example queries the `prometheus-example-app` service in the `ns1` project:
+. Ensure that your project is not excluded from user workload monitoring. The following examples use the `ns1` project.
+
+.. Verify that the project _does not_ have the `openshift.io/user-monitoring=false` label attached:
++
+[source,terminal]
+----
+$ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'
+----
++
+[NOTE]
+====
+The default label set for user workload projects is `openshift.io/user-monitoring=true`. However, the label is not visible unless you manually apply it.
+====
+
+.. If the label is attached, remove the label:
++
+.Example of removing the label from the project
+[source,terminal]
+----
+$ oc label namespace ns1 'openshift.io/user-monitoring-'
+----
++
+.Example output
+[source,terminal]
+----
+namespace/ns1 unlabeled
+----
+
+. Check that the corresponding labels match in the service and `ServiceMonitor` resource configurations. The following examples use the `prometheus-example-app` service, the `prometheus-example-monitor` service monitor, and the `ns1` project.
+.. Obtain the label defined in the service.
 +
 [source,terminal]
 ----
@@ -38,7 +66,7 @@ $ oc -n ns1 get service prometheus-example-app -o yaml
     app: prometheus-example-app
 ----
 +
-.. Check that the `matchLabels` definition in the `ServiceMonitor` resource configuration matches the label output in the preceding step. The following example queries the `prometheus-example-monitor` service monitor in the `ns1` project:
+.. Check that the `matchLabels` definition in the `ServiceMonitor` resource configuration matches the label output in the preceding step.
 +
 [source,terminal]
 ----
@@ -68,7 +96,7 @@ spec:
 You can check service and `ServiceMonitor` resource labels as a developer with view permissions for the project.
 ====
 
-. *Inspect the logs for the Prometheus Operator* in the `openshift-user-workload-monitoring` project.
+. Inspect the logs for the Prometheus Operator in the `openshift-user-workload-monitoring` project.
 .. List the pods in the `openshift-user-workload-monitoring` project:
 +
 [source,terminal]
@@ -101,14 +129,14 @@ If there is a issue with the service monitor, the logs might include an error si
 level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
 ----
 
-. *Review the target status for your endpoint* on the *Metrics targets* page in the {product-title} web console UI.
+. Review the target status for your endpoint on the *Metrics targets* page in the {product-title} web console UI.
 .. Log in to the {product-title} web console and navigate to *Observe* → *Targets* in the *Administrator* perspective.
 
 .. Locate the metrics endpoint in the list, and review the status of the target in the *Status* column.
 
 .. If the *Status* is *Down*, click the URL for the endpoint to view more information on the *Target Details* page for that metrics target.
 
-. *Configure debug level logging for the Prometheus Operator* in the `openshift-user-workload-monitoring` project.
+. Configure debug level logging for the Prometheus Operator in the `openshift-user-workload-monitoring` project.
 .. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
 +
 [source,terminal]
diff --git a/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc b/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc
index 197d58772c18..56c306ae30d0 100644
--- a/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc
+++ b/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc
@@ -26,7 +26,7 @@ endif::[]
 
 .Procedure
 
-. In the *Administrator* perspective, navigate to *Observe* -> *Alerting* -> *Alerting rules*.
+. From the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Alerting* -> *Alerting rules*.
 
 . Select the *Platform* and *User* sources in the *Filter* drop-down menu.
 +
diff --git a/modules/monitoring-maintenance-and-support.adoc b/modules/monitoring-maintenance-and-support.adoc
index ac299b862adc..8e52994e74f2 100644
--- a/modules/monitoring-maintenance-and-support.adoc
+++ b/modules/monitoring-maintenance-and-support.adoc
@@ -5,7 +5,7 @@
 [id="maintenance-and-support_{context}"]
 = Maintenance and support for monitoring
 
-Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the "Config map reference for the {cmo-short}". *Do not use other configurations, as they are unsupported.*
+Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the "Config map reference for the {cmo-short}". _Do not use other configurations, as they are unsupported._
 
 Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the {cmo-full}", your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
 
diff --git a/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc
index d144090983a6..a6125178453c 100644
--- a/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc
+++ b/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc
@@ -7,8 +7,6 @@
 [id="managing-alerting-rules-for-user-defined-projects_{context}"]
 = Managing alerting rules for user-defined projects
 
-{product-title} monitoring ships with a set of default alerting rules. As a cluster administrator, you can view the default alerting rules.
-
 In {product-title}, you can view, edit, and remove alerting rules in user-defined projects.
 
 ifdef::openshift-rosa,openshift-dedicated[]
diff --git a/modules/monitoring-managing-core-platform-alerting-rules.adoc b/modules/monitoring-managing-core-platform-alerting-rules.adoc
index 60b7fa166b92..2f65acfd0f20 100644
--- a/modules/monitoring-managing-core-platform-alerting-rules.adoc
+++ b/modules/monitoring-managing-core-platform-alerting-rules.adoc
@@ -6,7 +6,7 @@
 [id="managing-core-platform-alerting-rules_{context}"]
 = Managing alerting rules for core platform monitoring
 
-{product-title} {product-version} monitoring ships with a large set of default alerting rules for platform metrics.
+The {product-title} monitoring includes a large set of default alerting rules for platform metrics.
 As a cluster administrator, you can customize this set of rules in two ways:
 
 * Modify the settings for existing platform alerting rules by adjusting thresholds or by adding and modifying labels.
diff --git a/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc b/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc
index 476111a1e203..5f72844cbd72 100644
--- a/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc
+++ b/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc
@@ -4,51 +4,29 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="modifying-retention-time-and-size-for-prometheus-metrics-data_{context}"]
-= Modifying the retention time and size for Prometheus metrics data
-
-By default, Prometheus retains metrics data for the following durations:
-
-ifndef::openshift-dedicated,openshift-rosa[]
-* *Core platform monitoring*: 15 days
-* *Monitoring for user-defined projects*: 24 hours
-endif::openshift-dedicated,openshift-rosa[]
-
-ifdef::openshift-dedicated,openshift-rosa[]
-* *Core platform monitoring*: 11 days
-* *Monitoring for user-defined projects*: 24 hours
-endif::openshift-dedicated,openshift-rosa[]
-
-You can modify the retention time for
-ifndef::openshift-dedicated,openshift-rosa[]
-Prometheus
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-the Prometheus instance that monitors user-defined projects,
-endif::openshift-dedicated,openshift-rosa[]
-to change how soon the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. If the data reaches this size limit, Prometheus deletes the oldest data first until the disk space used is again below the limit.
-
-Note the following behaviors of these data retention settings:
-
-* The size-based retention policy applies to all data block directories in the `/prometheus` directory, including persistent blocks, write-ahead log (WAL) data, and m-mapped chunks.
-* Data in the `/wal` and `/head_chunks` directories counts toward the retention size limit, but Prometheus never purges data from these directories based on size- or time-based retention policies.
-Thus, if you set a retention size limit lower than the maximum size set for the `/wal` and `/head_chunks` directories, you have configured the system not to retain any data blocks in the `/prometheus` data directories.
-* The size-based retention policy is applied only when Prometheus cuts a new data block, which occurs every two hours after the WAL contains at least three hours of data.
-ifndef::openshift-dedicated,openshift-rosa[]
-* If you do not explicitly define values for either `retention` or `retentionSize`, retention time defaults to 15 days for core platform monitoring and 24 hours for user-defined project monitoring. Retention size is not set.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-* If you do not explicitly define values for either `retention` or `retentionSize`, retention time defaults to 11 days for core platform monitoring and 24 hours for user-defined project monitoring. Retention size is not set.
-endif::openshift-dedicated,openshift-rosa[]
-* If you define values for both `retention` and `retentionSize`, both values apply.
-If any data blocks exceed the defined retention time or the defined size limit, Prometheus purges these data blocks.
-* If you define a value for `retentionSize` and do not define `retention`, only the `retentionSize` value applies.
-* If you do not define a value for `retentionSize` and only define a value for `retention`, only the `retention` value applies.
-ifndef::openshift-dedicated,openshift-rosa[]
-* If you set the `retentionSize` or `retention` value to `0`, the default settings apply. The default settings set retention time to 15 days for core platform monitoring and 24 hours for user-defined project monitoring. By default, retention size is not set.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-* If you set the `retentionSize` or `retention` value to `0`, the default settings apply. The default settings set retention time to 11 days for core platform monitoring and 24 hours for user-defined project monitoring. By default, retention size is not set.
-endif::openshift-dedicated,openshift-rosa[]
+= Modifying retention time and size for Prometheus metrics data
+
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: prometheus
+// end::UWM[]
+
+By default, Prometheus retains metrics data for 
+// tag::CPM[]
+15 days for core platform monitoring.
+// end::CPM[]
+// tag::UWM[]
+24 hours for monitoring for user-defined projects.
+// end::UWM[]
+You can modify the retention time for the Prometheus instance to change when the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses.
 
 [NOTE]
 ====
@@ -57,110 +35,69 @@ Data compaction occurs every two hours. Therefore, a persistent volume (PV) migh
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To modify the retention time and size for the Prometheus instance that monitors core {product-title} projects*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add the retention time and size configuration under `data/config.yaml`:
+. Add the retention time and size configuration under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
-      retention: <time_specification> <1>
-      retentionSize: <size_specification> <2>
+    {component}:
+      retention: <time_specification> # <1>
+      retentionSize: <size_specification> # <2>
 ----
-+
 <1> The retention time: a number directly followed by `ms` (milliseconds), `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), or `y` (years). You can also combine time values for specific times, such as `1h30m15s`.
 <2> The retention size: a number directly followed by `B` (bytes), `KB` (kilobytes), `MB` (megabytes), `GB` (gigabytes), `TB` (terabytes), `PB` (petabytes), and `EB` (exabytes).
 +
-The following example sets the retention time to 24 hours and the retention size to 10 gigabytes for the Prometheus instance that monitors core {product-title} components:
+The following example sets the retention time to 24 hours and the retention size to 10 gigabytes for the Prometheus instance:
 +
-[source,yaml]
+.Example of setting retention time for Prometheus
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
-      retention: 24h
-      retentionSize: 10GB
-----
-
-** *To modify the retention time and size for the Prometheus instance that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add the retention time and size configuration under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      retention: <time_specification> <1>
-      retentionSize: <size_specification> <2>
-----
-+
-<1> The retention time: a number directly followed by `ms` (milliseconds), `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), or `y` (years).
-You can also combine time values for specific times, such as `1h30m15s`.
-<2> The retention size: a number directly followed by `B` (bytes), `KB` (kilobytes), `MB` (megabytes), `GB` (gigabytes), `TB` (terabytes), `PB` (petabytes), or `EB` (exabytes).
-+
-The following example sets the retention time to 24 hours and the retention size to 10 gigabytes for the Prometheus instance that monitors user-defined projects:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
+    {component}:
       retention: 24h
       retentionSize: 10GB
 ----
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
\ No newline at end of file
diff --git a/modules/monitoring-understanding-monitoring-stack-in-ha-clusters.adoc b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc
similarity index 90%
rename from modules/monitoring-understanding-monitoring-stack-in-ha-clusters.adoc
rename to modules/monitoring-monitoring-stack-in-ha-clusters.adoc
index 778717ed9e73..a0246553c4e0 100644
--- a/modules/monitoring-understanding-monitoring-stack-in-ha-clusters.adoc
+++ b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc
@@ -3,8 +3,8 @@
 // * observability/monitoring/monitoring-overview.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="understanding-monitoring-stack-in-ha-clusters_{context}"]
-= Understanding the monitoring stack in high-availability clusters
+[id="monitoring-stack-in-ha-clusters_{context}"]
+= The monitoring stack in high-availability clusters
 
 By default, in multi-node clusters, the following components run in high-availability (HA) mode to prevent data loss and service interruption:
 
diff --git a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc
index fd865e3a7d38..70e79fdce004 100644
--- a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc
+++ b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc
@@ -6,33 +6,53 @@
 [id="moving-monitoring-components-to-different-nodes_{context}"]
 = Moving monitoring components to different nodes
 
-ifndef::openshift-dedicated,openshift-rosa[]
-To specify the nodes in your cluster on which monitoring stack components will run, configure the `nodeSelector` constraint in the component's `ConfigMap` object to match labels assigned to the nodes.
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples.
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+// end::UWM[]
+
+// tag::CPM[]
+To specify the nodes in your cluster on which monitoring stack components will run, configure the `nodeSelector` constraint for the components in the `cluster-monitoring-config` config map to match labels assigned to the nodes.
 
 [NOTE]
 ====
 You cannot add a node selector constraint directly to an existing scheduled pod.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+// end::CPM[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
-You can move any of the components that monitor workloads for user-defined projects to specific worker nodes. It is not permitted to move components to control plane or infrastructure nodes.
-endif::openshift-dedicated,openshift-rosa[]
+// tag::UWM[]
+You can move any of the components that monitor workloads for user-defined projects to specific worker nodes. 
+
+[WARNING]
+====
+It is not permitted to move components to control plane or infrastructure nodes.
+====
+// end::UWM[]
 
 .Prerequisites
+
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+* You have installed the OpenShift CLI (`oc`).
+// end::CPM[]
+
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
 * You have installed the OpenShift CLI (`oc`).
+// end::UWM[]
 
 .Procedure
 
@@ -40,75 +60,38 @@ endif::openshift-dedicated,openshift-rosa[]
 +
 [source,terminal]
 ----
-$ oc label nodes <node-name> <node-label>
+$ oc label nodes <node_name> <node_label> <1>
 ----
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To move a component that monitors core {product-title} projects*:
+<1> Replace `<node_name>` with the name of the node where you want to add the label. 
+Replace `<node_label>` with the name of the wanted label.
 
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` `ConfigMap` object in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Specify the node labels for the `nodeSelector` constraint for the component under `data/config.yaml`:
+. Specify the node labels for the `nodeSelector` constraint for the component under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    <component>: <1>
+    # ...
+    <component>: #<1>
       nodeSelector:
-        <node-label-1> <2>
-        <node-label-2> <3>
-        <...>
+        <node_label_1> #<2>
+        <node_label_2> #<3>
+    # ...
 ----
 <1> Substitute `<component>` with the appropriate monitoring stack component name.
-<2> Substitute `<node-label-1>` with the label you added to the node.
-<3> Optional: Specify additional labels.
-If you specify additional labels, the pods for the component are only scheduled on the nodes that contain all of the specified labels.
-+
-[NOTE]
-====
-If monitoring components remain in a `Pending` state after configuring the `nodeSelector` constraint, check the pod events for errors relating to taints and tolerations.
-====
-
-** *To move a component that monitors user-defined projects*:
-endif::openshift-dedicated,openshift-rosa[]
-
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Specify the node labels for the `nodeSelector` constraint for the component under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>: <1>
-      nodeSelector:
-        <node-label-1> <2>
-        <node-label-2> <3>
-        <...>
-----
-<1> Substitute `<component>` with the appropriate monitoring stack component name.
-<2> Substitute `<node-label-1>` with the label you added to the node.
+<2> Substitute `<node_label_1>` with the label you added to the node.
 <3> Optional: Specify additional labels.
 If you specify additional labels, the pods for the component are only scheduled on the nodes that contain all of the specified labels.
 +
@@ -118,3 +101,7 @@ If monitoring components remain in a `Pending` state after configuring the `node
 ====
 
 . Save the file to apply the changes. The components specified in the new configuration are automatically moved to the new nodes, and the pods affected by the new configuration are redeployed.
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
diff --git a/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc b/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc
index 17b2b1ecbf60..cd2065ba065f 100644
--- a/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc
+++ b/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc
@@ -3,7 +3,7 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="Optimizing-alerting-for-user-defined-projects_{context}"]
+[id="optimizing-alerting-for-user-defined-projects_{context}"]
 = Optimizing alerting for user-defined projects
 
 You can optimize alerting for your own projects by considering the following recommendations when creating alerting rules:
diff --git a/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc b/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc
index 2180b523a200..9519663156c7 100644
--- a/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc
+++ b/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc
@@ -57,7 +57,7 @@ $ TOKEN=$(oc whoami -t)
 +
 [source,terminal]
 ----
-$ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath={.status.ingress[].host})
+$ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath='{.status.ingress[].host}')
 ----
 
 . Query metrics from the `/federate` route.
diff --git a/modules/monitoring-querying-metrics-for-all-projects-as-an-administrator.adoc b/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc
similarity index 86%
rename from modules/monitoring-querying-metrics-for-all-projects-as-an-administrator.adoc
rename to modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc
index e1bdf4bf8d53..3ac1e7f0de36 100644
--- a/modules/monitoring-querying-metrics-for-all-projects-as-an-administrator.adoc
+++ b/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc
@@ -4,8 +4,12 @@
 // * virt/support/virt-prometheus-queries.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="querying-metrics-for-all-projects-as-an-administrator_{context}"]
-= Querying metrics for all projects as a cluster administrator
+[id="querying-metrics-for-all-projects-with-mon-dashboard_{context}"]
+= Querying metrics for all projects with the {product-title} web console
+
+// The following section will be included in the administrator section, hence there is no need to include "administrator" in the title
+
+You can use the {product-title} metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring.
 
 As a
 ifndef::openshift-dedicated,openshift-rosa[]
@@ -69,7 +73,7 @@ Use the keyboard arrows to select one of these suggested items and then press En
 * By default, the query table shows an expanded view that lists every metric and its current value. Click the *˅* down arrowhead to minimize the expanded view for a query.
 ====
 
-. Optional: The page URL now contains the queries you ran. To use this set of queries again in the future, save this URL.
+. Optional: Save the page URL to use this set of queries again in the future.
 
 . Explore the visualized metrics. Initially, all metrics from all enabled queries are shown on the plot. Select which metrics are shown by performing any of the following actions:
 +
diff --git a/modules/monitoring-querying-metrics-for-user-defined-projects-as-a-developer.adoc b/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc
similarity index 84%
rename from modules/monitoring-querying-metrics-for-user-defined-projects-as-a-developer.adoc
rename to modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc
index 152a39e90496..dd2c7cbd5d4e 100644
--- a/modules/monitoring-querying-metrics-for-user-defined-projects-as-a-developer.adoc
+++ b/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc
@@ -4,10 +4,12 @@
 // * virt/support/virt-prometheus-queries.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="querying-metrics-for-user-defined-projects-as-a-developer_{context}"]
-= Querying metrics for user-defined projects as a developer
+[id="querying-metrics-for-user-defined-projects-with-mon-dashboard_{context}"]
+= Querying metrics for user-defined projects with the {product-title} web console
 
-You can access metrics for a user-defined project as a developer or as a user with view permissions for the project.
+You can use the {product-title} metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about any user-defined workloads that you are monitoring.
+
+As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.
 
 The Metrics UI includes predefined queries, for example, CPU, memory, bandwidth, or network packet. These queries are restricted to the selected project. You can also run custom Prometheus Query Language (PromQL) queries for the project.
 
@@ -30,7 +32,7 @@ endif::openshift-dedicated,openshift-rosa[]
 
 . In the *Developer* perspective of the {product-title} web console, click *Observe* and go to the *Metrics* tab.
 
-. Select the project that you want to view metrics for in the *Project:* list.
+. Select the project that you want to view metrics for from the *Project:* list.
 
 . To add one or more queries, perform any of the following actions:
 +
@@ -62,7 +64,7 @@ Use the keyboard arrows to select one of these suggested items and then press En
 * By default, the query table shows an expanded view that lists every metric and its current value. Click the *˅* down arrowhead to minimize the expanded view for a query.
 ====
 
-. Optional: The page URL now contains the queries you ran. To use this set of queries again in the future, save this URL.
+. Optional: Save the page URL to use this set of queries again in the future.
 
 . Explore the visualized metrics. Initially, all metrics from all enabled queries are shown on the plot. Select which metrics are shown by performing any of the following actions:
 +
diff --git a/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc
index fd21d052dbbb..99f5993765fa 100644
--- a/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc
+++ b/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc
@@ -11,7 +11,7 @@ You can remove alerting rules for user-defined projects.
 .Prerequisites
 
 * You have enabled monitoring for user-defined projects.
-* You are logged in as a user that has the `monitoring-rules-edit` cluster role for the project where you want to create an alerting rule.
+* You are logged in as a cluster administrator or as a user that has the `monitoring-rules-edit` cluster role for the project where you want to create an alerting rule.
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/monitoring-resizing-a-persistent-volume.adoc b/modules/monitoring-resizing-a-persistent-volume.adoc
index 229eefa28aaf..a32e62407e9f 100644
--- a/modules/monitoring-resizing-a-persistent-volume.adoc
+++ b/modules/monitoring-resizing-a-persistent-volume.adoc
@@ -6,7 +6,26 @@
 [id="resizing-a-persistent-volume_{context}"]
 = Resizing a persistent volume
 
-You can resize a persistent volume (PV) for monitoring components, such as Prometheus, Thanos Ruler, or Alertmanager. You need to manually expand a persistent volume claim (PVC), and then update the config map in which the component is configured.
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: thanosRuler
+// end::UWM[]
+
+// tag::CPM[]
+You can resize a persistent volume (PV) for monitoring components, such as Prometheus or Alertmanager. 
+// end::CPM[]
+// tag::UWM[]
+You can resize a persistent volume (PV) for the instances of Prometheus, Thanos Ruler, and Alertmanager.
+// end::UWM[]
+You need to manually expand a persistent volume claim (PVC), and then update the config map in which the component is configured.
 
 [IMPORTANT]
 ====
@@ -14,128 +33,87 @@ You can only expand the size of the PVC. Shrinking the storage size is not possi
 ====
 
 .Prerequisites
-
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+* You have configured at least one PVC for core {product-title} monitoring components.
+// end::CPM[]
+// tag::UWM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
+* You have configured at least one PVC for components that monitor user-defined projects.
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
-* *If you are configuring core {product-title} monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-** You have configured at least one PVC for core {product-title} monitoring components.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
-** You have configured at least one PVC for components that monitor user-defined projects.
 
 .Procedure
 
 . Manually expand a PVC with the updated storage request. For more information, see "Expanding persistent volume claims (PVCs) with a file system" in _Expanding persistent volumes_.
 
-. Edit the `ConfigMap` object:
-** *If you are configuring core {product-title} monitoring components*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add a new storage size for the PVC configuration for the component under `data/config.yaml`:
+. Add a new storage size for the PVC configuration for the component under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    <component>: #<1>
+    <component>: # <1>
       volumeClaimTemplate:
         spec:
           resources:
             requests:
-              storage: <amount_of_storage> #<2>
+              storage: <amount_of_storage> # <2>
 ----
 <1> The component for which you want to change the storage size.
 <2> Specify the new size for the storage volume. It must be greater than the previous value.
 +
-The following example sets the new PVC request to 100 gigabytes for the Prometheus instance that monitors core {product-title} components:
+The following example sets the new PVC request to 
+// tag::CPM[]
+100 gigabytes for the Prometheus instance:
+// end::CPM[]
+// tag::UWM[]
+20 gigabytes for Thanos Ruler:
+// end::UWM[]
 +
-[source,yaml]
+.Example storage configuration for `{component}`
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
+    {component}:
       volumeClaimTemplate:
         spec:
           resources:
             requests:
+# tag::CPM[]
               storage: 100Gi
-----
-
-** *If you are configuring components that monitor user-defined projects*:
-+
-[NOTE]
-====
-You can resize the volumes for the Thanos Ruler and for instances of Alertmanager and Prometheus that monitor user-defined projects.
-====
-+
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Update the PVC configuration for the monitoring component under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>: #<1>
-      volumeClaimTemplate:
-        spec:
-          resources:
-            requests:
-              storage: <amount_of_storage> #<2>
-----
-<1> The component for which you want to change the storage size.
-<2> Specify the new size for the storage volume. It must be greater than the previous value.
-+
-The following example sets the new PVC request to 20 gigabytes for Thanos Ruler:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    thanosRuler:
-      volumeClaimTemplate:
-        spec:
-          resources:
-            requests:
+# end::CPM[]
+# tag::UWM[]
               storage: 20Gi
+# end::UWM[]
 ----
+// tag::UWM[]
 +
 [NOTE]
 ====
 Storage requirements for the `thanosRuler` component depend on the number of rules that are evaluated and how many samples each rule generates.
 ====
+// end::UWM[]
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 +
@@ -143,3 +121,8 @@ Storage requirements for the `thanosRuler` component depend on the number of rul
 ====
 When you update the config map with a new storage size, the affected `StatefulSet` object is recreated, resulting in a temporary service outage.
 ====
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
diff --git a/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc b/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc
index d7609ad9168a..2c87ab26e232 100644
--- a/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc
+++ b/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc
@@ -23,12 +23,12 @@ To address this issue, you can remove Prometheus time-series database (TSDB) blo
 
 .Prerequisites
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
@@ -40,7 +40,7 @@ endif::openshift-dedicated,openshift-rosa[]
 $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \// <1>
 -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \// <1>
 -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
--- sh -c 'cd /prometheus/;du -hs $(ls -dt */ | grep -Eo "[0-9|A-Z]{26}")'
+-- sh -c 'cd /prometheus/;du -hs $(ls -dtr */ | grep -Eo "[0-9|A-Z]{26}")'
 ----
 <1> Replace `<prometheus_k8s_pod_name>` with the pod mentioned in the `KubePersistentVolumeFillingUp` alert description.
 +
diff --git a/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc b/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc
index 09b354453575..072b187e85d1 100644
--- a/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc
+++ b/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc
@@ -9,8 +9,8 @@
 
 This document describes the following resources deployed and managed by the Cluster Monitoring Operator (CMO):
 
-* link:#cmo-routes-resources[Routes]
-* link:#cmo-services-resources[Services]
+* link:#cmo-routes-resources_{context}[Routes]
+* link:#cmo-services-resources_{context}[Services]
 
 Use this information when you want to configure API endpoint connections to retrieve, send, or query metrics data.
 
@@ -23,7 +23,7 @@ To avoid these issues, follow these recommendations:
 * Avoid querying endpoints frequently. Limit queries to a maximum of one every 30 seconds.
 * Do not try to retrieve all metrics data via the `/federate` endpoint. Query it only when you want to retrieve a limited, aggregated data set. For example, retrieving fewer than 1,000 samples for each request helps minimize the risk of performance degradation.
 ====
-[id="cmo-routes-resources"]
+[id="cmo-routes-resources_{context}"]
 == CMO routes resources
 
 === openshift-monitoring/alertmanager-main
@@ -50,7 +50,7 @@ Expose the `/api` endpoints of the `thanos-querier` service via a router.
 
 Expose the `/api` endpoints of the `thanos-ruler` service via a router.
 
-[id="cmo-services-resources"]
+[id="cmo-services-resources_{context}"]
 == CMO services resources
 
 === openshift-monitoring/prometheus-operator-admission-webhook
diff --git a/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc b/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc
new file mode 100644
index 000000000000..386193442c38
--- /dev/null
+++ b/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc
@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/configuring-the-monitoring-stack.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="retention-time-and-size-for-prometheus-metrics-data_{context}"]
+= Retention time and size for Prometheus metrics
+
+By default, Prometheus retains metrics data for the following durations:
+
+* *Core platform monitoring*: 15 days
+* *Monitoring for user-defined projects*: 24 hours
+
+You can modify the retention time for the Prometheus instance to change how soon the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. If the data reaches this size limit, Prometheus deletes the oldest data first until the disk space used is again below the limit.
+
+Note the following behaviors of these data retention settings:
+
+* The size-based retention policy applies to all data block directories in the `/prometheus` directory, including persistent blocks, write-ahead log (WAL) data, and m-mapped chunks.
+* Data in the `/wal` and `/head_chunks` directories counts toward the retention size limit, but Prometheus never purges data from these directories based on size- or time-based retention policies.
+Thus, if you set a retention size limit lower than the maximum size set for the `/wal` and `/head_chunks` directories, you have configured the system not to retain any data blocks in the `/prometheus` data directories.
+* The size-based retention policy is applied only when Prometheus cuts a new data block, which occurs every two hours after the WAL contains at least three hours of data.
+* If you do not explicitly define values for either `retention` or `retentionSize`, retention time defaults to 15 days for core platform monitoring and 24 hours for user-defined project monitoring. Retention size is not set.
+* If you define values for both `retention` and `retentionSize`, both values apply.
+If any data blocks exceed the defined retention time or the defined size limit, Prometheus purges these data blocks.
+* If you define a value for `retentionSize` and do not define `retention`, only the `retentionSize` value applies.
+* If you do not define a value for `retentionSize` and only define a value for `retention`, only the `retention` value applies.
+* If you set the `retentionSize` or `retention` value to `0`, the default settings apply. The default settings set retention time to 15 days for core platform monitoring and 24 hours for user-defined project monitoring. By default, retention size is not set.
+
+[NOTE]
+====
+Data compaction occurs every two hours. Therefore, a persistent volume (PV) might fill up before compaction, potentially exceeding the `retentionSize` limit. In such cases, the `KubePersistentVolumeFillingUp` alert fires until the space on a PV is lower than the `retentionSize` limit.
+====
diff --git a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc
index 13a9abb419cf..e28ae308c046 100644
--- a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc
+++ b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc
@@ -24,10 +24,10 @@ endif::openshift-dedicated,openshift-rosa[]
 . Choose a dashboard in the *Dashboard* list. Some dashboards, such as *etcd* and *Prometheus* dashboards, produce additional sub-menus when selected.
 
 . Optional: Select a time range for the graphs in the *Time Range* list.
-+
+
 ** Select a pre-defined time period.
-+
-** Set a custom time range by selecting *Custom time range* in the *Time Range* list.
+
+** Set a custom time range by clicking *Custom time range* in the *Time Range* list.
 +
 .. Input or select the *From* and *To* dates and times.
 +
@@ -35,4 +35,4 @@ endif::openshift-dedicated,openshift-rosa[]
 
 . Optional: Select a *Refresh Interval*.
 
-. Hover over each of the graphs within a dashboard to display detailed information about specific items.
+. Hover over each of the graphs within a dashboard to display detailed information about specific items.
\ No newline at end of file
diff --git a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc
index 044d50840a98..8e2ee61481cc 100644
--- a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc
+++ b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc
@@ -6,7 +6,12 @@
 [id="reviewing-monitoring-dashboards-developer_{context}"]
 = Reviewing monitoring dashboards as a developer
 
-In the *Developer* perspective, you can view dashboards relating to a selected project. You must have access to monitor a project to view dashboard information for it.
+In the *Developer* perspective, you can view dashboards relating to a selected project.
+
+[NOTE]
+====
+In the *Developer* perspective, you can view dashboards for only one project at a time.
+====
 
 .Prerequisites
 
@@ -27,10 +32,10 @@ All dashboards produce additional sub-menus when selected, except *Kubernetes /
 ====
 +
 . Optional: Select a time range for the graphs in the *Time Range* list.
-+
+
 ** Select a pre-defined time period.
-+
-** Set a custom time range by selecting *Custom time range* in the *Time Range* list.
+
+** Set a custom time range by clicking *Custom time range* in the *Time Range* list.
 +
 .. Input or select the *From* and *To* dates and times.
 +
diff --git a/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc b/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc
index 214aa7534eb4..1ccd82197830 100644
--- a/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc
+++ b/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc
@@ -8,7 +8,7 @@
 
 You can filter the alerts, silences, and alerting rules that are displayed in the Alerting UI. This section provides a description of each of the available filtering options.
 
-[discrete]
+[id="understanding-alert-filters_{context}"]
 == Understanding alert filters
 
 In the *Administrator* perspective, the *Alerts* page in the Alerting UI provides details about alerts relating to default {product-title} and user-defined projects. The page includes a summary of severity, state, and source for each alert. The time at which an alert went into its current state is also shown.
@@ -31,7 +31,7 @@ You can filter by alert state, severity, and source. By default, only *Platform*
 ** *Platform*. Platform-level alerts relate only to default {product-title} projects. These projects provide core {product-title} functionality.
 ** *User*. User alerts relate to user-defined projects. These alerts are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.
 
-[discrete]
+[id="understanding-silence-filters_{context}"]
 == Understanding silence filters
 
 In the *Administrator* perspective, the *Silences* page in the Alerting UI provides details about silences applied to alerts in default {product-title} and user-defined projects. The page includes a summary of the state of each silence and the time at which a silence ends.
@@ -43,7 +43,7 @@ You can filter by silence state. By default, only *Active* and *Pending* silence
 ** *Pending*. The silence has been scheduled and it is not yet active.
 ** *Expired*. The silence has expired and notifications will be sent if the conditions for an alert are true.
 
-[discrete]
+[id="understanding-alerting-rule-filters_{context}"]
 == Understanding alerting rule filters
 
 In the *Administrator* perspective, the *Alerting rules* page in the Alerting UI provides details about alerting rules relating to default {product-title} and user-defined projects. The page includes a summary of the state, severity, and source for each alerting rule.
@@ -67,7 +67,7 @@ You can filter alerting rules by alert state, severity, and source. By default,
 ** *Platform*. Platform-level alerting rules relate only to default {product-title} projects. These projects provide core {product-title} functionality.
 ** *User*. User-defined workload alerting rules relate to user-defined projects. These alerting rules are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.
 
-[discrete]
+[id="searching-filtering-alerts-dev-perspective_{context}"]
 == Searching and filtering alerts, silences, and alerting rules in the Developer perspective
 
 In the *Developer* perspective, the *Alerts* page in the Alerting UI provides a combined view of alerts and silences relating to the selected project. A link to the governing alerting rule is provided for each displayed alert.
diff --git a/modules/monitoring-setting-log-levels-for-monitoring-components.adoc b/modules/monitoring-setting-log-levels-for-monitoring-components.adoc
index d21b6635e79e..0224ab2fe665 100644
--- a/modules/monitoring-setting-log-levels-for-monitoring-components.adoc
+++ b/modules/monitoring-setting-log-levels-for-monitoring-components.adoc
@@ -6,19 +6,29 @@
 [id="setting-log-levels-for-monitoring-components_{context}"]
 = Setting log levels for monitoring components
 
-You can configure the log level for
-ifndef::openshift-dedicated,openshift-rosa[]
-Alertmanager, Prometheus Operator, Prometheus, Thanos Querier, and Thanos Ruler.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-Alertmanager, Prometheus Operator, Prometheus, and Thanos Ruler.
-endif::openshift-dedicated,openshift-rosa[]
-
-The following log levels can be applied to the relevant component in the
-ifndef::openshift-dedicated,openshift-rosa[]
-`cluster-monitoring-config` and
-endif::openshift-dedicated,openshift-rosa[]
-`user-workload-monitoring-config` `ConfigMap` objects:
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:prometheus: prometheusK8s
+:alertmanager: alertmanagerMain
+:thanos: thanosQuerier
+:component-name: Thanos Querier
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:prometheus: prometheus
+:alertmanager: alertmanager
+:thanos: thanosRuler
+:component-name: Thanos Ruler
+// end::UWM[]
+
+You can configure the log level for Alertmanager, Prometheus Operator, Prometheus, and {component-name}.
+
+
+The following log levels can be applied to the relevant component in the `{configmap-name}` `ConfigMap` object:
 
 * `debug`. Log debug, informational, warning, and error messages.
 * `info`. Log informational, warning, and error messages.
@@ -29,103 +39,84 @@ The default log level is `info`.
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are setting a log level for Alertmanager, Prometheus Operator, Prometheus, or Thanos Querier in the `openshift-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are setting a log level for Prometheus Operator, Prometheus, or Thanos Ruler in the `openshift-user-workload-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
+
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Edit the `ConfigMap` object:
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To set a log level for a component in the `openshift-monitoring` project*:
-.. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-.. Add `logLevel: <log_level>` for a component under `data/config.yaml`:
+. Add `logLevel: <log_level>` for a component under `data/config.yaml`:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    <component>: <1>
-      logLevel: <log_level> <2>
+    <component>: # <1>
+      logLevel: <log_level> # <2>
 ----
 <1> The monitoring stack component for which you are setting a log level.
-For default platform monitoring, available component values are `prometheusK8s`, `alertmanagerMain`, `prometheusOperator`, and `thanosQuerier`.
+Available component values are `{prometheus}`, `{alertmanager}`, `prometheusOperator`, and `{thanos}`.
 <2> The log level to set for the component.
 The available values are `error`, `warn`, `info`, and `debug`.
 The default value is `info`.
 
-** *To set a log level for a component in the `openshift-user-workload-monitoring` project*:
-endif::openshift-dedicated,openshift-rosa[]
-
-.. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
-----
-
-.. Add `logLevel: <log_level>` for a component under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    <component>: <1>
-      logLevel: <log_level> <2>
-----
-<1> The monitoring stack component for which you are setting a log level.
-For user workload monitoring, available component values are `alertmanager`, `prometheus`, `prometheusOperator`, and `thanosRuler`.
-<2> The log level to apply to the component. The available values are `error`, `warn`, `info`, and `debug`. The default value is `info`.
-
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
-. Confirm that the log-level has been applied by reviewing the deployment or pod configuration in the related project. The following example checks the log level in the `prometheus-operator` deployment in the `openshift-user-workload-monitoring` project:
+. Confirm that the log level has been applied by reviewing the deployment or pod configuration in the related project. 
+The following example checks the log level for the `prometheus-operator` deployment:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"
+$ oc -n {namespace-name} get deploy prometheus-operator -o yaml | grep "log-level"
 ----
 +
 .Example output
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
         - --log-level=debug
 ----
 
-. Check that the pods for the component are running. The following example lists the status of pods in the `openshift-user-workload-monitoring` project:
+. Check that the pods for the component are running. The following example lists the status of pods:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-user-workload-monitoring get pods
+$ oc -n {namespace-name} get pods
 ----
 +
 [NOTE]
 ====
 If an unrecognized `logLevel` value is included in the `ConfigMap` object, the pods for the component might not restart successfully.
 ====
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!prometheus:
+:!alertmanager:
+:!thanos:
+:!component-name:
diff --git a/modules/monitoring-setting-query-log-file-for-prometheus.adoc b/modules/monitoring-setting-query-log-file-for-prometheus.adoc
index 5aef6e5a24bc..6457cd5462f6 100644
--- a/modules/monitoring-setting-query-log-file-for-prometheus.adoc
+++ b/modules/monitoring-setting-query-log-file-for-prometheus.adoc
@@ -6,11 +6,22 @@
 [id="setting-query-log-file-for-prometheus_{context}"]
 = Enabling the query log file for Prometheus
 
-[role="_abstract"]
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
+
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:component: prometheusK8s
+:pod: prometheus-k8s-0
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:component: prometheus
+:pod: prometheus-user-workload-0
+// end::UWM[]
+
 You can configure Prometheus to write all queries that have been run by the engine to a log file.
-ifndef::openshift-dedicated,openshift-rosa[]
-You can do so for default platform monitoring and for user-defined workload monitoring.
-endif::openshift-dedicated,openshift-rosa[]
 
 [IMPORTANT]
 ====
@@ -19,110 +30,98 @@ Because log rotation is not supported, only enable this feature temporarily when
 
 .Prerequisites
 
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `cluster-monitoring-config` `ConfigMap` object.
+// end::CPM[]
+// tag::UWM[]
 ifndef::openshift-dedicated,openshift-rosa[]
-* *If you are enabling the query log file feature for Prometheus in the `openshift-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created the `cluster-monitoring-config` `ConfigMap` object.
-* *If you are enabling the query log file feature for Prometheus in the `openshift-user-workload-monitoring` project*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
-** A cluster administrator has enabled monitoring for user-defined projects.
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+* A cluster administrator has enabled monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
+
 ifdef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
 * The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
 endif::openshift-dedicated,openshift-rosa[]
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-ifndef::openshift-dedicated,openshift-rosa[]
-** *To set the query log file for Prometheus in the `openshift-monitoring` project*:
-. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
+
+. Add the `queryLogFile` parameter for Prometheus under `data/config.yaml`:
 +
-. Add `queryLogFile: <path>` for `prometheusK8s` under `data/config.yaml`:
-+
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    prometheusK8s:
-      queryLogFile: <path> <1>
+    {component}:
+      queryLogFile: <path> # <1>
 ----
-<1> The full path to the file in which queries will be logged.
-+
+<1> Add the full path to the file in which queries will be logged.
+
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
-+
-. Verify that the pods for the component are running. The following sample command lists the status of pods in the `openshift-monitoring` project:
-+
-[source,terminal]
-----
-$ oc -n openshift-monitoring get pods
-----
-+
-. Read the query log:
-+
-[source,terminal]
-----
-$ oc -n openshift-monitoring exec prometheus-k8s-0 -- cat <path>
-----
-+
-[IMPORTANT]
-====
-Revert the setting in the config map after you have examined the logged query information.
-====
 
-** *To set the query log file for Prometheus in the `openshift-user-workload-monitoring` project*:
-endif::openshift-dedicated,openshift-rosa[]
-. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
+. Verify that the pods for the component are running. The following sample command lists the status of pods:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
+$ oc -n {namespace-name} get pods
 ----
 +
-. Add `queryLogFile: <path>` for `prometheus` under `data/config.yaml`:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: user-workload-monitoring-config
-  namespace: openshift-user-workload-monitoring
-data:
-  config.yaml: |
-    prometheus:
-      queryLogFile: <path> <1>
+// tag::CPM[]
+.Example output
+[source,terminal]
 ----
-<1> The full path to the file in which queries will be logged.
-+
-. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
-+
-. Verify that the pods for the component are running. The following example command lists the status of pods in the `openshift-user-workload-monitoring` project:
-+
+...
+prometheus-operator-567c9bc75c-96wkj   2/2     Running   0          62m
+prometheus-k8s-0                       6/6     Running   1          57m
+prometheus-k8s-1                       6/6     Running   1          57m
+thanos-querier-56c76d7df4-2xkpc        6/6     Running   0          57m
+thanos-querier-56c76d7df4-j5p29        6/6     Running   0          57m
+...
+----
+// end::CPM[]
+// tag::UWM[]
+.Example output
 [source,terminal]
 ----
-$ oc -n openshift-user-workload-monitoring get pods
+...
+prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
+prometheus-user-workload-0             5/5     Running   1          132m
+prometheus-user-workload-1             5/5     Running   1          132m
+thanos-ruler-user-workload-0           3/3     Running   0          132m
+thanos-ruler-user-workload-1           3/3     Running   0          132m
+...
 ----
-+
+// end::UWM[]
+
 . Read the query log:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>
+$ oc -n {namespace-name} exec {pod} -- cat <path>
 ----
 +
 [IMPORTANT]
 ====
 Revert the setting in the config map after you have examined the logged query information.
 ====
+
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!component:
+:!pod:
diff --git a/modules/monitoring-shiftstack-metrics.adoc b/modules/monitoring-shiftstack-metrics.adoc
new file mode 100644
index 000000000000..c9abf138aa13
--- /dev/null
+++ b/modules/monitoring-shiftstack-metrics.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// * observability/monitoring/shiftstack-prometheus-configuration.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="monitoring-shiftstack-metrics.adoc_{context}"]
+= Available metrics for clusters that run on RHOSO
+
+To query metrics and identifying resources across the stack, there are helper metrics that establish a correlation between {rhoso-first} infrastructure resources and their representations in the tenant {product-title} cluster.
+
+To map nodes with {rhoso} compute instances, in the metric `kube_node_info`:
+
+* `node` is the Kubernetes node name.
+
+* `provider_id` contains the identifier of the corresponding compute service instance.
+
+To map persistent volumes with {rhoso} block storage or shared filesystems shares, in the metric `kube_persistentvolume_info`:
+
+* `persistentvolume` is the volume name.
+
+* `csi_volume_handle` is the block storage volume or share identifier.
+
+By default, the compute machines that back the cluster control plane nodes are created in a server group with a soft anti-affinity policy. As a result, the compute service creates them on separate hypervisors on a best-effort basis. However, if the state of the {rhoso} cluster is not appropriate for this distribution, the machines are created anyway.
+
+In combination with the default soft anti-affinity policy, you can configure an alert that activates when a hypervisor hosts more than one control plane node of a given cluster to highlight the degraded level of high availability.
+
+As an example, this PromQL query returns the number of {product-title} master nodes per {rh-openstack} host:
+
+[source,promql]
+----
+sum by (vm_instance) (
+  group by (vm_instance, resource) (ceilometer_cpu)
+    / on (resource) group_right(vm_instance) (
+      group by (node, resource) (
+        label_replace(kube_node_info, "resource", "$1", "system_uuid", "(.+)")
+      )
+    / on (node) group_left group by (node) (
+      cluster:master_nodes
+    )
+  )
+)
+----
\ No newline at end of file
diff --git a/modules/monitoring-silencing-alerts.adoc b/modules/monitoring-silencing-alerts.adoc
index d6674aa83f75..0a20e4f2fab8 100644
--- a/modules/monitoring-silencing-alerts.adoc
+++ b/modules/monitoring-silencing-alerts.adoc
@@ -3,13 +3,28 @@
 // * observability/monitoring/managing-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="silencing-alerts_{context}"]
-= Silencing alerts
+
+// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
+
+// tag::ADM[]
+[id="silencing-alerts-adm_{context}"]
+= Silencing alerts from the Administrator perspective
+// end::ADM[]
+
+// tag::DEV[]
+[id="silencing-alerts-dev_{context}"]
+= Silencing alerts from the Developer perspective
+// end::DEV[]
 
 You can silence a specific alert or silence alerts that match a specification that you define.
 
 .Prerequisites
 
+// tag::ADM[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+// end::ADM[]
+
+// tag::DEV[]
 ifndef::openshift-dedicated,openshift-rosa[]
 * If you are a cluster administrator, you have access to the cluster as a user with the `cluster-admin` role.
 endif::openshift-dedicated,openshift-rosa[]
@@ -20,12 +35,14 @@ endif::openshift-dedicated,openshift-rosa[]
 ** The `cluster-monitoring-view` cluster role, which allows you to access Alertmanager.
 ** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts in the *Administrator* perspective in the web console.
 ** The `monitoring-rules-edit` cluster role, which permits you to create and silence alerts in the *Developer* perspective in the web console.
+// end::DEV[]
 
 .Procedure
 
-To silence a specific alert in the *Administrator* perspective:
+// tag::ADM[]
+To silence a specific alert:
 
-. Go to *Observe* -> *Alerting* -> *Alerts* in the {product-title} web console.
+. From the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Alerting* -> *Alerts*.
 
 . For the alert that you want to silence, click {kebab} and select *Silence alert* to open the *Silence alert* page with a default configuration for the chosen alert.
 
@@ -38,43 +55,49 @@ You must add a comment before saving a silence.
 
 . To save the silence, click *Silence*.
 
-To silence a specific alert in the *Developer* perspective:
-
-. Go to *Observe* -> *<project_name>* -> *Alerts* in the {product-title} web console.
-
-. If necessary, expand the details for the alert by selecting a greater than symbol (*>*) next to the alert name.
+To silence a set of alerts:
 
-. Click the alert message in the expanded view to open the *Alert details* page for the alert.
+. From the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Alerting* -> *Silences*.
 
-. Click *Silence alert* to open the *Silence alert* page with a default configuration for the alert.
+. Click *Create silence*.
 
-. Optional: Change the default configuration details for the silence.
+. On the *Create silence* page, set the schedule, duration, and label details for an alert.
 +
 [NOTE]
 ====
 You must add a comment before saving a silence.
 ====
 
-. To save the silence, click *Silence*.
+. To create silences for alerts that match the labels that you entered, click *Silence*.
+// end::ADM[]
 
-To silence a set of alerts by creating a silence configuration in the *Administrator* perspective:
+// tag::DEV[]
+To silence a specific alert:
 
-. Go to *Observe* -> *Alerting* -> *Silences* in the {product-title} web console.
+. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Alerts* tab.
 
-. Click *Create silence*.
+. Select the project that you want to silence an alert for from the *Project:* list. 
 
-. On the *Create silence* page, set the schedule, duration, and label details for an alert.
+. If necessary, expand the details for the alert by clicking a greater than symbol (*>*) next to the alert name.
+
+. Click the alert message in the expanded view to open the *Alert details* page for the alert.
+
+. Click *Silence alert* to open the *Silence alert* page with a default configuration for the alert.
+
+. Optional: Change the default configuration details for the silence.
 +
 [NOTE]
 ====
 You must add a comment before saving a silence.
 ====
 
-. To create silences for alerts that match the labels that you entered, click *Silence*.
+. To save the silence, click *Silence*.
+
+To silence a set of alerts:
 
-To silence a set of alerts by creating a silence configuration in the *Developer* perspective:
+. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Silences* tab.
 
-. Go to *Observe* -> *<project_name>* -> *Silences* in the {product-title} web console.
+. Select the project that you want to silence alerts for from the *Project:* list. 
 
 . Click *Create silence*.
 
@@ -86,3 +109,4 @@ You must add a comment before saving a silence.
 ====
 
 . To create silences for alerts that match the labels that you entered, click *Silence*.
+// end::DEV[]
\ No newline at end of file
diff --git a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc
index 7287f7ececd5..8387edadd7b5 100644
--- a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc
+++ b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc
@@ -4,51 +4,67 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="specifying-limits-and-resource-requests-for-monitoring-components_{context}"]
-= Specifying limits and requests for monitoring components
+= Specifying limits and requests
 
-To configure CPU and memory resources, specify values for resource limits and requests in the appropriate `ConfigMap` object for the namespace in which the monitoring component is located:
+// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples.
+// tag::CPM[]
+:configmap-name: cluster-monitoring-config
+:namespace-name: openshift-monitoring
+:alertmanager: alertmanagerMain
+:prometheus: prometheusK8s
+:thanos: thanosQuerier
+// end::CPM[]
+// tag::UWM[]
+:configmap-name: user-workload-monitoring-config
+:namespace-name: openshift-user-workload-monitoring
+:alertmanager: alertmanager
+:prometheus: prometheus
+:thanos: thanosRuler
+// end::UWM[]
 
-* The `cluster-monitoring-config` config map in the `openshift-monitoring` namespace for core platform monitoring
-* The `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` namespace for components that monitor user-defined projects
+To configure CPU and memory resources, specify values for resource limits and requests in the `{configmap-name}` `ConfigMap` object in the `{namespace-name}` namespace.
 
 .Prerequisites
 
-* *If you are configuring core platform monitoring components*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role.
-** You have created a `ConfigMap` object named `cluster-monitoring-config`.
-* *If you are configuring components that monitor user-defined projects*:
-** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+// tag::CPM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role.
+* You have created the `ConfigMap` object named `cluster-monitoring-config`.
+// end::CPM[]
+
+// tag::UWM[]
+* You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
+// end::UWM[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. To configure core platform monitoring components, edit the `cluster-monitoring-config` config map object in the `openshift-monitoring` namespace:
+. Edit the `{configmap-name}` config map in the `{namespace-name}` project:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
+$ oc -n {namespace-name} edit configmap {configmap-name}
 ----
 
-. Add values to define resource limits and requests for each core platform monitoring component you want to configure.
+. Add values to define resource limits and requests for each component you want to configure.
 +
 [IMPORTANT]
 ====
-Make sure that the value set for a limit is always higher than the value set for a request.
+Ensure that the value set for a limit is always higher than the value set for a request.
 Otherwise, an error will occur, and the container will not run.
 ====
 +
-.Example
+.Example of setting resource limits and requests
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: cluster-monitoring-config
-  namespace: openshift-monitoring
+  name: {configmap-name}
+  namespace: {namespace-name}
 data:
   config.yaml: |
-    alertmanagerMain:
+    {alertmanager}:
       resources:
         limits:
           cpu: 500m
@@ -56,7 +72,7 @@ data:
         requests:
           cpu: 200m
           memory: 500Mi
-    prometheusK8s:
+    {prometheus}:
       resources:
         limits:
           cpu: 500m
@@ -64,6 +80,15 @@ data:
         requests:
           cpu: 200m
           memory: 500Mi
+    {thanos}:
+      resources:
+        limits:
+          cpu: 500m
+          memory: 1Gi
+        requests:
+          cpu: 200m
+          memory: 500Mi
+# tag::CPM[]
     prometheusOperator:
       resources:
         limits:
@@ -104,14 +129,6 @@ data:
         requests:
           cpu: 200m
           memory: 500Mi
-    thanosQuerier:
-      resources:
-        limits:
-          cpu: 500m
-          memory: 1Gi
-        requests:
-          cpu: 200m
-          memory: 500Mi
     nodeExporter:
       resources:
         limits:
@@ -136,10 +153,14 @@ data:
         requests:
           cpu: 20m
           memory: 50Mi
+# end::CPM[]
 ----
 
 . Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
-[role="_additional-resources"]
-.Additional resources
-* link:https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits[Kubernetes requests and limits documentation]
+// Unset the source code block attributes just to be safe.
+:!configmap-name:
+:!namespace-name:
+:!alertmanager:
+:!prometheus:
+:!thanos:
\ No newline at end of file
diff --git a/modules/monitoring-support-version-matrix-for-monitoring-components.adoc b/modules/monitoring-support-version-matrix-for-monitoring-components.adoc
index 08bd4ba56e07..f34d9fe6c3de 100644
--- a/modules/monitoring-support-version-matrix-for-monitoring-components.adoc
+++ b/modules/monitoring-support-version-matrix-for-monitoring-components.adoc
@@ -12,6 +12,8 @@ The following matrix contains information about versions of monitoring component
 |===
 |{product-title} |Prometheus Operator |Prometheus  |Metrics Server |Alertmanager |kube-state-metrics agent |monitoring-plugin |node-exporter agent |Thanos
 
+|4.18 |0.78.1 |2.55.1 |0.7.2 |0.27.0 |2.13.0 |1.0.0 |1.8.2 |0.36.1
+
 |4.17 |0.75.2 |2.53.1 |0.7.1 |0.27.0 |2.13.0 |1.0.0 |1.8.2 |0.35.1
 
 |4.16 |0.73.2 |2.52.0 |0.7.1 |0.26.0 |2.12.0 |1.0.0 |1.8.0 |0.35.0
diff --git a/modules/monitoring-supported-remote-write-authentication-settings.adoc b/modules/monitoring-supported-remote-write-authentication-settings.adoc
index 864c4e70a2fa..55aff7883ba8 100644
--- a/modules/monitoring-supported-remote-write-authentication-settings.adoc
+++ b/modules/monitoring-supported-remote-write-authentication-settings.adoc
@@ -3,7 +3,7 @@
 // * observability/monitoring/configuring-the-monitoring-stack.adoc
 
 :_mod-docs-content-type: REFERENCE
-[id="supported_remote_write_authentication_settings_{context}"]
+[id="supported-remote-write-authentication-settings_{context}"]
 = Supported remote write authentication settings
 
 You can use different methods to authenticate with a remote write endpoint. Currently supported authentication methods are AWS Signature Version 4, basic authentication, authorization, OAuth 2.0, and TLS client. The following table provides details about supported authentication methods for use with remote write.
diff --git a/modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc
index a53525e3e5d5..00373dfc2318 100644
--- a/modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc
+++ b/modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc
@@ -13,7 +13,7 @@ endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 As a `dedicated-admin`, you can enable alert routing for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
-With this feature, you can allow users with the **alert-routing-edit** role to configure alert notification routing and receivers for user-defined projects.
+With this feature, you can allow users with the `alert-routing-edit` cluster role to configure alert notification routing and receivers for user-defined projects.
 ifndef::openshift-dedicated,openshift-rosa[]
 These notifications are routed by the default Alertmanager instance or, if enabled, an optional Alertmanager instance dedicated to user-defined monitoring.
 endif::openshift-dedicated,openshift-rosa[]
@@ -36,7 +36,7 @@ endif::openshift-dedicated,openshift-rosa[]
 
 [NOTE]
 ====
-The following are limitations of alert routing for user-defined projects:
+Review the following limitations of alert routing for user-defined projects:
 
 * For user-defined alerting rules, user-defined routing is scoped to the namespace in which the resource is defined. For example, a routing configuration in namespace `ns1` only applies to `PrometheusRules` resources in the same namespace.
 
diff --git a/modules/monitoring-understanding-the-monitoring-stack.adoc b/modules/monitoring-understanding-the-monitoring-stack.adoc
index 87b1359ec5f0..e6922b364897 100644
--- a/modules/monitoring-understanding-the-monitoring-stack.adoc
+++ b/modules/monitoring-understanding-the-monitoring-stack.adoc
@@ -11,11 +11,7 @@
 [id="understanding-the-monitoring-stack_{context}"]
 = Understanding the monitoring stack
 
-The {product-title}
-ifdef::openshift-rosa[]
-(ROSA)
-endif::openshift-rosa[]
-monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. The monitoring stack includes the following:
+The monitoring stack includes the following components:
 
 * *Default platform monitoring components*.
 ifndef::openshift-dedicated,openshift-rosa[]
diff --git a/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc b/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc
index 766176960ef4..ecbadb1b46c7 100644
--- a/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc
+++ b/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc
@@ -9,16 +9,15 @@
 By using the `nodeSelector` constraint with labeled nodes, you can move any of the monitoring stack components to specific nodes.
 By doing so, you can control the placement and distribution of the monitoring components across a cluster.
 
-By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and segregate workloads based on specific requirements or policies.
+By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies.
 
-[id="how-node-selectors-work-with-other-constraints_{context}"]
+[discrete]
 == How node selectors work with other constraints
 
-
 If you move monitoring components by using node selector constraints, be aware that other constraints to control pod scheduling might exist for a cluster:
 
 * Topology spread constraints might be in place to control pod placement.
-* Hard anti-affinity rules are in place for Prometheus, Thanos Querier, Alertmanager, and other monitoring components to ensure that multiple pods for these components are always spread across different nodes and are therefore always highly available.
+* Hard anti-affinity rules are in place for Prometheus, Alertmanager, and other monitoring components to ensure that multiple pods for these components are always spread across different nodes and are therefore always highly available.
 
 When scheduling pods onto nodes, the pod scheduler tries to satisfy all existing constraints when determining pod placement.
 That is, all constraints compound when the pod scheduler determines which pods will be placed on which nodes.
diff --git a/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc b/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc
index 9eb16490f834..240c4c20b4d7 100644
--- a/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc
+++ b/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc
@@ -4,16 +4,12 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="using-pod-topology-spread-constraints-for-monitoring_{context}"]
-= Using pod topology spread constraints for monitoring
+= About pod topology spread constraints for monitoring
 
-You can use pod topology spread constraints to control how
-ifndef::openshift-dedicated,openshift-rosa[]
-the monitoring pods
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-the pods for user-defined monitoring
-endif::openshift-dedicated,openshift-rosa[]
-are spread across a network topology when {product-title} pods are deployed in multiple availability zones.
+You can use pod topology spread constraints to control how the monitoring pods are spread across a network topology when {product-title} pods are deployed in multiple availability zones.
 
 Pod topology spread constraints are suitable for controlling pod scheduling within hierarchical topologies in which nodes are spread across different infrastructure levels, such as regions and zones within those regions.
-Additionally, by being able to schedule pods in different zones, you can improve network latency in certain scenarios.
\ No newline at end of file
+Additionally, by being able to schedule pods in different zones, you can improve network latency in certain scenarios.
+
+You can configure pod topology spread constraints for all the pods deployed by the {cmo-full} to control how pod replicas are scheduled to nodes across zones. This ensures that the pods are highly available and run more efficiently, because workloads are spread across nodes in different data centers or hierarchical infrastructure zones.
+
diff --git a/modules/monitoring-validating-a-monitoringstack-for-cluster-observability-operator.adoc b/modules/monitoring-validating-a-monitoringstack-for-cluster-observability-operator.adoc
new file mode 100644
index 000000000000..c52ef5a7baa4
--- /dev/null
+++ b/modules/monitoring-validating-a-monitoringstack-for-cluster-observability-operator.adoc
@@ -0,0 +1,81 @@
+// Module included in the following assemblies:
+//
+// * observability/cluster-observability-operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="monitoring-validating-a-monitoringstack-for-cluster-observability-operator_{context}"]
+= Validating the monitoring stack
+
+To validate that the monitoring stack is working correctly, access the example service and then view the gathered metrics.
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with administrative permissions for the namespace.
+* You have installed the {coo-full}.
+* You have deployed the `prometheus-coo-example-app` sample service in the `ns1-coo` namespace.
+* You have created a `ServiceMonitor` object named `prometheus-coo-example-monitor` in the `ns1-coo` namespace.
+* You have created a `MonitoringStack` object named `example-coo-monitoring-stack` in the `ns1-coo` namespace.
+
+.Procedure
+
+. Create a route to expose the example `prometheus-coo-example-app` service. From your terminal, run the command:
++
+[source,terminal]
+----
+$ oc expose svc prometheus-coo-example-app -n ns1-coo
+----
+. Access the route from your browser, or command line, to generate metrics.
+
+. Execute a query on the Prometheus pod to return the total HTTP requests metric:
++
+[source,terminal]
+----
+$ oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/query?query=http_requests_total'
+----
++
+.Example output (formatted using `jq` for convenience)
+[source,json]
+----
+{
+  "status": "success",
+  "data": {
+    "resultType": "vector",
+    "result": [
+      {
+        "metric": {
+          "__name__": "http_requests_total",
+          "code": "200",
+          "endpoint": "web",
+          "instance": "10.129.2.25:8080",
+          "job": "prometheus-coo-example-app",
+          "method": "get",
+          "namespace": "ns1-coo",
+          "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
+          "service": "prometheus-coo-example-app"
+        },
+        "value": [
+          1730807483.632,
+          "3"
+        ]
+      },
+      {
+        "metric": {
+          "__name__": "http_requests_total",
+          "code": "404",
+          "endpoint": "web",
+          "instance": "10.129.2.25:8080",
+          "job": "prometheus-coo-example-app",
+          "method": "get",
+          "namespace": "ns1-coo",
+          "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
+          "service": "prometheus-coo-example-app"
+        },
+        "value": [
+          1730807483.632,
+          "0"
+        ]
+      }
+    ]
+  }
+}
+----
diff --git a/modules/mos-network-prereqs-min-bandwidth.adoc b/modules/mos-network-prereqs-min-bandwidth.adoc
index 56675c3b2d6b..5e5900d061ac 100644
--- a/modules/mos-network-prereqs-min-bandwidth.adoc
+++ b/modules/mos-network-prereqs-min-bandwidth.adoc
@@ -2,14 +2,9 @@
 //
 // * rosa_planning/rosa-sts-aws-prereqs.adoc
 
-//Define the minimum bandwidth variable here so we can use this same module across all managed variants as testing completes for XCMSTRAT-422
-ifdef::openshift-rosa,openshift-rosa-classic,openshift-rosa-hcp,openshift-osd,openshift-azure[]
-:mos-min-bandwidth: 120{nbsp}Mbps
-endif::[]
-
 [id="mos-network-prereqs-min-bandwidth_{context}"]
 = Minimum bandwidth
 
-During cluster deployment, {product-title} requires a minimum bandwidth of {mos-min-bandwidth} between cluster resources and public internet resources. When network connectivity is slower than {mos-min-bandwidth} (for example, when connecting through a proxy) the cluster installation process times out and deployment fails.
+During cluster deployment, {product-title} requires a minimum bandwidth of 120{nbsp}Mbps between cluster resources and public internet resources. When network connectivity is slower than 120{nbsp}Mbps (for example, when connecting through a proxy) the cluster installation process times out and deployment fails.
 
-After deployment, network requirements are determined by your workload. However, a minimum bandwidth of {mos-min-bandwidth} helps to ensure timely cluster and operator upgrades.
+After deployment, network requirements are determined by your workload. However, a minimum bandwidth of 120{nbsp}Mbps helps to ensure timely cluster and operator upgrades.
diff --git a/modules/mtc-operator-supported.adoc b/modules/mtc-operator-supported.adoc
new file mode 100644
index 000000000000..7b308424eced
--- /dev/null
+++ b/modules/mtc-operator-supported.adoc
@@ -0,0 +1,43 @@
+// Module included in the following assemblies:
+//
+// * migration_toolkit_for_containers/about-mtc.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="mtc-operator-supported_{context}"]
+= Support for {mtc-first}
+
+.Supported versions of {mtc-short}
+[width="100%",cols="10%,14%,20%,22%,22%,22%,options="header"]
+|===
+|{mtc-short} version
+|{product-title} version
+|General availability
+|Full support ends
+|Maintenance ends
+|Extended Update Support (EUS)
+
+|1.8
+a|
+* 4.14
+* 4.15
+* 4.16
+* 4.17
+|02 Oct 2023
+|Release of 1.9
+|Release of 1.10
+|N/A
+
+|1.7
+a|
+* 3
+* 4.14
+* 4.15
+* 4.16
+|01 Mar 2022
+|01 Jul 2024
+|01 Jul 2025
+|N/A
+|===
+
+For more details about EUS, see link:https://access.redhat.com/support/policy/updates/openshift#eus[Extended Update Support].
+
diff --git a/modules/multi-arch-creating-podplacment-config-using-cli.adoc b/modules/multi-arch-creating-podplacment-config-using-cli.adoc
index e4d0ff8bf189..faedc9a3e219 100644
--- a/modules/multi-arch-creating-podplacment-config-using-cli.adoc
+++ b/modules/multi-arch-creating-podplacment-config-using-cli.adoc
@@ -30,7 +30,15 @@ spec:
   namespaceSelector:
     matchExpressions:
       - key: multiarch.openshift.io/exclude-pod-placement 
-        operator: DoesNotExist 
+        operator: DoesNotExist
+  plugins:
+    nodeAffinityScoring:
+      enabled: true
+      platforms:
+        - architecture: amd64
+          weight: 100
+        - architecture: arm64
+          weight: 50
 ----
 
 . Create the `ClusterPodPlacementConfig` object by running the following command:
diff --git a/modules/multi-arch-creating-podplacment-config.adoc b/modules/multi-arch-creating-podplacment-config.adoc
index 324b2937e137..be68140122de 100644
--- a/modules/multi-arch-creating-podplacment-config.adoc
+++ b/modules/multi-arch-creating-podplacment-config.adoc
@@ -25,11 +25,25 @@ spec:
   namespaceSelector: <3>
     matchExpressions:
       - key: multiarch.openshift.io/exclude-pod-placement 
-        operator: DoesNotExist 
+        operator: DoesNotExist
+  plugins: <4>
+    nodeAffinityScoring: <5>
+      enabled: true <6>
+      platforms: <7>
+        - architecture: amd64 <8>
+          weight: 100 <9>
+        - architecture: arm64
+          weight: 50
 ----
 <1> You must set this field value to `cluster`. 
 <2> Optional: You can set the field value to `Normal`, `Debug`, `Trace`, or `TraceAll`. The value is set to `Normal` by default. 
 <3> Optional: You can configure the `namespaceSelector` to select the namespaces in which the Multiarch Tuning Operator's pod placement operand must process the `nodeAffinity` of the pods. All namespaces are considered by default.
+<4> Optional: Includes a list of plugins for architecture-aware workload scheduling.
+<5> Optional: You can use this plugin to set architecture preferences for pod placement. When enabled, the scheduler first filters out nodes that do not meet the pod’s requirements. Then, it prioritizes the remaining nodes based on the architecture scores defined in the `nodeAffinityScoring.platforms` field.
+<6> Optional: Set this field to `true` to enable the `nodeAffinityScoring` plugin. The default value is `false`.
+<7> Optional: Defines a list of architectures and their corresponding scores.
+<8> Specify the node architecture to score. The scheduler prioritizes nodes for pod placement based on the architecture scores that you set and the scheduling requirements defined in the pod specification. Accepted values are `arm64`, `amd64`, `ppc64le`, or `s390x`.
+<9> Assign a score to the architecture. The value for this field must be configured in the range of `1` (lowest priority) to `100` (highest priority). The scheduler uses this score to prioritize nodes for pod placement, favoring nodes with architectures that have higher scores.
 
 In this example, the `operator` field value is set to `DoesNotExist`. Therefore, if the `key` field value (`multiarch.openshift.io/exclude-pod-placement`) is set as a label in a namespace, the operand does not process the `nodeAffinity` of the pods in that namespace. Instead, the operand processes the `nodeAffinity` of the pods in namespaces that do not contain the label.
 
diff --git a/modules/multi-arch-gather-info-about-workloads.adoc b/modules/multi-arch-gather-info-about-workloads.adoc
index 914584f6ba5f..0d4c3d057334 100644
--- a/modules/multi-arch-gather-info-about-workloads.adoc
+++ b/modules/multi-arch-gather-info-about-workloads.adoc
@@ -27,5 +27,6 @@ The following table describes the labels that the Multiarch Tuning Operator adds
 |`multiarch.openshift.io/scheduling-gate: gated` |The pod is gated.
 |`multiarch.openshift.io/scheduling-gate: removed` |The pod gate has been removed.
 |`multiarch.openshift.io/inspection-error: ""` |An error has occurred while building the node affinity requirements.
-
+|`multiarch.openshift.io/preferred-node-affinity: set` |The Operator has set the architecture preferences in the pod.
+|`multiarch.openshift.io/preferred-node-affinity: not-set` |The Operator did not set the architecture preferences in the pod because the user had already set them in the `preferredDuringSchedulingIgnoredDuringExecution` node affinity.
 |====
\ No newline at end of file
diff --git a/modules/multi-arch-installing-using-cli.adoc b/modules/multi-arch-installing-using-cli.adoc
index 22b89a91d85f..1c4e0d32ecff 100644
--- a/modules/multi-arch-installing-using-cli.adoc
+++ b/modules/multi-arch-installing-using-cli.adoc
@@ -63,7 +63,7 @@ spec:
   source: redhat-operators
   sourceNamespace: openshift-marketplace
   installPlanApproval: Automatic
-  startingCSV: multiarch-tuning-operator.v1.0.0
+  startingCSV: multiarch-tuning-operator.<version>
 ----
 
 .. Create the `Subscription` object by running the following command:
@@ -91,8 +91,8 @@ $ oc get csv -n openshift-multiarch-tuning-operator
 .Example output
 [source,terminal]
 ----
-NAME                               DISPLAY                     VERSION   REPLACES                              PHASE
-multiarch-tuning-operator.v1.0.0   Multiarch Tuning Operator   1.0.0     multiarch-tuning-operator.v0.9.0      Succeeded
+NAME                                   DISPLAY                     VERSION       REPLACES                            PHASE
+multiarch-tuning-operator.<version>   Multiarch Tuning Operator   <version>     multiarch-tuning-operator.1.0.0      Succeeded
 ----
 +
 The installation is successful if the Operator is in `Succeeded` phase.
diff --git a/modules/multi-arch-uninstalling-using-cli.adoc b/modules/multi-arch-uninstalling-using-cli.adoc
index 2df2a74b3547..ca5724682afc 100644
--- a/modules/multi-arch-uninstalling-using-cli.adoc
+++ b/modules/multi-arch-uninstalling-using-cli.adoc
@@ -47,7 +47,7 @@ $ oc get subscription.operators.coreos.com <subscription_name> -n <namespace> -o
 .Example output
 [source,terminal]
 ----
-currentCSV: multiarch-tuning-operator.v1.0.0
+currentCSV: multiarch-tuning-operator.<version>
 ----
 
 . Delete the `Subscription` object by running the following command:
@@ -70,12 +70,12 @@ subscription.operators.coreos.com "openshift-multiarch-tuning-operator" deleted
 ----
 $ oc delete clusterserviceversion <currentCSV_value> -n <namespace> <1>
 ----
-<1> Replace `<currentCSV>` with the `currentCSV` value for the Multiarch Tuning Operator. For example: `multiarch-tuning-operator.v1.0.0`. Replace `<namespace>` with the name of the namespace where you want to uninstall the Multiarch Tuning Operator.
+<1> Replace `<currentCSV>` with the `currentCSV` value for the Multiarch Tuning Operator. For example: `multiarch-tuning-operator.<version>`. Replace `<namespace>` with the name of the namespace where you want to uninstall the Multiarch Tuning Operator.
 +
 .Example output
 [source,terminal]
 ----
-clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.v1.0.0" deleted
+clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.<version>" deleted
 ----
 
 .Verification
diff --git a/modules/multi-architecture-modify-machine-set-aws.adoc b/modules/multi-architecture-modify-machine-set-aws.adoc
index a919b8d632e8..d4e9fedcd91a 100644
--- a/modules/multi-architecture-modify-machine-set-aws.adoc
+++ b/modules/multi-architecture-modify-machine-set-aws.adoc
@@ -79,12 +79,12 @@ spec:
             - filters:
                 - name: tag:Name
                   values:
-                    - <infrastructure_id>-worker-sg <1>
+                    - <infrastructure_id>-node <1>
           subnet:
             filters:
               - name: tag:Name
                 values:
-                  - <infrastructure_id>-private-<zone>
+                  - <infrastructure_id>-subnet-private-<zone>
           tags:
             - name: kubernetes.io/cluster/<infrastructure_id> <1>
               value: owned
@@ -97,11 +97,11 @@ spec:
 +
 [source,terminal]
 ----
-$ oc get -o jsonpath=‘{.status.infrastructureName}{“\n”}’ infrastructure cluster
+$ oc get -o jsonpath="{.status.infrastructureName}{'\n'}" infrastructure cluster
 ----
 <2> Specify the infrastructure ID, role node label, and zone.
 <3> Specify the role node label to add.
-<4> Specify a Red{nbsp}Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) for your AWS zone for the nodes. The RHCOS AMI must be compatible with the machine architecture.
+<4> Specify a {op-system-first} Amazon Machine Image (AMI) for your AWS region for the nodes. The {op-system} AMI must be compatible with the machine architecture.
 +
 [source,terminal]
 ----
diff --git a/modules/multi-architecture-scheduling.adoc b/modules/multi-architecture-scheduling.adoc
index 9f0655cc3252..3cbfe837c5b4 100644
--- a/modules/multi-architecture-scheduling.adoc
+++ b/modules/multi-architecture-scheduling.adoc
@@ -4,6 +4,8 @@
 
 When you deploy workloads on a cluster with compute nodes that use different architectures, you must align pod architecture with the architecture of the underlying node. Your workload may also require additional configuration to particular resources depending on the underlying node architecture.
 
-ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 You can use the Multiarch Tuning Operator to enable architecture-aware scheduling of workloads on clusters with multi-architecture compute machines. The Multiarch Tuning Operator implements additional scheduler predicates in the pods specifications based on the architectures that the pods can support at creation time.
-endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
+ifndef::openshift-enterprise[]
+For information about the Multiarch Tuning Operator, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/postinstallation_configuration/configuring-multi-architecture-compute-machines-on-an-openshift-cluster#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator].
+endif::openshift-enterprise[]
\ No newline at end of file
diff --git a/modules/network-flow-matrix.adoc b/modules/network-flow-matrix.adoc
index 20844f7488ca..a448cf6aff83 100644
--- a/modules/network-flow-matrix.adoc
+++ b/modules/network-flow-matrix.adoc
@@ -102,4 +102,4 @@ In addition to the base network flows, the following matrix describes the ingres
 [%header,format=csv]
 |===
 include::https://raw.githubusercontent.com/openshift-kni/commatrix/release-4.18/docs/stable/unique/aws-sno.csv[]
-|===
+|===
\ No newline at end of file
diff --git a/modules/network-observability-cli-capturing-metrics.adoc b/modules/network-observability-cli-capturing-metrics.adoc
new file mode 100644
index 000000000000..ace7a4f702b4
--- /dev/null
+++ b/modules/network-observability-cli-capturing-metrics.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * observability/network_observability/netobserv_cli/netobserv-cli-using.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-cli-capturing-metrics_{context}"]
+= Capturing metrics
+You can generate on-demand dashboards in Prometheus by using a service monitor for Network Observability.
+
+.Prerequisites
+* Install the {oc-first}.
+* Install the Network Observability CLI (`oc netobserv`) plugin.
+
+.Procedure
+. Capture metrics with filters enabled by running the following command:
++
+.Example output
+[source,terminal]
+----
+$ oc netobserv metrics --enable_filter=true --cidr=0.0.0.0/0 --protocol=TCP --port=49051
+----
+. Open the link provided in the terminal to view the *NetObserv / On-Demand* dashboard:
++ 
+.Example URL
+[source,terminal]
+----
+https://console-openshift-console.apps.rosa...openshiftapps.com/monitoring/dashboards/netobserv-cli
+----
++
+[NOTE]
+====
+Features that are not enabled present as empty graphs.
+====
\ No newline at end of file
diff --git a/modules/network-observability-creating-metrics-network-events.adoc b/modules/network-observability-creating-metrics-network-events.adoc
new file mode 100644
index 000000000000..59e0d5ce2c92
--- /dev/null
+++ b/modules/network-observability-creating-metrics-network-events.adoc
@@ -0,0 +1,56 @@
+// Module included in the following assemblies:
+//
+// * observability/network_observability/mertics-alerts-dashboards.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-creating-metrics-network-events_{context}"]
+= Creating metrics from nested or array fields in the Traffic flows table
+
+:FeatureName: OVN Observability / Viewing `NetworkEvents`
+include::snippets/technology-preview.adoc[]
+[IMPORTANT]
+====
+OVN Observability and the ability to view and track network events is available only in {product-title} 4.17 and 4.18. 
+====
+You can create a `FlowMetric` resource to generate metrics for nested or array fields in the *Traffic flows* table, such as *Network events* or *Interfaces*. The following example shows how to generate metrics from the *Network events* field for network policy events. 
+
+.Prerequsities
+* Enable `NetworkEvents feature`. See the Additional resources for how to do this. 
+* A network policy specified. 
+
+.Procedure
+. In the web console, navigate to *Operators* -> *Installed Operators*.
+. In the *Provided APIs* heading for the *NetObserv Operator*, select *FlowMetric*.
+. In the *Project*  dropdown list, select the project of the Network Observability Operator instance. 
+. Click *Create FlowMetric*.
+. Create `FlowMetric` resources to add the following configurations: 
++
+.Configuration counting network policy events per policy name and namespace
+[source,yaml]
+----
+apiVersion: flows.netobserv.io/v1alpha1
+kind: FlowMetric
+metadata:
+  name: network-policy-events
+  namespace: netobserv
+spec:
+  metricName: network_policy_events_total
+  type: Counter
+  labels: [NetworkEvents>Type, NetworkEvents>Namespace, NetworkEvents>Name, NetworkEvents>Action, NetworkEvents>Direction]       <1>
+  filters:
+  - field: NetworkEvents>Feature
+    value: acl
+  flatten: [NetworkEvents]       <2>
+  remap:                         <3>
+    "NetworkEvents>Type": type
+    "NetworkEvents>Namespace": namespace
+    "NetworkEvents>Name": name
+    "NetworkEvents>Direction": direction
+----
+<1> These labels represent the nested fields for *Network Events* from the *Traffic flows* table. Each network event has a specific type, namespace, name, action, and direction. You can alternatively specify the `Interfaces` if `NetworkEvents` is unavailable in your {product-title} version.
+<2> Optional: You can choose to represent a field that contains a list of items as distinct items.
+<3> Optional: You can rename the fields in Prometheus.  
+
+.Verification
+. In the web console, navigate to *Observe* -> *Dashboards* and scroll down to see the *Network Policy* tab. 
+. You should begin seeing metrics filter in based on the metric you created along with the network policy specifications. 
\ No newline at end of file
diff --git a/modules/network-observability-flowcollector-api-specifications.adoc b/modules/network-observability-flowcollector-api-specifications.adoc
index 367042fbd4e4..5764bb9aa881 100644
--- a/modules/network-observability-flowcollector-api-specifications.adoc
+++ b/modules/network-observability-flowcollector-api-specifications.adoc
@@ -102,7 +102,7 @@ Kafka can provide better scalability, resiliency, and high availability (for mor
 
 | `exporters`
 | `array`
-| `exporters` define additional optional exporters for custom consumption or storage.
+| `exporters` defines additional optional exporters for custom consumption or storage.
 
 | `kafka`
 | `object`
@@ -154,7 +154,7 @@ is set to `eBPF`.
 
 | `type`
 | `string`
-| `type` [deprecated (*)] selects the flows tracing agent. Previously, this field allowed to select between `eBPF` or `IPFIX`.
+| `type` [deprecated *] selects the flows tracing agent. Previously, this field allowed to select between `eBPF` or `IPFIX`.
 Only `eBPF` is allowed now, so this field is deprecated and is planned for removal in a future version of the API.
 
 |===
@@ -204,19 +204,26 @@ Otherwise it is matched as a case-sensitive string.
 | `array (string)`
 | List of additional features to enable. They are all disabled by default. Enabling additional features might have performance impacts. Possible values are: +
 
-- `PacketDrop`: enable the packets drop flows logging feature. This feature requires mounting
-the kernel debug filesystem, so the eBPF agent pods have to run as privileged.
+- `PacketDrop`: Enable the packets drop flows logging feature. This feature requires mounting
+the kernel debug filesystem, so the eBPF agent pods must run as privileged.
 If the `spec.agent.ebpf.privileged` parameter is not set, an error is reported. +
 
-- `DNSTracking`: enable the DNS tracking feature. +
+- `DNSTracking`: Enable the DNS tracking feature. +
 
-- `FlowRTT`: enable flow latency (sRTT) extraction in the eBPF agent from TCP traffic. +
+- `FlowRTT`: Enable flow latency (sRTT) extraction in the eBPF agent from TCP traffic. +
 
-- `NetworkEvents`: enable the network events monitoring feature, such as correlating flows and network policies.
-This feature requires mounting the kernel debug filesystem, so the eBPF agent pods have to run as privileged.
-It requires using the OVN-Kubernetes network plugin with the Observability feature.
-IMPORTANT: This feature is available as a Developer Preview. +
+- `NetworkEvents`: Enable the network events monitoring feature, such as correlating flows and network policies.
+This feature requires mounting the kernel debug filesystem, so the eBPF agent pods must run as privileged.
+It requires using the OVN-Kubernetes network plugin with the Observability feature. +
+IMPORTANT: This feature is available as a Technology Preview.
+
+- `PacketTranslation`: Enable enriching flows with packet translation information, such as Service NAT. +
 
+- `EbpfManager`: Unsupported * . Use eBPF Manager to manage Network Observability eBPF programs. Pre-requisite: the eBPF Manager operator (or upstream bpfman operator) must be installed. +
+
+- `UDNMapping`: Unsupported *. Enable interfaces mapping to User Defined Networks (UDN).  +
+This feature requires mounting the kernel debug filesystem, so the eBPF agent pods must run as privileged.
+It requires using the OVN-Kubernetes network plugin with the Observability feature.
 
 | `flowFilter`
 | `object`
@@ -407,6 +414,11 @@ To filter two ports, use a "port1,port2" in string format. For example, `ports:
 | `integer`
 | `icmpType`, for ICMP traffic, optionally defines the ICMP type to filter flows by.
 
+| `peerCIDR`
+| `string`
+| `peerCIDR` defines the Peer IP CIDR to filter flows by.
+Examples: `10.10.10.0/24` or `100:100:100:100::/64`
+
 | `peerIP`
 | `string`
 | `peerIP` optionally defines the remote IP address to filter flows by.
@@ -425,7 +437,18 @@ To filter two ports, use a "port1,port2" in string format. For example, `ports:
 
 | `protocol`
 | `string`
-| `protocol` optionally defines a protocol to filter flows by. The available options are `TCP`, `UDP`, `ICMP`, `ICMPv6` and `SCTP`.
+| `protocol` optionally defines a protocol to filter flows by. The available options are `TCP`, `UDP`, `ICMP`, `ICMPv6`, and `SCTP`.
+
+| `rules`
+| `array`
+| `rules` defines a list of filtering rules on the eBPF Agents.
+When filtering is enabled, by default, flows that don't match any rule are rejected.
+To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules.
+Unsupported *.
+
+| `sampling`
+| `integer`
+| `sampling` sampling rate for the matched flows, overriding the global sampling defined at `spec.agent.ebpf.sampling`.
 
 | `sourcePorts`
 | `integer-or-string`
@@ -437,7 +460,110 @@ To filter two ports, use a "port1,port2" in string format. For example, `ports:
 | `tcpFlags`
 | `string`
 | `tcpFlags` optionally defines TCP flags to filter flows by.
-In addition to the standard flags (RFC-9293), you can also filter by one of the three following combinations: `SYN-ACK`, `FIN-ACK` and `RST-ACK`.
+In addition to the standard flags (RFC-9293), you can also filter by one of the three following combinations: `SYN-ACK`, `FIN-ACK`, and `RST-ACK`.
+
+|===
+== .spec.agent.ebpf.flowFilter.rules
+Description::
++
+--
+`rules` defines a list of filtering rules on the eBPF Agents.
+When filtering is enabled, by default, flows that don't match any rule are rejected.
+To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules.
+Unsupported *.
+--
+
+Type::
+  `array`
+
+
+
+
+== .spec.agent.ebpf.flowFilter.rules[]
+Description::
++
+--
+`EBPFFlowFilterRule` defines the desired eBPF agent configuration regarding flow filtering rule.
+--
+
+Type::
+  `object`
+
+
+
+
+[cols="1,1,1",options="header"]
+|===
+| Property | Type | Description
+
+| `action`
+| `string`
+| `action` defines the action to perform on the flows that match the filter. The available options are `Accept`, which is the default, and `Reject`.
+
+| `cidr`
+| `string`
+| `cidr` defines the IP CIDR to filter flows by.
+Examples: `10.10.10.0/24` or `100:100:100:100::/64`
+
+| `destPorts`
+| `integer-or-string`
+| `destPorts` optionally defines the destination ports to filter flows by.
+To filter a single port, set a single port as an integer value. For example, `destPorts: 80`.
+To filter a range of ports, use a "start-end" range in string format. For example, `destPorts: "80-100"`.
+To filter two ports, use a "port1,port2" in string format. For example, `ports: "80,100"`.
+
+| `direction`
+| `string`
+| `direction` optionally defines a direction to filter flows by. The available options are `Ingress` and `Egress`.
+
+| `icmpCode`
+| `integer`
+| `icmpCode`, for Internet Control Message Protocol (ICMP) traffic, optionally defines the ICMP code to filter flows by.
+
+| `icmpType`
+| `integer`
+| `icmpType`, for ICMP traffic, optionally defines the ICMP type to filter flows by.
+
+| `peerCIDR`
+| `string`
+| `peerCIDR` defines the Peer IP CIDR to filter flows by.
+Examples: `10.10.10.0/24` or `100:100:100:100::/64`
+
+| `peerIP`
+| `string`
+| `peerIP` optionally defines the remote IP address to filter flows by.
+Example: `10.10.10.10`.
+
+| `pktDrops`
+| `boolean`
+| `pktDrops` optionally filters only flows containing packet drops.
+
+| `ports`
+| `integer-or-string`
+| `ports` optionally defines the ports to filter flows by. It is used both for source and destination ports.
+To filter a single port, set a single port as an integer value. For example, `ports: 80`.
+To filter a range of ports, use a "start-end" range in string format. For example, `ports: "80-100"`.
+To filter two ports, use a "port1,port2" in string format. For example, `ports: "80,100"`.
+
+| `protocol`
+| `string`
+| `protocol` optionally defines a protocol to filter flows by. The available options are `TCP`, `UDP`, `ICMP`, `ICMPv6`, and `SCTP`.
+
+| `sampling`
+| `integer`
+| `sampling` sampling rate for the matched flows, overriding the global sampling defined at `spec.agent.ebpf.sampling`.
+
+| `sourcePorts`
+| `integer-or-string`
+| `sourcePorts` optionally defines the source ports to filter flows by.
+To filter a single port, set a single port as an integer value. For example, `sourcePorts: 80`.
+To filter a range of ports, use a "start-end" range in string format. For example, `sourcePorts: "80-100"`.
+To filter two ports, use a "port1,port2" in string format. For example, `ports: "80,100"`.
+
+| `tcpFlags`
+| `string`
+| `tcpFlags` optionally defines TCP flags to filter flows by.
+In addition to the standard flags (RFC-9293), you can also filter by one of the three following combinations: `SYN-ACK`, `FIN-ACK`, and `RST-ACK`.
 
 |===
 == .spec.agent.ebpf.metrics
@@ -537,7 +663,7 @@ If set to `true`, the `providedCaFile` field is ignored.
 | Select the type of TLS configuration: +
 
 - `Disabled` (default) to not configure TLS for the endpoint.
-- `Provided` to manually provide cert file and a key file. [Unsupported (*)].
+- `Provided` to manually provide cert file and a key file. Unsupported *.
 - `Auto` to use {product-title} auto generated certificate using annotations.
 
 |===
@@ -937,7 +1063,7 @@ More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-co
 Description::
 +
 --
-`exporters` define additional optional exporters for custom consumption or storage.
+`exporters` defines additional optional exporters for custom consumption or storage.
 --
 
 Type::
@@ -979,7 +1105,7 @@ Required::
 
 | `type`
 | `string`
-| `type` selects the type of exporters. The available options are `Kafka`, `IPFIX` and `OpenTelemetry`.
+| `type` selects the type of exporters. The available options are `Kafka`, `IPFIX`, and `OpenTelemetry`.
 
 |===
 == .spec.exporters[].ipfix
@@ -1041,7 +1167,7 @@ Required::
 
 | `sasl`
 | `object`
-| SASL authentication configuration. [Unsupported (*)].
+| SASL authentication configuration. Unsupported *.
 
 | `tls`
 | `object`
@@ -1056,7 +1182,7 @@ Required::
 Description::
 +
 --
-SASL authentication configuration. [Unsupported (*)].
+SASL authentication configuration. Unsupported *.
 --
 
 Type::
@@ -1552,7 +1678,7 @@ Required::
 
 | `sasl`
 | `object`
-| SASL authentication configuration. [Unsupported (*)].
+| SASL authentication configuration. Unsupported *.
 
 | `tls`
 | `object`
@@ -1567,7 +1693,7 @@ Required::
 Description::
 +
 --
-SASL authentication configuration. [Unsupported (*)].
+SASL authentication configuration. Unsupported *.
 --
 
 Type::
@@ -1953,7 +2079,7 @@ Type::
 
 - `Forward` forwards the user token for authorization. +
 
-- `Host` [deprecated (*)] - uses the local pod service account to authenticate to Loki. +
+- `Host` [deprecated *] - uses the local pod service account to authenticate to Loki. +
 
 When using the Loki Operator, this must be set to `Forward`.
 
@@ -2539,7 +2665,7 @@ configuration, you can disable it and install your own instead.
 | `boolean`
 | Set `enable` to `true` to deploy network policies on the namespaces used by Network Observability (main and privileged). It is disabled by default.
 These network policies better isolate the Network Observability components to prevent undesired connections to them.
-We recommend you either enable it, or create your own network policy for Network Observability.
+To increase the security of connections, enable this option or create your own network policy.
 
 |===
 == .spec.processor
@@ -2575,6 +2701,18 @@ such as `GOGC` and `GOMAXPROCS` env vars. Set these values at your own risk.
 | `string`
 | `clusterName` is the name of the cluster to appear in the flows data. This is useful in a multi-cluster context. When using {product-title}, leave empty to make it automatically determined.
 
+| `deduper`
+| `object`
+| `deduper` allows you to sample or drop flows identified as duplicates, in order to save on resource usage.
+Unsupported *.
+
+| `filters`
+| `array`
+| `filters` lets you define custom filters to limit the amount of generated flows.
+These filters provide more flexibility than the eBPF Agent filters (in `spec.agent.ebpf.flowFilter`), such as allowing to filter by Kubernetes namespace,
+but with a lesser improvement in performance.
+Unsupported *.
+
 | `imagePullPolicy`
 | `string`
 | `imagePullPolicy` is the Kubernetes pull policy for the image defined above
@@ -2605,13 +2743,13 @@ This setting is ignored when Kafka is disabled.
 | `string`
 | `logTypes` defines the desired record types to generate. Possible values are: +
 
-- `Flows` (default) to export regular network flows +
+- `Flows` to export regular network flows. This is the default. +
 
-- `Conversations` to generate events for started conversations, ended conversations as well as periodic "tick" updates +
+- `Conversations` to generate events for started conversations, ended conversations as well as periodic "tick" updates. +
 
-- `EndedConversations` to generate only ended conversations events +
+- `EndedConversations` to generate only ended conversations events. +
 
-- `All` to generate both network flows and all conversations events +
+- `All` to generate both network flows and all conversations events. It is not recommended due to the impact on resources footprint. +
 
 
 | `metrics`
@@ -2667,7 +2805,7 @@ This delay is ignored when a FIN packet is collected for TCP flows (see `convers
 
 | `dropUnusedFields`
 | `boolean`
-| `dropUnusedFields` [deprecated (*)] this setting is not used anymore.
+| `dropUnusedFields` [deprecated *] this setting is not used anymore.
 
 | `enableKubeProbes`
 | `boolean`
@@ -2700,7 +2838,7 @@ By convention, some values are forbidden. It must be greater than 1024 and diffe
 
 | `secondaryNetworks`
 | `array`
-| Define secondary networks to be checked for resources identification.
+| Defines secondary networks to be checked for resources identification.
 To guarantee a correct identification, indexed values must form an unique identifier across the cluster.
 If the same index is used by several resources, those resources might be incorrectly labeled.
 
@@ -2773,9 +2911,8 @@ Type::
 Description::
 +
 --
-Define secondary networks to be checked for resources identification.
-To guarantee a correct identification, indexed values must form an unique identifier across the cluster.
-If the same index is used by several resources, those resources might be incorrectly labeled.
+Defines secondary networks to be checked for resources identification.
+To guarantee a correct identification, indexed values must form an unique identifier across the cluster. If the same index is used by several resources, those resources might be incorrectly labeled.
 --
 
 Type::
@@ -2814,6 +2951,133 @@ Fields absent from the 'k8s.v1.cni.cncf.io/network-status' annotation must not b
 | `string`
 | `name` should match the network name as visible in the pods annotation 'k8s.v1.cni.cncf.io/network-status'.
 
+|===
+== .spec.processor.deduper
+Description::
++
+--
+`deduper` allows you to sample or drop flows identified as duplicates, in order to save on resource usage.
+Unsupported *.
+--
+
+Type::
+  `object`
+
+
+
+
+[cols="1,1,1",options="header"]
+|===
+| Property | Type | Description
+
+| `mode`
+| `string`
+| Set the Processor de-duplication mode. It comes in addition to the Agent-based deduplication because the Agent cannot de-duplicate same flows reported from different nodes. +
+
+- Use `Drop` to drop every flow considered as duplicates, allowing saving more on resource usage but potentially losing some information such as the network interfaces used from peer, or network events. +
+
+- Use `Sample` to randomly keep only one flow on 50, which is the default, among the ones considered as duplicates. This is a compromise between dropping every duplicate or keeping every duplicate. This sampling action comes in addition to the Agent-based sampling. If both Agent and Processor sampling values are `50`, the combined sampling is 1:2500. +
+
+- Use `Disabled` to turn off Processor-based de-duplication. +
+
+
+| `sampling`
+| `integer`
+| `sampling` is the sampling rate when deduper `mode` is `Sample`.
+
+|===
+== .spec.processor.filters
+Description::
++
+--
+`filters` lets you define custom filters to limit the amount of generated flows.
+These filters provide more flexibility than the eBPF Agent filters (in `spec.agent.ebpf.flowFilter`), such as allowing to filter by Kubernetes namespace,
+but with a lesser improvement in performance.
+Unsupported *.
+--
+
+Type::
+  `array`
+
+
+
+
+== .spec.processor.filters[]
+Description::
++
+--
+`FLPFilterSet` defines the desired configuration for FLP-based filtering satisfying all conditions.
+--
+
+Type::
+  `object`
+
+
+
+
+[cols="1,1,1",options="header"]
+|===
+| Property | Type | Description
+
+| `allOf`
+| `array`
+| `filters` is a list of matches that must be all satisfied in order to remove a flow.
+
+| `outputTarget`
+| `string`
+| If specified, these filters only target a single output: `Loki`, `Metrics` or `Exporters`. By default, all outputs are targeted.
+
+| `sampling`
+| `integer`
+| `sampling` is an optional sampling rate to apply to this filter.
+
+|===
+== .spec.processor.filters[].allOf
+Description::
++
+--
+`filters` is a list of matches that must be all satisfied in order to remove a flow.
+--
+
+Type::
+  `array`
+
+
+
+
+== .spec.processor.filters[].allOf[]
+Description::
++
+--
+`FLPSingleFilter` defines the desired configuration for a single FLP-based filter.
+--
+
+Type::
+  `object`
+
+Required::
+  - `field`
+  - `matchType`
+
+
+
+[cols="1,1,1",options="header"]
+|===
+| Property | Type | Description
+
+| `field`
+| `string`
+| Name of the field to filter on.
+Refer to the documentation for the list of available fields: https://github.com/netobserv/network-observability-operator/blob/main/docs/flows-format.adoc.
+
+| `matchType`
+| `string`
+| Type of matching to apply.
+
+| `value`
+| `string`
+| Value to filter on. When `matchType` is `Equal` or `NotEqual`, you can use field injection with `$(SomeField)` to refer to any other field of the flow.
+
 |===
 == .spec.processor.kafkaConsumerAutoscaler
 Description::
@@ -2865,7 +3129,8 @@ Note that the more metrics you add, the bigger is the impact on Prometheus workl
 Metrics enabled by default are:
 `namespace_flows_total`, `node_ingress_bytes_total`, `node_egress_bytes_total`, `workload_ingress_bytes_total`,
 `workload_egress_bytes_total`, `namespace_drop_packets_total` (when `PacketDrop` feature is enabled),
-`namespace_rtt_seconds` (when `FlowRTT` feature is enabled), `namespace_dns_latency_seconds` (when `DNSTracking` feature is enabled).
+`namespace_rtt_seconds` (when `FlowRTT` feature is enabled), `namespace_dns_latency_seconds` (when `DNSTracking` feature is enabled),
+`namespace_network_policy_events_total` (when `NetworkEvents` feature is enabled).
 More information, with full list of available metrics: https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md
 
 | `server`
@@ -2936,7 +3201,7 @@ If set to `true`, the `providedCaFile` field is ignored.
 | Select the type of TLS configuration: +
 
 - `Disabled` (default) to not configure TLS for the endpoint.
-- `Provided` to manually provide cert file and a key file. [Unsupported (*)].
+- `Provided` to manually provide cert file and a key file. Unsupported *.
 - `Auto` to use {product-title} auto generated certificate using annotations.
 
 |===
diff --git a/modules/network-observability-flowmetric-api-specifications.adoc b/modules/network-observability-flowmetric-api-specifications.adoc
index 09e4b3b44654..c9adb00fb33c 100644
--- a/modules/network-observability-flowmetric-api-specifications.adoc
+++ b/modules/network-observability-flowmetric-api-specifications.adoc
@@ -107,6 +107,11 @@ When set to `Egress`, it is equivalent to adding the regular expression filter o
 be used to eliminate duplicates: `Duplicate != "true"` and `FlowDirection = "0"`.
 Refer to the documentation for the list of available fields: https://docs.openshift.com/container-platform/latest/observability/network_observability/json-flows-format-reference.html.
 
+| `flatten`
+| `array (string)`
+| `flatten` is a list of list-type fields that must be flattened, such as Interfaces and NetworkEvents. Flattened fields generate one metric per item in that field.
+For instance, when flattening `Interfaces` on a bytes counter, a flow having Interfaces [br-ex, ens5] increases one counter for `br-ex` and another for `ens5`.
+
 | `labels`
 | `array (string)`
 | `labels` is a list of fields that should be used as Prometheus labels, also known as dimensions.
diff --git a/modules/network-observability-flows-format.adoc b/modules/network-observability-flows-format.adoc
index ce2635f0247f..a81303aa2b6c 100644
--- a/modules/network-observability-flows-format.adoc
+++ b/modules/network-observability-flows-format.adoc
@@ -1,7 +1,7 @@
 // Automatically generated by 'hack/asciidoc-flows-gen.sh'. Do not edit, or make the NETOBSERV team aware of the editions.
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-flows-format_{context}"]
-= Network flows format reference
+= Network Flows format reference
 
 This is the specification of the network flows format. That format is used when a Kafka exporter is configured, for Prometheus metrics labels as well as internally for the Loki store.
 
@@ -9,7 +9,7 @@ The "Filter ID" column shows which related name to use when defining Quick Filte
 
 The "Loki label" column is useful when querying Loki directly: label fields need to be selected using link:https://grafana.com/docs/loki/latest/logql/log_queries/#log-stream-selector[stream selectors].
 
-The "Cardinality" column contains information about the implied metric cardinality if this field was to be used as a Prometheus label with the `FlowMetrics` API. For more information, see the `FlowMetrics` documentation for more information on using this API.
+The "Cardinality" column gives information about the implied metric cardinality if this field was to be used as a Prometheus label with the `FlowMetrics` API. Refer to the `FlowMetrics` documentation for more information on using this API.
 
 
 [cols="1,1,3,1,1,1,1",options="header"]
@@ -99,6 +99,13 @@ The "Cardinality" column contains information about the implied metric cardinali
 | yes
 | fine
 | destination.k8s.namespace.name
+| `DstK8S_NetworkName`
+| string
+| Destination network name
+| `dst_network`
+| no
+| fine
+| n/a
 | `DstK8S_OwnerName`
 | string
 | Name of the destination owner, such as Deployment name, StatefulSet name, etc.
@@ -156,14 +163,14 @@ The "Cardinality" column contains information about the implied metric cardinali
 | fine
 | n/a
 | `Flags`
-| number
-| Logical OR combination of unique TCP flags comprised in the flow, as per RFC-9293, with additional custom flags to represent the following per-packet combinations: +
-- SYN+ACK (0x100) +
-- FIN+ACK (0x200) +
-- RST+ACK (0x400)
+| string[]
+| List of TCP flags comprised in the flow, according to RFC-9293, with additional custom flags to represent the following per-packet combinations: +
+- SYN_ACK +
+- FIN_ACK +
+- RST_ACK
 | `tcp_flags`
 | no
-| fine
+| careful
 | tcp.flags
 | `FlowDirection`
 | number
@@ -190,7 +197,7 @@ The "Cardinality" column contains information about the implied metric cardinali
 | fine
 | icmp.type
 | `IfDirections`
-| number
+| number[]
 | Flow directions from the network interface observation point. Can be one of: +
 - 0: Ingress (interface incoming traffic) +
 - 1: Egress (interface outgoing traffic)
@@ -199,7 +206,7 @@ The "Cardinality" column contains information about the implied metric cardinali
 | fine
 | interface.directions
 | `Interfaces`
-| string
+| string[]
 | Network interfaces
 | `interfaces`
 | no
@@ -220,8 +227,14 @@ The "Cardinality" column contains information about the implied metric cardinali
 | fine
 | k8s.layer
 | `NetworkEvents`
-| string
-| Network events flow monitoring
+| object[]
+| Network events, such as network policy actions, composed of nested fields: +
+- Feature (such as "acl" for network policies) +
+- Type (such as an "AdminNetworkPolicy") +
+- Namespace (namespace where the event applies, if any) +
+- Name (name of the resource that triggered the event) +
+- Action (such as "allow" or "drop") +
+- Direction (Ingress or Egress)
 | `network_events`
 | no
 | avoid
@@ -229,7 +242,7 @@ The "Cardinality" column contains information about the implied metric cardinali
 | `Packets`
 | number
 | Number of packets
-| n/a
+| `pkt_drop_cause`
 | no
 | avoid
 | packets
@@ -275,6 +288,13 @@ The "Cardinality" column contains information about the implied metric cardinali
 | no
 | fine
 | protocol
+| `Sampling`
+| number
+| Sampling rate used for this flow
+| n/a
+| no
+| fine
+| n/a
 | `SrcAddr`
 | string
 | Source IP address (ipv4 or ipv6)
@@ -310,6 +330,13 @@ The "Cardinality" column contains information about the implied metric cardinali
 | yes
 | fine
 | source.k8s.namespace.name
+| `SrcK8S_NetworkName`
+| string
+| Source network name
+| `src_network`
+| no
+| fine
+| n/a
 | `SrcK8S_OwnerName`
 | string
 | Name of the source owner, such as Deployment name, StatefulSet name, etc.
@@ -387,6 +414,48 @@ The "Cardinality" column contains information about the implied metric cardinali
 | no
 | avoid
 | timereceived
+| `Udns`
+| string[]
+| List of User Defined Networks
+| `udns`
+| no
+| careful
+| n/a
+| `XlatDstAddr`
+| string
+| Packet translation destination address
+| `xlat_dst_address`
+| no
+| avoid
+| n/a
+| `XlatDstPort`
+| number
+| Packet translation destination port
+| `xlat_dst_port`
+| no
+| careful
+| n/a
+| `XlatSrcAddr`
+| string
+| Packet translation source address
+| `xlat_src_address`
+| no
+| avoid
+| n/a
+| `XlatSrcPort`
+| number
+| Packet translation source port
+| `xlat_src_port`
+| no
+| careful
+| n/a
+| `ZoneId`
+| number
+| Packet translation zone id
+| `xlat_zone_id`
+| no
+| avoid
+| n/a
 | `_HashId`
 | string
 | In conversation tracking, the conversation identifier
@@ -396,9 +465,9 @@ The "Cardinality" column contains information about the implied metric cardinali
 | n/a
 | `_RecordType`
 | string
-| Type of record: 'flowLog' for regular flow logs, or 'newConnection', 'heartbeat', 'endConnection' for conversation tracking
+| Type of record: `flowLog` for regular flow logs, or `newConnection`, `heartbeat`, `endConnection` for conversation tracking
 | `type`
 | yes
 | fine
 | n/a
-|===
\ No newline at end of file
+|=== 
\ No newline at end of file
diff --git a/modules/network-observability-metrics-names.adoc b/modules/network-observability-metrics-names.adoc
index c2555fe71632..7d49f8ee9971 100644
--- a/modules/network-observability-metrics-names.adoc
+++ b/modules/network-observability-metrics-names.adoc
@@ -50,4 +50,9 @@ When the `FlowRTT` feature is enabled in `spec.agent.ebpf.features`, the followi
 
 * `namespace_rtt_seconds` *
 * `node_rtt_seconds`
-* `workload_rtt_seconds`
\ No newline at end of file
+* `workload_rtt_seconds`
+
+Network events metrics names::
+When `NetworkEvents` feature is enabled, this metric is available by default:
+
+* `namespace_network_policy_events_total`
\ No newline at end of file
diff --git a/modules/network-observability-netobserv-cli-install.adoc b/modules/network-observability-netobserv-cli-install.adoc
index 795752e51aee..ddd46b423e51 100644
--- a/modules/network-observability-netobserv-cli-install.adoc
+++ b/modules/network-observability-netobserv-cli-install.adoc
@@ -18,24 +18,23 @@ You can optionally use Krew to install the `netobserv` CLI plugin. For more info
 
 .Procedure
 
-. Download the link:https://mirror.openshift.com/pub/cgw/netobserv/latest/[`oc netobserv` CLI tar file] that corresponds with your architecture.
-. Unpack the archive. For example, for the `amd64` archive, run the following command:
+. Download the link:https://mirror.openshift.com/pub/cgw/netobserv/latest/[`oc netobserv` file] that corresponds with your architecture. For example, for the `amd64` archive:
 +
 [source,terminal]
 ----
-$ tar xvf netobserv-cli-linux-amd64.tar.gz
+$ curl -LO https://mirror.openshift.com/pub/cgw/netobserv/latest/oc-netobserv-amd64
 ----
 . Make the file executable:
 +
 [source,terminal]
 ----
-$ chmod +x ./oc-netobserv
+$ chmod +x ./oc-netobserv-amd64
 ----
 . Move the extracted `netobserv-cli` binary to a directory that is on your `PATH`, such as `/usr/local/bin/`:
 +
 [source,terminal]
 ----
-$ sudo mv ./oc-netobserv /usr/local/bin/
+$ sudo mv ./oc-netobserv-amd64 /usr/local/bin/oc-netobserv
 ----
 
 .Verification
diff --git a/modules/network-observability-netobserv-cli-reference.adoc b/modules/network-observability-netobserv-cli-reference.adoc
index 476951c370cd..7bdc6aba8240 100644
--- a/modules/network-observability-netobserv-cli-reference.adoc
+++ b/modules/network-observability-netobserv-cli-reference.adoc
@@ -1,13 +1,14 @@
 // Automatically generated by './scripts/generate-doc.sh'. Do not edit, or make the NETOBSERV team aware of the editions.
 :_mod-docs-content-type: REFERENCE
+
 [id="network-observability-netobserv-cli-reference_{context}"]
 = Network Observability CLI usage
 
-You can use the Network Observability CLI (`oc netobserv`) to pass command line arguments to capture flow data and packet data for further analysis, enable Network Observability Operator features, or pass configuration options to the eBPF agent and `flowlogs-pipeline`.
+You can use the Network Observability CLI (`oc netobserv`) to pass command line arguments to capture flows data, packets data, and metrics for further analysis and enable features supported by the Network Observability Operator.
 
 [id="cli-syntax_{context}"]
 == Syntax 
-The basic syntax for `oc netobserv` commands is as follows: 
+The basic syntax for `oc netobserv` commands: 
 
 .`oc netobserv` syntax
 [source,terminal]
@@ -26,6 +27,14 @@ $ oc netobserv [<command>] [<feature_option>] [<command_options>] <1>
 | Capture flows information. For subcommands, see the "Flows capture options" table.
 | packets
 | Capture packets data. For subcommands, see the "Packets capture options" table.
+| metrics
+| Capture metrics data. For subcommands, see the "Metrics capture options" table.
+| follow
+| Follow collector logs when running in background.
+| stop
+| Stop collection by removing agent daemonset.
+| copy
+| Copy collector generated files locally.
 | cleanup
 | Remove the Network Observability CLI components.
 | version
@@ -46,44 +55,52 @@ $ oc netobserv flows [<feature_option>] [<command_options>]
 [cols="1,1,1",options="header"]
 |===
 | Option | Description | Default
-|--enable_pktdrop|        enable packet drop                         | false
-|--enable_dns|            enable DNS tracking                        | false
-|--enable_rtt|            enable RTT tracking                        | false
-|--enable_network_events| enable Network events monitoring           | false
-|--enable_filter|         enable flow filter                         | false
-|--log-level|             components logs                            | info
-|--max-time|              maximum capture time                       | 5m
-|--max-bytes|             maximum capture bytes                      | 50000000 = 50MB
-|--copy|                  copy the output files locally              | prompt
-|--direction|             filter direction                           | n/a
-|--cidr|                  filter CIDR                                | 0.0.0.0/0
-|--protocol|              filter protocol                            | n/a
-|--sport|                 filter source port                         | n/a
-|--dport|                 filter destination port                    | n/a
-|--port|                  filter port                                | n/a
-|--sport_range|           filter source port range                   | n/a
-|--dport_range|           filter destination port range              | n/a
-|--port_range|            filter port range                          | n/a
-|--sports|                filter on either of two source ports       | n/a
-|--dports|                filter on either of two destination ports  | n/a
-|--ports|                 filter on either of two ports              | n/a
-|--tcp_flags|             filter TCP flags                           | n/a
-|--action|                filter action                              | Accept
-|--icmp_type|             filter ICMP type                           | n/a
-|--icmp_code|             filter ICMP code                           | n/a
-|--peer_ip|               filter peer IP                             | n/a
-|--interfaces|            interfaces to monitor                      | n/a
+|--enable_all|                enable all eBPF features                   | false
+|--enable_dns|                enable DNS tracking                        | false
+|--enable_network_events|     enable network events monitoring           | false
+|--enable_pkt_translation|    enable packet translation                  | false
+|--enable_pkt_drop|           enable packet drop                         | false
+|--enable_rtt|                enable RTT tracking                        | false
+|--enable_udn_mapping|        enable User Defined Network mapping | false
+|--get-subnets|               get subnets information                   | false
+|--background|                run in background                          | false
+|--copy|                      copy the output files locally              | prompt
+|--log-level|                 components logs                            | info
+|--max-time|                  maximum capture time                       | 5m
+|--max-bytes|                 maximum capture bytes                      | 50000000 = 50MB
+|--action|                    filter action                              | Accept
+|--cidr|                      filter CIDR                                | 0.0.0.0/0
+|--direction|                 filter direction                           | –
+|--dport|                     filter destination port                    | –
+|--dport_range|               filter destination port range              | –
+|--dports|                    filter on either of two destination ports  | –
+|--drops|                     filter flows with only dropped packets     | false
+|--icmp_code|                 filter ICMP code                           | –
+|--icmp_type|                 filter ICMP type                           | –
+|--node-selector|             capture on specific nodes                  | –
+|--peer_ip|                   filter peer IP                             | –
+|--peer_cidr|                 filter peer CIDR                           | –
+|--port_range|                filter port range                          | –
+|--port|                      filter port                                | –
+|--ports|                     filter on either of two ports              | –
+|--protocol|                  filter protocol                            | –
+|--regexes|                   filter flows using regular expression      | –
+|--sport_range|               filter source port range                   | –
+|--sport|                     filter source port                         | –
+|--sports|                    filter on either of two source ports       | –
+|--tcp_flags|                 filter TCP flags                           | –
+|--interfaces|                interfaces to monitor                      | –
 |===
 
 .Example running flows capture on TCP protocol and port 49051 with PacketDrop and RTT features enabled:
 [source,terminal]
 ----
-$ oc netobserv flows --enable_pktdrop=true  --enable_rtt=true --enable_filter=true --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051
+$ oc netobserv flows --enable_pkt_drop  --enable_rtt --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051
 ----
-
 [id="cli-reference-packet-capture-options_{context}"]
 == Packets capture options
-You can filter on port and protocol for packet capture data. 
+You can filter packets capture data the as same as flows capture by using the filters.
+Certain features, such as packets drop, DNS, RTT, and network events, are only available for flows and metrics capture.
 
 .`oc netobserv packets` syntax
 [source,terminal]
@@ -93,27 +110,32 @@ $ oc netobserv packets [<option>]
 [cols="1,1,1",options="header"]
 |===
 | Option | Description | Default
-|--log-level|             components logs                            | info
-|--max-time|              maximum capture time                       | 5m
-|--max-bytes|             maximum capture bytes                      | 50000000 = 50MB
-|--copy|                  copy the output files locally              | prompt
-|--direction|             filter direction                           | n/a
-|--cidr|                  filter CIDR                                | 0.0.0.0/0
-|--protocol|              filter protocol                            | n/a
-|--sport|                 filter source port                         | n/a
-|--dport|                 filter destination port                    | n/a
-|--port|                  filter port                                | n/a
-|--sport_range|           filter source port range                   | n/a
-|--dport_range|           filter destination port range              | n/a
-|--port_range|            filter port range                          | n/a
-|--sports|                filter on either of two source ports       | n/a
-|--dports|                filter on either of two destination ports  | n/a
-|--ports|                 filter on either of two ports              | n/a
-|--tcp_flags|             filter TCP flags                           | n/a
-|--action|                filter action                              | Accept
-|--icmp_type|             filter ICMP type                           | n/a
-|--icmp_code|             filter ICMP code                           | n/a
-|--peer_ip|               filter peer IP                             | n/a
+|--background|                run in background                          | false
+|--copy|                      copy the output files locally              | prompt
+|--log-level|                 components logs                            | info
+|--max-time|                  maximum capture time                       | 5m
+|--max-bytes|                 maximum capture bytes                      | 50000000 = 50MB
+|--action|                    filter action                              | Accept
+|--cidr|                      filter CIDR                                | 0.0.0.0/0
+|--direction|                 filter direction                           | –
+|--dport|                     filter destination port                    | –
+|--dport_range|               filter destination port range              | –
+|--dports|                    filter on either of two destination ports  | –
+|--drops|                     filter flows with only dropped packets     | false
+|--icmp_code|                 filter ICMP code                           | –
+|--icmp_type|                 filter ICMP type                           | –
+|--node-selector|             capture on specific nodes                  | –
+|--peer_ip|                   filter peer IP                             | –
+|--peer_cidr|                 filter peer CIDR                           | –
+|--port_range|                filter port range                          | –
+|--port|                      filter port                                | –
+|--ports|                     filter on either of two ports              | –
+|--protocol|                  filter protocol                            | –
+|--regexes|                   filter flows using regular expression      | –
+|--sport_range|               filter source port range                   | –
+|--sport|                     filter source port                         | –
+|--sports|                    filter on either of two source ports       | –
+|--tcp_flags|                 filter TCP flags                           | –
 |===
 
 .Example running packets capture on TCP protocol and port 49051:
@@ -121,3 +143,52 @@ $ oc netobserv packets [<option>]
 ----
 $ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051
 ----
+[id="cli-reference-metrics-capture-options_{context}"]
+== Metrics capture options
+You can enable features and use filters on metrics capture, the same as flows capture. The generated graphs fill accordingly in the dashboard.
+
+.`oc netobserv metrics` syntax
+[source,terminal]
+----
+$ oc netobserv metrics [<option>]
+----
+[cols="1,1,1",options="header"]
+|===
+| Option | Description | Default
+|--enable_all|                enable all eBPF features                   | false
+|--enable_dns|                enable DNS tracking                        | false
+|--enable_network_events|     enable network events monitoring           | false
+|--enable_pkt_translation|    enable packet translation                  | false
+|--enable_pkt_drop|           enable packet drop                         | false
+|--enable_rtt|                enable RTT tracking                        | false
+|--enable_udn_mapping|        enable User Defined Network mapping | false
+|--get-subnets|               get subnets information                   | false
+|--action|                    filter action                              | Accept
+|--cidr|                      filter CIDR                                | 0.0.0.0/0
+|--direction|                 filter direction                           | –
+|--dport|                     filter destination port                    | –
+|--dport_range|               filter destination port range              | –
+|--dports|                    filter on either of two destination ports  | –
+|--drops|                     filter flows with only dropped packets     | false
+|--icmp_code|                 filter ICMP code                           | –
+|--icmp_type|                 filter ICMP type                           | –
+|--node-selector|             capture on specific nodes                  | –
+|--peer_ip|                   filter peer IP                             | –
+|--peer_cidr|                 filter peer CIDR                           | –
+|--port_range|                filter port range                          | –
+|--port|                      filter port                                | –
+|--ports|                     filter on either of two ports              | –
+|--protocol|                  filter protocol                            | –
+|--regexes|                   filter flows using regular expression      | –
+|--sport_range|               filter source port range                   | –
+|--sport|                     filter source port                         | –
+|--sports|                    filter on either of two source ports       | –
+|--tcp_flags|                 filter TCP flags                           | –
+|--interfaces|                interfaces to monitor                      | –
+|===
+
+.Example running metrics capture for TCP drops
+[source,terminal]
+----
+$ oc netobserv metrics --enable_pkt_drop --protocol=TCP 
+----
\ No newline at end of file
diff --git a/modules/network-observability-networking-events-overview.adoc b/modules/network-observability-networking-events-overview.adoc
new file mode 100644
index 000000000000..965a3e1d4187
--- /dev/null
+++ b/modules/network-observability-networking-events-overview.adoc
@@ -0,0 +1,17 @@
+// Module included in the following assemblies:
+//
+// network_observability/observing-network-traffic.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="network-observability-networking-events-overview_{context}"]
+= OVN Kubernetes networking events
+:FeatureName: OVN-Kubernetes networking events tracking
+include::snippets/technology-preview.adoc[]
+
+You use network event tracking in Network Observability to gain insight into OVN-Kubernetes events, including network policies, admin network policies, and egress firewalls. You can use the insights from tracking network events to help with the following tasks:
+
+* Network monitoring: Monitor allowed and blocked traffic, detecting whether packets are allowed or blocked based on network policies and admin network policies. 
+
+* Network security: You can track outbound traffic and see whether it adheres to egress firewall rules. Detect unauthorized outbound connections and flag outbound traffic that violates egress rules.
+
+See the _Additional resources_ in this section for more information about enabling and working with this view.
\ No newline at end of file
diff --git a/modules/network-observability-packet-translation-overview.adoc b/modules/network-observability-packet-translation-overview.adoc
new file mode 100644
index 000000000000..bbb56580420c
--- /dev/null
+++ b/modules/network-observability-packet-translation-overview.adoc
@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// network_observability/observing-network-traffic.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="network-observability-packet-translation-overview_{context}"]
+= Endpoint translation (xlat)
+You can gain visibility into the endpoints serving traffic in a consolidated view using Network Observability and extended Berkeley Packet Filter (eBPF). Typically, when traffic flows through a service, egressIP, or load balancer, the traffic flow information is abstracted as it is routed to one of the available pods. If you try to get information about the traffic, you can only view service related info, such as service IP and port, and not information about the specific pod that is serving the request. Often the information for both the service traffic and the virtual service endpoint is captured as two separate flows, which complicates troubleshooting. 
+
+To solve this, endpoint xlat can help in the following ways:
+
+- Capture the network flows at the kernel level, which has a minimal impact on performance.
+- Enrich the network flows with translated endpoint information, showing not only the service but also the specific backend pod, so you can see which pod served a request.
+
+As network packets are processed, the eBPF hook enriches flow logs with metadata about the translated endpoint that includes the following pieces of information that you can view in the *Network Traffic* page in a single row:
+
+- Source Pod IP
+- Source Port
+- Destination Pod IP
+- Destination Port
+- link:https://lwn.net/Articles/370152/#:~:text=A%20zone%20is%20simply%20a,to%20seperate%20conntrack%20defragmentation%20queues.[Conntrack Zone ID]
+
diff --git a/modules/network-observability-packet-translation.adoc b/modules/network-observability-packet-translation.adoc
new file mode 100644
index 000000000000..7a51075b7cf1
--- /dev/null
+++ b/modules/network-observability-packet-translation.adoc
@@ -0,0 +1,44 @@
+// Module included in the following assemblies:
+//
+// * network_observability/observing-network-traffic.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-packet-translation_{context}"]
+= Working with endpoint translation (xlat)
+You can use Network Observability and eBPF to enrich network flows from a Kubernetes service with translated endpoint information, gaining insight into the endpoints serving traffic.
+
+.Procedure
+. In the web console, navigate to *Operators* -> *Installed Operators*.
+. In the *Provided APIs* heading for the *NetObserv Operator*, select *Flow Collector*.
+. Select *cluster*, and then select the *YAML* tab.
+. Configure the `FlowCollector` custom resource for `PacketTranslation`, for example:
++
+[id="network-observability-flowcollector-configuring-packet-translation_{context}"]
+.Example `FlowCollector` configuration
+[source, yaml]
+----
+apiVersion: flows.netobserv.io/v1beta2
+kind: FlowCollector
+metadata:
+  name: cluster
+spec:
+  namespace: netobserv
+  agent:
+    type: eBPF
+    ebpf:
+      features:
+       - PacketTranslation   <1>
+----
+<1> You can start enriching network flows with translated packet information by listing the `PacketTranslation` parameter in the `spec.agent.ebpf.features` specification list.
+ 
+.Example filtering
+When you refresh the *Network Traffic* page you can filter for information about translated packets:
+
+. Filter the network flow data based on *Destination kind: Service*.
+. You can see the *xlat* column, which distinguishes where translated information is displayed, and the following default columns:
+
+* *Xlat Zone ID*
+* *Xlat Src Kubernetes Object* 
+* *Xlat Dst Kubernetes Object*
+
+You can manage the display of additional *xlat* columns in *Manage columns*.
diff --git a/modules/network-observability-resource-recommendations.adoc b/modules/network-observability-resource-recommendations.adoc
index e95ed3a4c9a2..a8359747ad1e 100644
--- a/modules/network-observability-resource-recommendations.adoc
+++ b/modules/network-observability-resource-recommendations.adoc
@@ -11,10 +11,14 @@ The following settings can help you manage resources and performance from the ou
 
 eBPF Sampling:: You can set the Sampling specification, `spec.agent.ebpf.sampling`, to manage resources. Smaller sampling values might consume a large amount of computational, memory and storage resources. You can mitigate this by specifying a sampling ratio value. A value of `100` means 1 flow every 100 is sampled. A value of `0` or `1` means all flows are captured. Smaller values result in an increase in returned flows and the accuracy of derived metrics. By default, eBPF sampling is set to a value of 50, so 1 flow every 50 is sampled. Note that more sampled flows also means more storage needed. Consider starting with the default values and refine empirically, in order to determine which setting your cluster can manage.
 
+eBPF features:: The more features that are enabled, the more CPU and memory are impacted. See "Observing the network traffic" for a complete list of these features.
+
+Without Loki:: You can reduce the amount of resources that Network Observability requires by not using Loki and instead relying on Prometheus. For example, when Network Observability is configured without Loki, the total savings of memory usage are in the 20-65% range and CPU utilization is lower by 10-30%, depending upon the sampling value. See "Network Observability without Loki" for more information.
+
 Restricting or excluding interfaces::  Reduce the overall observed traffic by setting the values for `spec.agent.ebpf.interfaces` and `spec.agent.ebpf.excludeInterfaces`. By default, the agent fetches all the interfaces in the system, except the ones listed in `excludeInterfaces` and `lo` (local interface). Note that the interface names might vary according to the Container Network Interface (CNI) used.
 
-The following settings can be used to fine-tune performance after the Network Observability has been running for a while:
+Performance fine-tuning:: The following settings can be used to fine-tune performance after the Network Observability has been running for a while:
 
-Resource requirements and limits:: Adapt the resource requirements and limits to the load and memory usage you expect on your cluster by using the `spec.agent.ebpf.resources` and `spec.processor.resources` specifications. The default limits of 800MB might be sufficient for most medium-sized clusters.
+* *Resource requirements and limits*: Adapt the resource requirements and limits to the load and memory usage you expect on your cluster by using the `spec.agent.ebpf.resources` and `spec.processor.resources` specifications. The default limits of 800MB might be sufficient for most medium-sized clusters.
 
-Cache max flows timeout:: Control how often flows are reported by the agents by using the eBPF agent's `spec.agent.ebpf.cacheMaxFlows` and `spec.agent.ebpf.cacheActiveTimeout` specifications. A larger value results in less traffic being generated by the agents, which correlates with a lower CPU load. However, a larger value leads to a slightly higher memory consumption, and might generate more latency in the flow collection.
\ No newline at end of file
+* *Cache max flows timeout*: Control how often flows are reported by the agents by using the eBPF agent's `spec.agent.ebpf.cacheMaxFlows` and `spec.agent.ebpf.cacheActiveTimeout` specifications. A larger value results in less traffic being generated by the agents, which correlates with a lower CPU load. However, a larger value leads to a slightly higher memory consumption, and might generate more latency in the flow collection.
\ No newline at end of file
diff --git a/modules/network-observability-resources-table.adoc b/modules/network-observability-resources-table.adoc
index 6d0e8d9f2abf..da59e0e69d5d 100644
--- a/modules/network-observability-resources-table.adoc
+++ b/modules/network-observability-resources-table.adoc
@@ -14,17 +14,17 @@ The examples outlined in the table demonstrate scenarios that are tailored to sp
 .Resource recommendations
 [options="header"]
 |===
-|                                     | Extra small (10 nodes) | Small (25 nodes)  | Medium (65 nodes) ^[2]^ | Large (120 nodes) ^[2]^
-| *Worker Node vCPU and memory*       | 4 vCPUs\| 16GiB mem ^[1]^ | 16 vCPUs\| 64GiB mem ^[1]^ | 16 vCPUs\| 64GiB mem  ^[1]^  |16 vCPUs\| 64GiB Mem ^[1]^
-| *LokiStack size*                    | `1x.extra-small`         | `1x.small`          | `1x.small`           | `1x.medium`
-| *Network Observability controller memory limit* | 400Mi (default)        | 400Mi (default)   | 400Mi (default)    | 400Mi (default)
-| *eBPF sampling rate*                | 50 (default)           | 50 (default)      | 50 (default)       | 50 (default)
-| *eBPF memory limit*                 | 800Mi (default)        | 800Mi (default)   | 800Mi (default)    | 1600Mi
-| *cacheMaxSize*                      | 50,000                 | 100,000 (default) | 100,000 (default)  | 100,000 (default)
-| *FLP memory limit*                  | 800Mi (default)        | 800Mi (default)   | 800Mi (default)    | 800Mi (default)
-| *FLP Kafka partitions*              | N/A                    | 48                | 48                 | 48
-| *Kafka consumer replicas*           | N/A                    | 6                 | 12                 | 18
-| *Kafka brokers*                     | N/A                    | 3 (default)       | 3 (default)        | 3 (default)
+|                                     | Extra small (10 nodes) | Small (25 nodes)  | Large (250 nodes) ^[2]^
+| *Worker Node vCPU and memory*       | 4 vCPUs\| 16GiB mem ^[1]^ | 16 vCPUs\| 64GiB mem  ^[1]^  |16 vCPUs\| 64GiB Mem ^[1]^
+| *LokiStack size*                    | `1x.extra-small`         | `1x.small`          | `1x.medium`
+| *Network Observability controller memory limit* | 400Mi (default)        | 400Mi (default)    | 400Mi (default)
+| *eBPF sampling rate*                | 50 (default)           | 50 (default)      | 50 (default)
+| *eBPF memory limit*                 | 800Mi (default)        | 800Mi (default)   | 1600Mi
+| *cacheMaxSize*                      | 50,000                 | 100,000 (default) | 100,000 (default)
+| *FLP memory limit*                  | 800Mi (default)        | 800Mi (default)   | 800Mi (default)
+| *FLP Kafka partitions*              | –                    | 48                | 48
+| *Kafka consumer replicas*           | –                    | 6                 | 18
+| *Kafka brokers*                     | –                    | 3 (default)       | 3 (default)
 |===
 [.small]
 --
diff --git a/modules/network-observability-total-resource-usage.adoc b/modules/network-observability-total-resource-usage.adoc
index 014f99295ec1..1dd9411ec0ca 100644
--- a/modules/network-observability-total-resource-usage.adoc
+++ b/modules/network-observability-total-resource-usage.adoc
@@ -5,13 +5,12 @@
 [id="network-observability-total-resource-usage-table_{context}"]
 = Total average memory and CPU usage
 
-The following table outlines averages of total resource usage for clusters with a sampling value of 1, 50, and 400 for 3 different tests: `Test 1`, `Test 2`, and `Test 3`. The tests differ in the following ways:
+The following table outlines averages of total resource usage for clusters with a sampling value of `1` and `50` for two different tests: `Test 1` and `Test 2`. The tests differ in the following ways:
 
-- `Test 1` takes into account the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 1` consists of 76 Namespaces, 5153 Pods, and 2305 Services.
-- `Test 2` takes into account a high ingress traffic volume.
-- `Test 3` takes into account the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent on a larger scale than `Test 1`, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 3` consists of 553 Namespaces, 6998 Pods, and 2508 Services.
+- `Test 1` takes into account high ingress traffic volume in addition to the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 1` consists of 76 Namespaces, 5153 Pods, and 2305 Services with a network traffic scale of ~350 MB/s.
+- `Test 2` takes into account high ingress traffic volume in addition to the total number of namespace, pods and services in an {product-title} cluster and represents use cases with a high number of workloads for a given cluster size. For example, `Test 2` consists of 553 Namespaces, 6998 Pods, and 2508 Services with a network traffic scale of ~950 MB/s.
 
-Since different types of cluster use cases are exemplified in the different tests, the numbers in this table cannot be linearly compared side-by-side, but instead are intended to be used as a benchmark for evaluating your personal cluster usage. The examples outlined in the table demonstrate scenarios that are tailored to specific workloads. Consider each example only as a baseline from which adjustments can be made to accommodate your workload needs.
+Since different types of cluster use cases are exemplified in the different tests, the numbers in this table do not scale linearly when compared side-by-side. Instead, they are intended to be used as a benchmark for evaluating your personal cluster usage. The examples outlined in the table demonstrate scenarios that are tailored to specific workloads. Consider each example only as a baseline from which adjustments can be made to accommodate your workload needs.
 
 [NOTE]
 ====
@@ -21,26 +20,13 @@ Metrics exported to Prometheus can impact the resource usage. Cardinality values
 .Total average resource usage
 [%autowidth, options="header"]
 |===
-| Sampling value | Parameters | Test 1 (25 nodes) | Test 2 (65 nodes) | Test 3 (120 nodes)
-.6+| *Sampling = 1* | *With Loki* 3+|
-| Total NetObserv CPU Usage | 3.24 | 3.42 | 7.30
-| Total NetObserv RSS (Memory) Usage | 14.09 GB | 22.56 GB | 36.46 GB
-| *Without Loki* 3+|
-| Total NetObserv CPU Usage | 2.40 | 2.43 | 5.59
-| Total NetObserv RSS (Memory) Usage | 6.85 GB | 10.39 GB | 13.92 GB
-.6+| *Sampling = 50* | *With Loki* 3+|
-| Total NetObserv CPU Usage | 2.04 | 2.36 | 3.31
-| Total NetObserv RSS (Memory) Usage | 8.79 GB | 19.14 GB | 21.07 GB
-| *Without Loki* 3+|
-| Total NetObserv CPU Usage | 1.55 | 1.64 | 2.70
-| Total NetObserv RSS (Memory) Usage | 6.71 GB | 10.15 GB | 14.82 GB
-.6+| *Sampling = 400* | *With Loki* 3+|
-| Total NetObserv CPU Usage | 1.71 | 1.44 | 2.36
-| Total NetObserv RSS (Memory) Usage | 8.21 GB | 16.02 GB | 17.44 GB
-| *Without Loki* 3+|
-| Total NetObserv CPU Usage | 1.31 | 1.06 | 1.83
-| Total NetObserv RSS (Memory) Usage | 7.01 GB | 10.70 GB | 13.26 GB
+| Sampling value | Resources used | Test 1 (25 nodes) | Test 2 (250 nodes)
+.2+| *Sampling = 50*
+| Total NetObserv CPU Usage | 1.35 | 5.39
+| Total NetObserv RSS (Memory) Usage | 16 GB | 63 GB
+.2+| *Sampling = 1*
+| Total NetObserv CPU Usage | 1.82 | 11.99
+| Total NetObserv RSS (Memory) Usage | 22 GB | 87 GB
 |===
 
-
-Summary: This table shows average total resource usage of Network Observability (Agents+FLP+Kafka+Loki).
\ No newline at end of file
+Summary: This table shows average total resource usage of Network Observability, which includes Agents, FLP, Kafka, and Loki with all features enabled. For details about what features are enabled, see the features covered in "Observing the network traffic", which comprises all the features that are enabled for this testing.
\ No newline at end of file
diff --git a/modules/network-observability-viewing-network-events.adoc b/modules/network-observability-viewing-network-events.adoc
new file mode 100644
index 000000000000..b8aa0df0f9db
--- /dev/null
+++ b/modules/network-observability-viewing-network-events.adoc
@@ -0,0 +1,60 @@
+// Module included in the following assemblies:
+//
+// * network_observability/observing-network-traffic.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-viewing-network-events_{context}"]
+= Viewing network events
+:FeatureName: OVN-Kubernetes networking events tracking
+include::snippets/technology-preview.adoc[]
+
+You can edit the `FlowCollector` to view information about network traffic events, such as network flows that are dropped or allowed by the following resources:
+
+* `NetworkPolicy`
+* `AdminNetworkPolicy`
+* `BaselineNetworkPolicy`
+* `EgressFirewall`
+* `UserDefinedNetwork` isolation
+* Multicast ACLs 
+
+.Prerequisites
+* You must have `OVNObservability` enabled by setting the `TechPreviewNoUpgrade` feature set in the `FeatureGate` custom resource (CR) named `cluster`. For more information, see "Enabling feature sets using the CLI" and "Checking OVN-Kubernetes network traffic with OVS sampling using the CLI". 
+* You have created at least one of the following network APIs: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinedNetwork` isolation, multicast, or `EgressFirewall`.
+
+.Procedure
+. In the web console, navigate to *Operators* -> *Installed Operators*.
+. In the *Provided APIs* heading for the *NetObserv Operator*, select *Flow Collector*.
+. Select *cluster*, and then select the *YAML* tab.
+. Configure the `FlowCollector` CR to enable viewing `NetworkEvents`, for example:
++
+[id="network-observability-flowcollector-configuring-networkevents{context}"]
+.Example `FlowCollector` configuration
+[source, yaml]
+----
+apiVersion: flows.netobserv.io/v1beta2
+kind: FlowCollector
+metadata:
+  name: cluster
+spec:
+   agent:
+    type: eBPF
+    ebpf:
+  #   sampling: 1       <1>
+      privileged: true  <2>
+      features:
+       - "NetworkEvents"
+----
+<1> Optional: The `sampling` parameter is set to a value of 1 so that all network events are captured. If sampling `1` is too resource heavy, set sampling to something more appropriate for your needs. 
+<2> The `privileged` parameter is set to `true` because the `OVN observability` library needs to access local Open vSwitch (OVS) socket and OpenShift Virtual Network (OVN) databases.
+
+.Verification
+. Navigate to the *Network Traffic* view and select the *Traffic flows* table. 
+. You should see the new column, *Network Events*, where you can view information about impacts of one of the following network APIs you have enabled: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinedNetwork` isolation, multicast, or egress firewalls. 
+
+An example of the kind of events you could see in this column is as follows:
++
+.Example of Network Events output
+[source,text]
+----
+<Dropped_or_Allowed> by <network_event_and_event_name>, direction <Ingress_or_Egress>
+----
diff --git a/modules/node-tuning-hosted-cluster.adoc b/modules/node-tuning-hosted-cluster.adoc
index 6dae7b1ef625..bf05a058049d 100644
--- a/modules/node-tuning-hosted-cluster.adoc
+++ b/modules/node-tuning-hosted-cluster.adoc
@@ -85,7 +85,8 @@ Now that you have created the `ConfigMap` object that contains a `Tuned` manifes
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator
+$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \
+  -n openshift-cluster-node-tuning-operator
 ----
 +
 .Example output
@@ -101,7 +102,8 @@ tuned-1    65s
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
+$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \
+  -n openshift-cluster-node-tuning-operator
 ----
 +
 .Example output
@@ -121,7 +123,8 @@ If no custom profiles are created, the `openshift-node` profile is applied by de
 +
 [source,terminal]
 ----
-$ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
+$ oc --kubeconfig="$HC_KUBECONFIG" \
+  debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
 ----
 +
 .Example output
diff --git a/modules/nodes-cluster-enabling-features-about.adoc b/modules/nodes-cluster-enabling-features-about.adoc
index 607679bfeeca..c702ee9a5a99 100644
--- a/modules/nodes-cluster-enabling-features-about.adoc
+++ b/modules/nodes-cluster-enabling-features-about.adoc
@@ -21,7 +21,6 @@ The following Technology Preview features are enabled by this feature set:
 +
 --
 ** External cloud providers. Enables support for external cloud providers for clusters on vSphere, AWS, Azure, and GCP. Support for OpenStack is GA. This is an internal feature that most users do not need to interact with. (`ExternalCloudProvider`)
-** Shared Resources CSI Driver in OpenShift Builds. Enables the Container Storage Interface (CSI). (`CSIDriverSharedResource`)
 ** Swap memory on nodes. Enables swap memory use for {product-title} workloads on a per-node basis. (`NodeSwap`)
 ** OpenStack Machine API Provider. This gate has no effect and is planned to be removed from this feature set in a future release. (`MachineAPIProviderOpenStack`)
 ** Insights Operator. Enables the `InsightsDataGather` CRD, which allows users to configure some Insights data gathering options. The feature set also enables the `DataGather` CRD, which allows users to run Insights data gathering on-demand. (`InsightsConfigAPI`)
@@ -29,6 +28,7 @@ The following Technology Preview features are enabled by this feature set:
 ** Dynamic Resource Allocation API. Enables a new API for requesting and sharing resources between pods and containers. This is an internal feature that most users do not need to interact with. (`DynamicResourceAllocation`)
 ** Pod security admission enforcement. Enables the restricted enforcement mode for pod security admission. Instead of only logging a warning, pods are rejected if they violate pod security standards. (`OpenShiftPodSecurityAdmission`)
 ** StatefulSet pod availability upgrading limits. Enables users to define the maximum number of statefulset pods unavailable during updates which reduces application downtime. (`MaxUnavailableStatefulSet`)
+** Image mode behavior of image streams. Enables a new API for controlling the import mode behavior of image streams. (`imageStreamImportMode`)
 ** `OVNObservability` resource allows you to verify expected network behavior. Supports the following network APIs: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinesdNetwork` isolation, multicast ACLs, and egress firewalls. When enabled, you can view network events in the terminal.
 ** `gcpLabelsTags`
 ** `vSphereStaticIPs`
@@ -65,38 +65,79 @@ The following Technology Preview features are enabled by this feature set:
 ** `InsightsOnDemandDataGather`
 ** `MetricsCollectionProfiles`
 ** `NewOLM`
-** `NodeDisruptionPolicy`
-** `PinnedImages`
-** `PlatformOperators`
-** `ServiceAccountTokenNodeBinding`
-** `TranslateStreamCloseWebsocketRequests`
-** `UpgradeStatus`
-** `VSphereMultiVCenters`
-** `VolumeGroupSnapshot`
+** `AWSClusterHostedDNS`
 ** `AdditionalRoutingCapabilities`
+** `AutomatedEtcdBackup`
 ** `BootcNodeManagement`
+** `CSIDriverSharedResource`
 ** `ClusterMonitoringConfig`
+** `ConsolePluginContentSecurityPolicy`
 ** `DNSNameResolver`
-** `ManagedBootImagesAWS`
+** `DynamicResourceAllocation`
+** `EtcdBackendQuota`
+** `Example`
+** `GCPClusterHostedDNS`
+** `ImageStreamImportMode`
+** `IngressControllerDynamicConfigurationManager`
+** `InsightsConfig`
+** `InsightsConfigAPI`
+** `InsightsOnDemandDataGather`
+** `InsightsRuntimeExtractor`
+** `MachineAPIProviderOpenStack`
+** `MachineConfigNodes`
+** `MaxUnavailableStatefulSet`
+** `MetricsCollectionProfiles`
+** `MinimumKubeletVersion`
+** `MixedCPUsAllocation`
 ** `NetworkSegmentation`
+** `NodeSwap`
+** `NutanixMultiSubnets`
+** `OVNObservability`
+** `OnClusterBuild`
+** `OpenShiftPodSecurityAdmission`
 ** `PersistentIPsForVirtualization`
+** `PinnedImages`
+** `PlatformOperators`
 ** `ProcMountType`
 ** `RouteAdvertisements`
+** `RouteExternalCertificate`
+** `ServiceAccountTokenNodeBinding`
+** `SignatureStores`
+** `SigstoreImageVerification`
+** `TranslateStreamCloseWebsocketRequests`
+** `UpgradeStatus`
+** `UserNamespacesPodSecurityStandards`
 ** `UserNamespacesSupport`
+** `VSphereMultiNetworks`
+** `VolumeAttributesClass`
+** `VolumeGroupSnapshot`
+** `ExternalOIDC`
 ** `AWSEFSDriverVolumeMetrics`
+** `AdminNetworkPolicy`
 ** `AlibabaPlatform`
 ** `AzureWorkloadIdentity`
+** `BareMetalLoadBalancer`
 ** `BuildCSIVolumes`
+** `ChunkSizeMiB`
 ** `CloudDualStackNodeIPs`
-** `ExternalCloudProviderAzure`
-** `ExternalCloudProviderExternal`
-** `ExternalCloudProviderGCP`
+** `DisableKubeletCloudCredentialProviders`
+** `GCPLabelsTags`
+** `HardwareSpeed`
 ** `IngressControllerLBSubnetsAWS`
+** `KMSv1`
+** `ManagedBootImages`
+** `ManagedBootImagesAWS`
 ** `MultiArchInstallAWS`
 ** `MultiArchInstallGCP`
+** `NetworkDiagnosticsConfig`
 ** `NetworkLiveMigration`
+** `NodeDisruptionPolicy`
 ** `PrivateHostedZoneAWS`
 ** `SetEIPForNLBIngressController`
+** `VSphereControlPlaneMachineSet`
+** `VSphereDriverConfiguration`
+** `VSphereMultiVCenters`
+** `VSphereStaticIPs`
 ** `ValidatingAdmissionPolicy`
 --
 
diff --git a/modules/nodes-cluster-overcommit-resource-requests.adoc b/modules/nodes-cluster-overcommit-resource-requests.adoc
index 13269625505c..e31b7f6a5bdd 100644
--- a/modules/nodes-cluster-overcommit-resource-requests.adoc
+++ b/modules/nodes-cluster-overcommit-resource-requests.adoc
@@ -24,4 +24,4 @@ to resource limits, which can be set higher than requested resources. The
 difference between request and limit determines the level of overcommit;
 for instance, if a container is given a memory request of 1Gi and a memory limit
 of 2Gi, it is scheduled based on the 1Gi request being available on the node,
-but could use up to 2Gi; so it is 200% overcommitted.
+but could use up to 2Gi; so it is 100% overcommitted.
diff --git a/modules/nodes-cluster-resource-override-deploy-cli.adoc b/modules/nodes-cluster-resource-override-deploy-cli.adoc
index 6170bd8bedf7..7fce3dfaf209 100644
--- a/modules/nodes-cluster-resource-override-deploy-cli.adoc
+++ b/modules/nodes-cluster-resource-override-deploy-cli.adoc
@@ -89,7 +89,7 @@ metadata:
   name: clusterresourceoverride
   namespace: clusterresourceoverride-operator
 spec:
-  channel: "{product-version}"
+  channel: "stable"
   name: clusterresourceoverride
   source: redhat-operators
   sourceNamespace: openshift-marketplace
diff --git a/modules/nodes-cluster-resource-override.adoc b/modules/nodes-cluster-resource-override.adoc
index 85840f218b70..8beb4924160e 100644
--- a/modules/nodes-cluster-resource-override.adoc
+++ b/modules/nodes-cluster-resource-override.adoc
@@ -3,13 +3,19 @@
 // * nodes/clusters/nodes-cluster-overcommit.adoc
 // * post_installation_configuration/node-tasks.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="nodes-cluster-resource-override_{context}"]
 = Cluster-level overcommit using the Cluster Resource Override Operator
 
 The Cluster Resource Override Operator is an admission webhook that allows you to control the level of overcommit and manage
 container density across all the nodes in your cluster. The Operator controls how nodes in specific projects can exceed defined memory and CPU limits.
 
-You must install the Cluster Resource Override Operator using the {product-title} console or CLI as shown in the following sections.
+// Paragraph taken from 3.11 docs and modified. 
+// https://docs.openshift.com/container-platform/3.11/admin_guide/overcommit.html#configuring-masters-for-overcommitment
+The Operator modifies the ratio between the requests and limits that are set on developer containers. In conjunction with a per-project limit range that specifies limits and defaults, you can achieve the desired level of overcommit.
+
+You must install the Cluster Resource Override Operator by using the {product-title} console or CLI as shown in the following sections. After you deploy the Cluster Resource Override Operator, the Operator modifies all new pods in specific namespaces. The Operator does not edit pods that existed before you deployed the Operator. 
+
 During the installation, you create a `ClusterResourceOverride` custom resource (CR), where you set the level of overcommit, as shown in the
 following example:
 
@@ -39,8 +45,7 @@ been set on containers. Create a `LimitRange` object with default limits per ind
 or configure limits in `Pod` specs for the overrides to apply.
 ====
 
-When configured, overrides can be enabled per-project by applying the following
-label to the Namespace object for each project:
+When configured, you can enable overrides on a per-project basis by applying the following label to the `Namespace` object for each project where you want the overrides to apply. For example, you can configure override so that infrastructure components are not subject to the overrides.
 
 [source,yaml]
 ----
@@ -57,3 +62,53 @@ metadata:
 ----
 
 The Operator watches for the `ClusterResourceOverride` CR and ensures that the `ClusterResourceOverride` admission webhook is installed into the same namespace as the operator.
+
+// Examples take from: https://github.com/openshift/cluster-resource-override-admission-operator?tab=readme-ov-file#test-pod-resource-override
+For example, a pod has the following resources limits:
+
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-pod
+  namespace: my-namespace
+# ...
+spec:
+  containers:
+    - name: hello-openshift
+      image: openshift/hello-openshift
+      resources:
+        limits:
+          memory: "512Mi"
+          cpu: "2000m"
+# ...
+----
+
+The Cluster Resource Override Operator intercepts the original pod request, then overrides the resources according to the configuration set in the `ClusterResourceOverride` object.
+
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-pod
+  namespace: my-namespace
+# ...
+spec:
+  containers:
+  - image: openshift/hello-openshift
+    name: hello-openshift
+    resources:
+      limits:
+        cpu: "1" <1>
+        memory: 512Mi
+      requests:
+        cpu: 250m <2>
+        memory: 256Mi
+# ...
+----
+<1> The CPU limit has been overridden to `1` because the `limitCPUToMemoryPercent` parameter is set to `200` in the `ClusterResourceOverride` object. As such, 200% of the memory limit, 512Mi in CPU terms, is 1 CPU core. 
+<2> The CPU request is now `250m` because the `cpuRequestToLimit` is set to `25` in the `ClusterResourceOverride` object. As such, 25% of the 1 CPU core is 250m.
+
+
diff --git a/modules/nodes-clusters-cgroups-2.adoc b/modules/nodes-clusters-cgroups-2.adoc
index fc50729bce66..90ef2c8c81c9 100644
--- a/modules/nodes-clusters-cgroups-2.adoc
+++ b/modules/nodes-clusters-cgroups-2.adoc
@@ -59,7 +59,7 @@ ifdef::post[]
 .Example `node.config` object
 [source,yaml]
 ----
-apiVersion: config.openshift.io/v2
+apiVersion: config.openshift.io/v1
 kind: Node
 metadata:
   annotations:
@@ -71,7 +71,7 @@ metadata:
   generation: 1
   name: cluster
   ownerReferences:
-  - apiVersion: config.openshift.io/v2
+  - apiVersion: config.openshift.io/v1
     kind: ClusterVersion
     name: version
     uid: 36282574-bf9f-409e-a6cd-3032939293eb
@@ -90,7 +90,7 @@ ifdef::nodes[]
 .Example `node.config` object
 [source,yaml]
 ----
-apiVersion: config.openshift.io/v2
+apiVersion: config.openshift.io/v1
 kind: Node
 metadata:
   annotations:
@@ -102,7 +102,7 @@ metadata:
   generation: 1
   name: cluster
   ownerReferences:
-  - apiVersion: config.openshift.io/v2
+  - apiVersion: config.openshift.io/v1
     kind: ClusterVersion
     name: version
     uid: 36282574-bf9f-409e-a6cd-3032939293eb
@@ -158,7 +158,7 @@ ifdef::nodes[]
 .Example output for cgroup v2
 [source,terminal]
 ----
-apiVersion: machineconfiguration.openshift.io/v2
+apiVersion: machineconfiguration.openshift.io/v1
 kind: MachineConfig
 metadata:
   labels:
@@ -168,17 +168,16 @@ spec:
   kernelArguments:
     systemd_unified_cgroup_hierarchy=1 <1>
     cgroup_no_v1="all" <2>
-    psi=1 <3>
+    psi=0
 ----
 <1> Enables cgroup v2 in systemd.
 <2> Disables cgroup v1.
-<3> Enables the Linux Pressure Stall Information (PSI) feature.
 +
 endif::nodes[]
 .Example output for cgroup v1
 [source,terminal]
 ----
-apiVersion: machineconfiguration.openshift.io/v2
+apiVersion: machineconfiguration.openshift.io/v1
 kind: MachineConfig
 metadata:
   labels:
@@ -188,9 +187,11 @@ spec:
   kernelArguments:
     systemd.unified_cgroup_hierarchy=0 <1>
     systemd.legacy_systemd_cgroup_controller=1 <2>
+    psi=1 <3>
 ----
 <1> Disables cgroup v2.
 <2> Enables cgroup v1 in systemd.
+<3> Enables the Linux Pressure Stall Information (PSI) feature.
 
 . Check the nodes to see that scheduling on the nodes is disabled. This indicates that the change is being applied:
 +
diff --git a/modules/nodes-cma-autoscaling-custom-install.adoc b/modules/nodes-cma-autoscaling-custom-install.adoc
index 9fbe69221df8..d8d0c9e020e8 100644
--- a/modules/nodes-cma-autoscaling-custom-install.adoc
+++ b/modules/nodes-cma-autoscaling-custom-install.adoc
@@ -126,7 +126,7 @@ spec:
 <2> Specifies the level of verbosity for the Custom Metrics Autoscaler Operator log messages. The allowed values are `debug`, `info`, `error`. The default is `info`.
 <3> Specifies the logging format for the Custom Metrics Autoscaler Operator log messages. The allowed values are `console` or `json`. The default is `console`.
 <4> Optional: Specifies one or more config maps with CA certificates, which the Custom Metrics Autoscaler Operator can use to connect securely to TLS-enabled metrics sources.
-<5> Specifies the logging level for the Custom Metrics Autoscaler Metrics Server. The allowed values are `0` for `info` and `4` or `debug`. The default is `0`.
+<5> Specifies the logging level for the Custom Metrics Autoscaler Metrics Server. The allowed values are `0` for `info` and `4` for `debug`. The default is `0`.
 <6> Activates audit logging for the Custom Metrics Autoscaler Operator and specifies the audit policy to use, as described in the "Configuring audit logging" section.
 
 .. Click *Create* to create the KEDA controller.
diff --git a/modules/nodes-cma-autoscaling-custom-prometheus-config.adoc b/modules/nodes-cma-autoscaling-custom-prometheus-config.adoc
index 1bb0ca80d207..6f8273794994 100644
--- a/modules/nodes-cma-autoscaling-custom-prometheus-config.adoc
+++ b/modules/nodes-cma-autoscaling-custom-prometheus-config.adoc
@@ -8,6 +8,8 @@
 
 You can use the installed {product-title} Prometheus monitoring as a source for the metrics used by the custom metrics autoscaler. However, there are some additional configurations you must perform.
 
+For your scaled objects to be able to read the {product-title} Prometheus metrics, you must use a trigger authentication or a cluster trigger authentication in order to provide the authentication information required. The following procedure differs depending on which trigger authentication method you use. For more information on trigger authentications, see "Understanding custom metrics autoscaler trigger authentications". 
+
 [NOTE]
 ====
 These steps are not required for an external Prometheus source.
@@ -32,12 +34,16 @@ You must perform the following tasks, as described in this section:
 
 .Procedure
 
-. Change to the project with the object you want to scale:
+. Change to the appropriate project:
 +
 [source,terminal]
 ----
-$ oc project my-project
+$ oc project <project_name> <1>
 ----
+<1> Specifies one of the following projects:
++
+*  If you are using a trigger authentication, specify the project with the object you want to scale.
+*  If you are using a cluster trigger authentication, specify the `openshift-keda` project.
 
 . Create a service account and token, if your cluster does not have one:
 
@@ -47,7 +53,6 @@ $ oc project my-project
 ----
 $ oc create serviceaccount thanos <1>
 ----
-+
 <1> Specifies the name of the service account.
 
 .. Create a `secret` YAML to generate a service account token:
@@ -62,7 +67,6 @@ metadata:
     kubernetes.io/service-account.name: thanos <1>
 type: kubernetes.io/service-account-token
 ----
-+
 <1> Specifies the name of the service account.
 
 .. Create the secret object by using the following command:
@@ -86,7 +90,7 @@ $ oc describe serviceaccount thanos <1>
 [source,terminal]
 ----
 Name:                thanos
-Namespace:           my-project
+Namespace:           <namespace_name>
 Labels:              <none>
 Annotations:         <none>
 Image pull secrets:  thanos-dockercfg-nnwgj
@@ -105,22 +109,27 @@ Events:              <none>
 [source,yaml]
 ----
 apiVersion: keda.sh/v1alpha1
-kind: TriggerAuthentication
+kind: <authentication_method> <1>
 metadata:
   name: keda-trigger-auth-prometheus
 spec:
-  secretTargetRef: <1>
-  - parameter: bearerToken <2>
-    name: thanos-token <3>
-    key: token <4>
+  secretTargetRef: <2>
+  - parameter: bearerToken <3>
+    name: thanos-token <4>
+    key: token <5>
   - parameter: ca
     name: thanos-token
     key: ca.crt
 ----
-<1> Specifies that this object uses a secret for authorization.
-<2> Specifies the authentication parameter to supply by using the token.
-<3> Specifies the name of the token to use.
-<4> Specifies the key in the token to use with the specified parameter.
+<1> Specifies one of the following trigger authentication methods:
++
+*  If you are using a trigger authentication, specify `TriggerAuthentication`. This example configures a trigger authentication.
+*  If you are using a cluster trigger authentication, specify `ClusterTriggerAuthentication`.
++
+<2> Specifies that this object uses a secret for authorization.
+<3> Specifies the authentication parameter to supply by using the token.
+<4> Specifies the name of the token to use.
+<5> Specifies the key in the token to use with the specified parameter.
 
 .. Create the CR object:
 +
@@ -171,23 +180,32 @@ $ oc create -f <file-name>.yaml
 [source,yaml]
 ----
 apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
+kind: <binding_type> <1>
 metadata:
-  name: thanos-metrics-reader <1>
-  namespace: my-project <2>
+  name: thanos-metrics-reader <2>
+  namespace: my-project <3>
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: thanos-metrics-reader
 subjects:
 - kind: ServiceAccount
-  name: thanos <3>
-  namespace: my-project <4>
+  name: thanos <4>
+  namespace: <namespace_name> <5>
 ----
-<1> Specifies the name of the role you created.
-<2> Specifies the namespace of the object you want to scale.
-<3> Specifies the name of the service account to bind to the role.
-<4> Specifies the namespace of the object you want to scale.
+<1> Specifies one of the following object types:
++
+*  If you are using a trigger authentication, specify `RoleBinding`.
+*  If you are using a cluster trigger authentication, specify `ClusterRoleBinding`.
++
+<2> Specifies the name of the role you created.
+<3> Specifies one of the following projects:
++
+*  If you are using a trigger authentication, specify the project with the object you want to scale.
+*  If you are using a cluster trigger authentication, specify the `openshift-keda` project.
++
+<4> Specifies the name of the service account to bind to the role.
+<5> Specifies the project where you previously created the service account.
 
 .. Create the CR object:
 +
diff --git a/modules/nodes-nodes-garbage-collection-configuring.adoc b/modules/nodes-nodes-garbage-collection-configuring.adoc
index 3d2093bdd36b..c43b39fa0920 100644
--- a/modules/nodes-nodes-garbage-collection-configuring.adoc
+++ b/modules/nodes-nodes-garbage-collection-configuring.adoc
@@ -102,7 +102,7 @@ spec:
       nodefs.inodesFree: "4%"
       imagefs.available: "10%"
       imagefs.inodesFree: "5%"
-    evictionPressureTransitionPeriod: 0s <7>
+    evictionPressureTransitionPeriod: 3m <7>
     imageMinimumGCAge: 5m <8>
     imageGCHighThresholdPercent: 80 <9>
     imageGCLowThresholdPercent: 75 <10>
@@ -115,10 +115,10 @@ spec:
 <5> For container garbage collection: Grace periods for the soft eviction. This parameter does not apply to `eviction-hard`.
 <6> For container garbage collection: Eviction thresholds based on a specific eviction trigger signal.
 For `evictionHard` you must specify all of these parameters.  If you do not specify all parameters, only the specified parameters are applied and the garbage collection will not function properly.
-<7> For container garbage collection: The duration to wait before transitioning out of an eviction pressure condition.
+<7> For container garbage collection: The duration to wait before transitioning out of an eviction pressure condition. Setting the `evictionPressureTransitionPeriod` parameter to `0` configures the default value of 5 minutes.
 <8> For image garbage collection: The minimum age for an unused image before the image is removed by garbage collection.
-<9> For image garbage collection: The percent of disk usage (expressed as an integer) that triggers image garbage collection.
-<10> For image garbage collection: The percent of disk usage (expressed as an integer) that image garbage collection attempts to free.
+<9> For image garbage collection: Image garbage collection is triggered at the specified percent of disk usage (expressed as an integer). This value must be greater than the `imageGCLowThresholdPercent` value.
+<10> For image garbage collection: Image garbage collection attempts to free resources to the specified percent of disk usage (expressed as an integer). This value must be less than the `imageGCHighThresholdPercent` value.
 
 . Run the following command to create the CR:
 +
diff --git a/modules/nodes-nodes-garbage-collection-containers.adoc b/modules/nodes-nodes-garbage-collection-containers.adoc
index 57eb24fa1160..39bf9803e221 100644
--- a/modules/nodes-nodes-garbage-collection-containers.adoc
+++ b/modules/nodes-nodes-garbage-collection-containers.adoc
@@ -41,4 +41,9 @@ For `evictionHard` you must specify all of these parameters.  If you do not spec
 
 If a node is oscillating above and below a soft eviction threshold, but not exceeding its associated grace period, the corresponding node would constantly oscillate between `true` and `false`. As a consequence, the scheduler could make poor scheduling decisions.
 
-To protect against this oscillation, use the `eviction-pressure-transition-period` flag to control how long {product-title} must wait before transitioning out of a pressure condition. {product-title} will not set an eviction threshold as being met for the specified pressure condition for the period specified before toggling the condition back to false.
+To protect against this oscillation, use the `evictionpressure-transition-period` flag to control how long {product-title} must wait before transitioning out of a pressure condition. {product-title} will not set an eviction threshold as being met for the specified pressure condition for the period specified before toggling the condition back to false.
+
+[NOTE]
+====
+Setting the `evictionPressureTransitionPeriod` parameter to `0` configures the default value of 5 minutes. You cannot set an eviction pressure transition period to zero seconds. 
+====
diff --git a/modules/nodes-nodes-garbage-collection-images.adoc b/modules/nodes-nodes-garbage-collection-images.adoc
index b526de2a2fe6..c1dce0e7d03e 100644
--- a/modules/nodes-nodes-garbage-collection-images.adoc
+++ b/modules/nodes-nodes-garbage-collection-images.adoc
@@ -34,11 +34,11 @@ a custom resource.
 
 |`imageGCHighThresholdPercent`
 |The percent of disk usage, expressed as an integer, which triggers image
-garbage collection. The default is *85*.
+garbage collection. The default is *85*. This value must be greater than the `imageGCLowThresholdPercent` value.
 
 |`imageGCLowThresholdPercent`
 |The percent of disk usage, expressed as an integer, to which image garbage
-collection attempts to free. The default is *80*.
+collection attempts to free. The default is *80*. This value must be less than the `imageGCHighThresholdPercent` value.
 |===
 
 Two lists of images are retrieved in each garbage collector run:
diff --git a/modules/nodes-nodes-kernel-arguments.adoc b/modules/nodes-nodes-kernel-arguments.adoc
index 3fa93c85f2e6..0596fb36b862 100644
--- a/modules/nodes-nodes-kernel-arguments.adoc
+++ b/modules/nodes-nodes-kernel-arguments.adoc
@@ -74,18 +74,18 @@ $ oc get MachineConfig
 [source,terminal]
 ----
 NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
-00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 99-master-ssh                                                                                 3.2.0             40m
-99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 99-worker-ssh                                                                                 3.2.0             40m
-rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 ----
 
 ifndef::openshift-origin[]
@@ -129,7 +129,7 @@ metadata:
 spec:
   config:
     ignition:
-      version: 3.2.0
+      version: 3.4.0
   kernelArguments:
     - enforcing=0 <3>
       systemd.unified_cgroup_hierarchy=0 <4>
@@ -161,19 +161,19 @@ $ oc get MachineConfig
 [source,terminal]
 ----
 NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
-00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
-99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+05-worker-kernelarg-selinuxpermissive                                                         3.4.0             105s
+99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 99-master-ssh                                                                                 3.2.0             40m
-99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 99-worker-ssh                                                                                 3.2.0             40m
-rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 ----
 
 . Check the nodes:
diff --git a/modules/nodes-nodes-viewing-listing-pods.adoc b/modules/nodes-nodes-viewing-listing-pods.adoc
index 980f6b4837c1..f08fb29381c4 100644
--- a/modules/nodes-nodes-viewing-listing-pods.adoc
+++ b/modules/nodes-nodes-viewing-listing-pods.adoc
@@ -10,42 +10,28 @@ You can list all the pods on a specific node.
 
 .Procedure
 
-* To list all or selected pods on one or more nodes:
-+
-[source,terminal]
-----
-$ oc describe node <node1> <node2>
-----
-+
-For example:
-+
-[source,terminal]
-----
-$ oc describe node ip-10-0-128-218.ec2.internal
-----
-
 * To list all or selected pods on selected nodes:
 +
 [source,terminal]
 ----
-$ oc describe node --selector=<node_selector>
+$ oc get pod --selector=<nodeSelector>
 ----
 +
 [source,terminal]
 ----
-$ oc describe node --selector=kubernetes.io/os
+$ oc get pod --selector=kubernetes.io/os
 ----
 +
 Or:
 +
 [source,terminal]
 ----
-$ oc describe node -l=<pod_selector>
+$ oc get pod -l=<nodeSelector>
 ----
 +
 [source,terminal]
 ----
-$ oc describe node -l node-role.kubernetes.io/worker
+$ oc get pod -l kubernetes.io/os=linux
 ----
 
 * To list all pods on a specific node, including terminated pods:
diff --git a/modules/nodes-nodes-viewing-listing.adoc b/modules/nodes-nodes-viewing-listing.adoc
index 6ab2d3764a5c..d4cb71e6ffd1 100644
--- a/modules/nodes-nodes-viewing-listing.adoc
+++ b/modules/nodes-nodes-viewing-listing.adoc
@@ -101,9 +101,10 @@ For example:
 $ oc describe node node1.example.com
 ----
 +
-
+--
 include::snippets/osd-aws-example-only.adoc[]
-
+--
++
 .Example output
 [source,text]
 ----
@@ -210,14 +211,12 @@ Events:     <11>
 <9> Information about the node host.
 <10> The pods on the node.
 <11> The events reported by the node.
-
++
 ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
-
 [NOTE]
 ====
 The control plane label is not automatically added to newly created or updated master nodes. If you want to use the control plane label for your nodes, you can manually configure the label. For more information, see _Understanding how to update labels on nodes_ in the _Additional resources_ section.
 ====
-
 endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 Among the information shown for nodes, the following node conditions appear in the output of the commands shown in this section:
diff --git a/modules/nodes-nodes-working-updating.adoc b/modules/nodes-nodes-working-updating.adoc
index d574c8997a92..45886e8c5c04 100644
--- a/modules/nodes-nodes-working-updating.adoc
+++ b/modules/nodes-nodes-working-updating.adoc
@@ -60,3 +60,10 @@ For example:
 ----
 $ oc label pods --all status=unhealthy
 ----
+
+[IMPORTANT]
+====
+In {product-title} 4.12 and later, newly installed clusters include both the `node-role.kubernetes.io/control-plane` and `node-role.kubernetes.io/master` labels on control plane nodes by default.
+
+In {product-title} versions earlier than 4.12, the `node-role.kubernetes.io/control-plane` label is not added by default. Therefore, you must manually add the `node-role.kubernetes.io/control-plane` label to control plane nodes in clusters upgraded from earlier versions.
+====
\ No newline at end of file
diff --git a/modules/nodes-pods-autoscaling-about.adoc b/modules/nodes-pods-autoscaling-about.adoc
index 7ebcdb319f8d..64e561830c81 100644
--- a/modules/nodes-pods-autoscaling-about.adoc
+++ b/modules/nodes-pods-autoscaling-about.adoc
@@ -66,26 +66,26 @@ and ensure that your application meets these requirements before using
 memory-based autoscaling.
 ====
 
-The following example shows autoscaling for the `image-registry` `Deployment` object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods increase to 7:
+The following example shows autoscaling for the `hello-node` `Deployment` object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods increase to 7:
 
 [source,terminal]
 ----
-$ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75
+$ oc autoscale deployment/hello-node --min=5 --max=7 --cpu-percent=75
 ----
 
 .Example output
 [source,terminal]
 ----
-horizontalpodautoscaler.autoscaling/image-registry autoscaled
+horizontalpodautoscaler.autoscaling/hello-node autoscaled
 ----
 
-.Sample HPA for the `image-registry` `Deployment` object with `minReplicas` set to 3
+.Sample YAML to create an HPA for the `hello-node` deployment object with `minReplicas` set to 3
 [source,yaml]
 ----
 apiVersion: autoscaling/v1
 kind: HorizontalPodAutoscaler
 metadata:
-  name: image-registry
+  name: hello-node
   namespace: default
 spec:
   maxReplicas: 7
@@ -93,25 +93,25 @@ spec:
   scaleTargetRef:
     apiVersion: apps/v1
     kind: Deployment
-    name: image-registry
+    name: hello-node
   targetCPUUtilizationPercentage: 75
 status:
   currentReplicas: 5
   desiredReplicas: 0
 ----
 
-. View the new state of the deployment:
-+
+After you create the HPA, you can view the new state of the deployment by running the following command:
+
 [source,terminal]
 ----
-$ oc get deployment image-registry
+$ oc get deployment hello-node
 ----
-+
+
 There are now 5 pods in the deployment:
-+
+
 .Example output
 [source,terminal]
 ----
-NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
-image-registry   1          5         5         config
+NAME         REVISION   DESIRED   CURRENT   TRIGGERED BY
+hello-node   1          5         5         config
 ----
diff --git a/modules/nodes-pods-autoscaling-creating-cpu.adoc b/modules/nodes-pods-autoscaling-creating-cpu.adoc
index 875eb4b6f870..85f0ec5b7472 100644
--- a/modules/nodes-pods-autoscaling-creating-cpu.adoc
+++ b/modules/nodes-pods-autoscaling-creating-cpu.adoc
@@ -76,11 +76,11 @@ $ oc autoscale <object_type>/<name> \// <1>
 <3> Specify the maximum number of replicas when scaling up.
 <4> Specify the target average CPU utilization over all the pods, represented as a percent of requested CPU. If not specified or negative, a default autoscaling policy is used.
 +
-For example, the following command shows autoscaling for the `image-registry` `Deployment` object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods will increase to 7:
+For example, the following command shows autoscaling for the `hello-node` deployment object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods will increase to 7:
 +
 [source,terminal]
 ----
-$ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75
+$ oc autoscale deployment/hello-node --min=5 --max=7 --cpu-percent=75
 ----
 
 ** To scale for a specific CPU value, create a YAML file similar to the following for an existing object:
diff --git a/modules/nodes-pods-secrets-certificates-creating.adoc b/modules/nodes-pods-secrets-certificates-creating.adoc
index a45681de9126..4bb234b3b1e0 100644
--- a/modules/nodes-pods-secrets-certificates-creating.adoc
+++ b/modules/nodes-pods-secrets-certificates-creating.adoc
@@ -35,7 +35,7 @@ spec:
     targetPort: 9376
 ----
 +
-The certificate and key are in PEM format, stored in `tls.crt` and `tls.key`
+<1> The certificate and key are in PEM format, stored in `tls.crt` and `tls.key`
 respectively.
 
 . Create the service:
diff --git a/modules/nodes-pods-vertical-autoscaler-configuring.adoc b/modules/nodes-pods-vertical-autoscaler-configuring.adoc
index c045670dee04..fa8f910c33d8 100644
--- a/modules/nodes-pods-vertical-autoscaler-configuring.adoc
+++ b/modules/nodes-pods-vertical-autoscaler-configuring.adoc
@@ -8,6 +8,8 @@
 
 You can use the Vertical Pod Autoscaler Operator (VPA) by creating a VPA custom resource (CR). The CR indicates which pods it should analyze and determines the actions the VPA should take with those pods.
 
+You can use the VPA to scale built-in resources such as deployments or stateful sets, and custom resources that manage pods. For more information on using the VPA with custom resources, see "Using the Vertical Pod Autoscaler Operator with Custom Resources."
+
 .Prerequisites
 
 * The workload object that you want to autoscale must exist.
diff --git a/modules/nodes-pods-vertical-autoscaler-custom-resource.adoc b/modules/nodes-pods-vertical-autoscaler-custom-resource.adoc
new file mode 100644
index 000000000000..c3a798f760c4
--- /dev/null
+++ b/modules/nodes-pods-vertical-autoscaler-custom-resource.adoc
@@ -0,0 +1,93 @@
+// Module included in the following assemblies:
+//
+// * nodes/nodes-vertical-autoscaler.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nodes-pods-vertical-autoscaler-custom-resource_{context}"]
+= Example custom resources for the Vertical Pod Autoscaler
+
+The Vertical Pod Autoscaler Operator (VPA) can update not only built-in resources such as deployments or stateful sets, but also custom resources that manage pods.
+
+In order to use the VPA with a custom resource, when you create the `CustomResourceDefinition` (CRD) object, you must configure the `labelSelectorPath` field in the `/scale` subresource. The `/scale` subresource creates a `Scale` object. The `labelSelectorPath` field defines the JSON path inside the custom resource that corresponds to `Status.Selector` in the `Scale` object and in the custom resource. The following is an example of a `CustomResourceDefinition` and a `CustomResource` that fulfills these requirements, along with a `VerticalPodAutoscaler` definition that targets the custom resource. The following example shows the `/scale` subresource contract. 
+
+[NOTE]
+====
+This example does not result in the VPA scaling pods because there is no controller for the custom resource that allows it to own any pods. As such, you must write a controller in a language supported by Kubernetes to manage the reconciliation and state management between the custom resource and your pods. The example illustrates the configuration for the VPA to understand the custom resource as scalable.
+====
+
+.Example custom CRD, CR
+[source,yaml]
+----
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: scalablepods.testing.openshift.io
+spec:
+  group: testing.openshift.io
+  versions:
+  - name: v1
+    served: true
+    storage: true
+    schema:
+      openAPIV3Schema:
+        type: object
+        properties:
+          spec:
+            type: object
+            properties:
+              replicas:
+                type: integer
+                minimum: 0
+              selector:
+                type: string
+          status:
+            type: object
+            properties:
+              replicas:
+                type: integer
+    subresources:
+      status: {}
+      scale:
+        specReplicasPath: .spec.replicas
+        statusReplicasPath: .status.replicas
+        labelSelectorPath: .spec.selector <1>
+  scope: Namespaced
+  names:
+    plural: scalablepods
+    singular: scalablepod
+    kind: ScalablePod
+    shortNames:
+    - spod
+----
+<1> Specifies the JSON path that corresponds to `status.selector` field of the custom resource object.
+
+.Example custom CR
+[source,yaml]
+----
+apiVersion: testing.openshift.io/v1
+kind: ScalablePod
+metadata:
+  name: scalable-cr
+  namespace: default
+spec:
+  selector: "app=scalable-cr" <1>
+  replicas: 1
+----
+<1> Specify the label type to apply to managed pods. This is the field referenced by the `labelSelectorPath` in the custom resource definition object.
+
+.Example VPA object
+[source,yaml]
+----
+apiVersion: autoscaling.k8s.io/v1
+kind: VerticalPodAutoscaler
+metadata:
+  name: scalable-cr
+  namespace: default
+spec:
+  targetRef:
+    apiVersion: testing.openshift.io/v1
+    kind: ScalablePod
+    name: scalable-cr
+  updatePolicy:
+    updateMode: "Auto"
+----
diff --git a/modules/nodes-pods-vertical-autoscaler-tuning.adoc b/modules/nodes-pods-vertical-autoscaler-tuning.adoc
index ecfd6392a3ae..032a45778e4c 100644
--- a/modules/nodes-pods-vertical-autoscaler-tuning.adoc
+++ b/modules/nodes-pods-vertical-autoscaler-tuning.adoc
@@ -20,7 +20,167 @@ You can perform the following tunings on the VPA components by editing the `Vert
 
 * To configure the VPA Operator to monitor only workloads that are being managed by a VPA CR, set the `memory-saver` parameter to `true` for the recommender component.
 
-The following example VPA controller CR sets the VPA API QPS and burts rates, configures the component pod resource requests, and sets `memory-saver` to `true` for the recommender:
+For guidelines on the resources and rate limits that you could set for each VPA component, the following tables provide recommended baseline values, depending on the size of your cluster and other factors. 
+
+[IMPORTANT]
+====
+These recommended values were derived from internal Red{nbsp}Hat testing on clusters that are not necessarily representative of real-world clusters. You should test these values in a non-production cluster before configuring a production cluster.
+====
+
+.Requests by containers in the cluster
+[cols="1,1,1,1,1,1,1,1,1,5,5"]
+|===
+| Component 2+| 1-500 containers 2+| 500-1000 containers 2+| 1000-2000 containers 2+| 2000-4000 containers 2+| 4000+ containers
+
+| 
+| *CPU*
+| *Memory*
+| *CPU*
+| *Memory*
+| *CPU*
+| *Memory*
+| *CPU*
+| *Memory*
+| *CPU*
+| *Memory*
+
+s| Admission 
+| 25m 
+| 50Mi
+| 25m 
+| 75Mi 
+| 40m 
+| 150Mi 
+| 75m 
+| 260Mi 
+| (0.03c)/2 + 10 ^[1]^
+| (0.1c)/2 + 50 ^[1]^
+
+s| Recommender
+| 25m
+| 100Mi
+| 50m
+| 160Mi
+| 75m
+| 275Mi
+| 120m
+| 420Mi
+| (0.05c)/2 + 50 ^[1]^
+| (0.15c)/2 + 120 ^[1]^
+
+s| Updater
+| 25m
+| 100Mi
+| 50m
+| 220Mi
+| 80m
+| 350Mi
+| 150m
+| 500Mi
+| (0.07c)/2 + 20 ^[1]^
+| (0.15c)/2 + 200 ^[1]^
+
+|===
+[.small]
+. `c` is the number of containers in the cluster.
+
+[NOTE]
+====
+It is recommended that you set the memory limit on your containers to at least double the recommended requests in the table. However, because CPU is a compressible resource, setting CPU limits for containers can throttle the VPA. As such, it is recommended that you do not set a CPU limit on your containers.
+====
+
+.Rate limits by VPAs in the cluster
+[cols="1,3,2,3,2,3,2,3,2"]
+|===
+| Component 2+| 1 - 150 VPAs 2+| 151 - 500 VPAs 2+| 501-2000 VPAs 2+| 2001-4000 VPAs
+
+| 
+| *QPS Limit* ^[1]^
+| *Burst* ^[2]^
+| *QPS Limit*
+| *Burst*
+| *QPS Limit*
+| *Burst*
+| *QPS Limit*
+| *Burst*
+
+s| Recommender
+| 5
+| 10
+| 30
+| 60
+| 60
+| 120
+| 120
+| 240
+
+s| Updater
+| 5
+| 10
+| 30
+| 60
+| 60
+| 120
+| 120
+| 240
+
+|===
+[.small]
+. QPS specifies the queries per second (QPS) limit when making requests to Kubernetes API server. The default for the updater and recommender pods is `5.0`. 
+. Burst specifies the burst limit when making requests to Kubernetes API server. The default for the updater and recommender pods is `10.0`.
+
+[NOTE]
+====
+If you have more than 4000 VPAs in your cluster, it is recommended that you start performance tuning with the values in the table and slowly increase the values until you achieve the desired recommender and updater latency and performance. You should adjust these values slowly because increased QPS and Burst could affect the cluster health and slow down the Kubernetes API server if too many API requests are being sent to the API server from the VPA components.
+====
+
+////
+Hiding these two NOTEs as not supported. These and the the above should be sub-bullets for "If you have more than 4000 VPAs in your cluster, note the following recommendations:".
+** It is recommended that you increase the recommender and updater interval, which is how often the VPA fetches pod metrics. However, with the longer intervals, the Operator takes longer to recommend and restart pods. The example `VerticalPodAutoscalerController` CR that follows includes the parameters to increase the intervals.
+** If you increase the `recommender-interval` value, it is recommended that you also increase the `checkpoints-timeout` value, which configures the timeout for writing VPA checkpoints after the start of the recommender interval. It is recommended that you set the timeout to the same value `recommender-interval` so that the recommender pod has time to write checkpoints before the next interval. The example `VerticalPodAutoscalerController` CR that follows includes the parameters to increase the timeout.
+////
+
+////
+Hiding as autoscaling custom resources not supported
+.Admission Rate limits (by custom resource pod creation surge)
+[options="header"]
+|===
+| Component 2+| 1-25 CR pod creation surge ^[1]^ 2+| 26-50 CR pod creation surge 2+| 50+ CR pod creation surge
+
+| 
+| *QPS Limit* ^[2]^
+| *Burst* ^[3]^
+| *QPS Limit*
+| *Burst*
+| *QPS Limit*
+| *Burst*
+
+s| Admission
+| 25
+| 50
+| 50
+| 100
+| Pod Surge / 2
+| Pod Surge
+
+|===
+[.small]
+. _Pod creation surge_ refers to the maximum number of pods that you expect to be created in a single second at any given time.
+. QPS specifies the queries per second (QPS) limit when making requests to Kubernetes API server. The default is `5.0`. 
+. Burst specifies the burst limit when making requests to Kubernetes API server. The default is `10.0`.
+
+[NOTE]
+====
+The admission pod can get throttled if you are using the VPA on custom resources.
+====
+////
+
+The following example VPA controller CR is for a cluster with 1000 to 2000 containers and a pod creation surge of 26 to 50. The CR sets the following values: 
+
+* The container memory and CPU requests for all three VPA components
+* The container memory limit for all three VPA components
+* The QPS and burst rates for all three VPA components
+* The `memory-saver` parameter to `true` for the VPA recommender component
 
 .Example `VerticalPodAutoscalerController` CR
 [source,yaml]
@@ -35,31 +195,37 @@ spec:
     admission: <1>
       container:
         args: <2>
-          - '--kube-api-qps=30.0'
-          - '--kube-api-burst=40.0'
+          - '--kube-api-qps=50.0'
+          - '--kube-api-burst=100.0'
         resources:
           requests: <3>
             cpu: 40m
-            memory: 40Mi
+            memory: 150Mi
+          limits:
+            memory: 300Mi            
     recommender: <4>
       container:
         args:
-          - '--kube-api-qps=20.0'
-          - '--kube-api-burst=60.0'
+          - '--kube-api-qps=60.0'
+          - '--kube-api-burst=120.0'
           - '--memory-saver=true' <5>
         resources:
           requests:
-            cpu: 60m
-            memory: 60Mi
+            cpu: 75m
+            memory: 275Mi
+          limits:
+            memory: 550Mi
     updater: <6>
       container:
         args:
-          - '--kube-api-qps=20.0'
-          - '--kube-api-burst=80.0'
+          - '--kube-api-qps=60.0'
+          - '--kube-api-burst=120.0'
         resources:
           requests:
             cpu: 80m
-            memory: 80Mi
+            memory: 350M
+          limits:
+            memory: 700Mi
   minReplicas: 2
   podMinCPUMillicores: 25
   podMinMemoryMb: 250
@@ -73,11 +239,21 @@ spec:
 * `kube-api-qps`: Specifies the queries per second (QPS) limit when making requests to Kubernetes API server. The default is `5.0`.
 * `kube-api-burst`: Specifies the burst limit when making requests to Kubernetes API server. The default is `10.0`.
 --
-<3> Specifies the CPU and memory requests for the VPA admission controller pod.
+<3> Specifies the resource requests and limits for the VPA admission controller pod.
 <4> Specifies the tuning parameters for the VPA recommender.
 <5> Specifies that the VPA Operator monitors only workloads with a VPA CR. The default is `false`.
 <6> Specifies the tuning parameters for the VPA updater.
 
+////
+Hiding these three callouts as not supported
+<5> Specifies how often the VPA should collect the container metrics for the recommender pod. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, and `h`. The default is one minute.
+<6> Specifies the timeout for writing VPA checkpoints after the start of the recommender interval. If you increase the `recommender-interval` value, it is recommended setting this value to the same value. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, and `h`. The default is one minute.
+<9> Specifies how often the VPA should collect the container metrics for the updater pod. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, and `h`. The default is one minute. 
+          - '--recommender-interval=2m' <5>
+          - '--checkpoints-timeout=' <6>
+          - '--updater-interval=30m0s' <9>
+////
+
 You can verify that the settings were applied to each VPA component pod.
 
 .Example updater pod
@@ -95,13 +271,13 @@ spec:
     - --logtostderr
     - --v=1
     - --min-replicas=2
-    - --kube-api-qps=20.0
-    - --kube-api-burst=80.0
+    - --kube-api-qps=60.0
+    - --kube-api-burst=120.0
 # ...
     resources:
       requests:
         cpu: 80m
-        memory: 80Mi
+        memory: 350M
 # ...
 ----
 
@@ -123,13 +299,13 @@ spec:
     - --tls-private-key=/data/tls-certs/tls.key
     - --client-ca-file=/data/tls-ca-certs/service-ca.crt
     - --webhook-timeout-seconds=10
-    - --kube-api-qps=30.0
-    - --kube-api-burst=40.0
+    - --kube-api-qps=50.0
+    - --kube-api-burst=100.0
 # ...
     resources:
       requests:
         cpu: 40m
-        memory: 40Mi
+        memory: 150Mi
 # ...
 ----
 
@@ -150,13 +326,13 @@ spec:
     - --recommendation-margin-fraction=0.15
     - --pod-recommendation-min-cpu-millicores=25
     - --pod-recommendation-min-memory-mb=250
-    - --kube-api-qps=20.0
-    - --kube-api-burst=60.0
+    - --kube-api-qps=60.0
+    - --kube-api-burst=120.0
     - --memory-saver=true
 # ...
     resources:
       requests:
-        cpu: 60m
-        memory: 60Mi
+        cpu: 75m
+        memory: 275Mi
 # ...
 ----
diff --git a/modules/nodes-scheduler-profiles-about.adoc b/modules/nodes-scheduler-profiles-about.adoc
index 922000fdba11..dc8b2887fedc 100644
--- a/modules/nodes-scheduler-profiles-about.adoc
+++ b/modules/nodes-scheduler-profiles-about.adoc
@@ -14,4 +14,9 @@ The following scheduler profiles are available:
 
 `HighNodeUtilization`:: This profile attempts to place as many pods as possible on to as few nodes as possible. This minimizes node count and has high resource usage per node.
 
+[NOTE]
+====
+Switching to the `HighNodeUtilization` scheduler profile will result in all pods of a `ReplicaSet` object being scheduled on the same node. This will add an increased risk for pod failure if the node fails.
+====
+
 `NoScoring`:: This is a low-latency profile that strives for the quickest scheduling cycle by disabling all score plugins. This might sacrifice better scheduling decisions for faster ones.
diff --git a/modules/nodes-scheduler-taints-tolerations-about.adoc b/modules/nodes-scheduler-taints-tolerations-about.adoc
index 2c4f69af7181..f9d82a2cb391 100644
--- a/modules/nodes-scheduler-taints-tolerations-about.adoc
+++ b/modules/nodes-scheduler-taints-tolerations-about.adoc
@@ -18,7 +18,7 @@ endif::[]
 
 A _taint_ allows a node to refuse a pod to be scheduled unless that pod has a matching _toleration_.
 
-You apply taints to a node through the `Node` specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). When you apply a taint a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint.
+You apply taints to a node through the `Node` specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). When you apply a taint to a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint.
 
 .Example taint in a node specification
 [source,yaml]
diff --git a/modules/nodes-sigstore-configure-cluster-policy.adoc b/modules/nodes-sigstore-configure-cluster-policy.adoc
new file mode 100644
index 000000000000..64780e07418b
--- /dev/null
+++ b/modules/nodes-sigstore-configure-cluster-policy.adoc
@@ -0,0 +1,223 @@
+// Module included in the following assemblies:
+//
+// * nodes/nodes-sigstore-using.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nodes-sigstore-configure-cluster-policy_{context}"]
+= Creating a cluster image policy CR
+
+A `ClusterImagePolicy` custom resource (CR) enables a cluster administrator to configure a sigstore signature verification policy for the entire cluster. When enabled, the Machine Config Operator (MCO) watches the `ClusterImagePolicy` object and updates the `/etc/containers/policy.json` and `/etc/containers/registries.d/sigstore-registries.yaml` files on all the nodes in the cluster.
+
+The following example shows general guidelines on how to configure a `ClusterImagePolicy` object. For more details on the parameters, see "About cluster and image policy parameters."
+
+.Prerequisites
+// Taken from https://issues.redhat.com/browse/OCPSTRAT-918
+* You have a sigstore-supported public key infrastructure (PKI) or a link:https://docs.sigstore.dev/cosign/[Cosign public and private key pair] for signing operations.
+* You have a signing process in place to sign your images.
+* You have access to a registry that supports Cosign signatures, if you are using Cosign signatures.
+* You enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`:
++
+[source,terminal]
+----
+$ oc edit featuregate cluster
+----
++
+.Example `FeatureGate` CR
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: FeatureGate
+metadata:
+  name: cluster
+spec:
+  featureSet: TechPreviewNoUpgrade <1>
+----
+<1> Enables the required `SigstoreImageVerification` feature.
++
+[WARNING]
+====
+Enabling the `TechPreviewNoUpgrade` feature set on your cluster cannot be undone and prevents minor version updates. This feature set allows you to enable these Technology Preview features on test clusters, where you can fully test them. Do not enable this feature set on production clusters.
+====
++
+After you save the changes, new machine configs are created, the machine config pools are updated, and scheduling on each node is disabled while the change is being applied.
+
+.Procedure
+
+. Create a cluster image policy object similar to the following examples. See "About image policy parameters" for specific details on these parameters.
++
+--
+.Example cluster image policy object with a public key policy and the `MatchRepoDigestOrExact` match policy
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1alpha1
+kind: ClusterImagePolicy <1>
+metadata:
+  name: p1
+spec:
+  scopes: <2>
+    - example.com
+  policy: <3>
+    rootOfTrust: <4>
+      policyType: PublicKey <5>
+      publicKey:
+        keyData: a2V5RGF0YQ== <6>
+        rekorKeyData: cmVrb3JLZXlEYXRh <7>
+    signedIdentity: <8>
+      matchPolicy: MatchRepoDigestOrExact
+----
+<1> Creates a `ClusterImagePolicy` object.
+<2> Defines a list of repositories or images assigned to this policy. In a cluster image policy, make sure that the policy does not block the deployment of the {product-title} images in the `quay.io/openshift-release-dev/ocp-release` and `quay.io/openshift-release-dev/ocp-v4.0-art-dev` repositories. Images in these repositories are required for cluster operation.
+<3> Specifies the parameters that define how the images are verified.
+<4> Defines a root of trust for the policy.
+<5> Specifies the policy types that define the root of trust, either a public key or a link:https://docs.sigstore.dev/certificate_authority/overview/[Fulcio certifice]. Here, a public key with Rekor verification.
+<6> For a public key policy, specifies a base64-encoded public key in the PEM format. The maximum length is 8192 characters.
+<7> Optional: Specifies a base64-encoded Rekor public key in the PEM format. The maximum length is 8192 characters.
+<8> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity:
+* `MatchRepoDigestOrExact`.
+* `MatchRepository`.
+* `ExactRepository`. The `exactRepository` parameter must be specified.
+* `RemapIdentity`. The `prefix` and `signedPrefix` parameters must be specified.
+--
++
+--
+.Example cluster image policy object with a Fulcio certificate policy and the `remapIdentity` match policy
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1alpha1
+kind: ClusterImagePolicy <1>
+metadata:
+  name: p1
+spec:
+  scopes: <2>
+    - example.com
+  policy: <3>
+    rootOfTrust: <4>
+      policyType: FulcioCAWithRekor <5>
+      fulcioCAWithRekor: <6>
+        fulcioCAData: a2V5RGF0YQ==
+        fulcioSubject:
+          oidcIssuer: "https://expected.OIDC.issuer/"
+          signedEmail: "expected-signing-user@example.com"
+        rekorKeyData: cmVrb3JLZXlEYXRh <7>
+    signedIdentity:
+      matchPolicy: RemapIdentity <8>
+      remapIdentity:
+        prefix: example.com <9>
+        signedPrefix: mirror-example.com <10>
+----
+<1> Creates a `ClusterImagePolicy` object.
+<2> Defines a list of repositories or images assigned to this policy. In a cluster image policy, make sure that the policy does not block the deployment of the {product-title} images in the `quay.io/openshift-release-dev/ocp-release` and `quay.io/openshift-release-dev/ocp-v4.0-art-dev` repositories. Images in these repositories are required for cluster operation.
+<3> Specifies the parameters that define how the images are verified.
+<4> Defines a root of trust for the policy.
+<5> Specifies the policy types that define the root of trust, either a public key or a link:https://docs.sigstore.dev/certificate_authority/overview/[Fulcio certificate]. Here, a Fulcio certificate with required Rekor verification.
+<6> For a Fulcio certificate policy, the following parameters are required:
+* `fulcioCAData`: Specifies a base64-encoded Fulcio certificate in the PEM format. The maximum length is 8192 characters.
+* `fulcioSubject`: Specifies the OIDC issuer and the email of the Fulcio authentication configuration.
+<7> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
+<8> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity.
+* `MatchRepoDigestOrExact`.
+* `MatchRepository`.
+* `ExactRepository`. The `exactRepository` parameter must be specified.
+* `RemapIdentity`. The `prefix` and `signedPrefix` parameters must be specified.
+<9> For the `remapIdentity` match policy, specifies the prefix that should be matched against the scoped image prefix. If the two match, the scoped image prefix is replaced with the value of `signedPrefix`. The maximum length is 512 characters.
+<10> For the `remapIdentity` match policy, specifies the image prefix to be remapped, if needed. The maximum length is 512 characters.
+--
+
+. Create the cluster image policy object:
++
+[source,terminal]
+----
+$ oc create -f <file_name>.yaml
+----
++
+The Machine Config Operator (MCO) updates the machine config pools (MCP) in your cluster.
+
+.Verification
+
+* After the nodes in your cluster are updated, you can verify that the cluster image policy has been configured:
+
+.. Start a debug pod for the node by running the following command:
++
+[source,terminal]
+----
+$ oc debug node/<node_name>
+----
+
+.. Set `/host` as the root directory within the debug shell by running the following command:
++
+[source,terminal]
+----
+sh-5.1# chroot /host/
+----
+
+.. Examine the `policy.json` file  by running the following command:
++
+[source,terminal]
+----
+sh-5.1# cat /etc/containers/policy.json
+----
++
+.Example output for the cluster image policy object with a public key showing the new cluster image policy
+[source,json]
+----
+# ...
+  "transports": {
+# ...
+    "docker": {
+      "example.com": [
+        {
+          "type": "sigstoreSigned",
+          "keyData": "a2V5RGF0YQ==",
+          "rekorPublicKeyData": "cmVrb3JLZXlEYXRh",
+          "signedIdentity": {
+            "type": "matchRepoDigestOrExact"
+          }
+        }
+      ],
+# ...
+----
++
+.Example output for the cluster image policy object with a Fulcio certificate showing the new cluster image policy
+[source,json]
+----
+# ...
+  "transports": {
+# ...
+    "docker": {
+      "example.com": [
+        {
+          "type": "sigstoreSigned",
+          "fulcio": {
+            "caData": "a2V5RGF0YQ==",
+            "oidcIssuer": "https://expected.OIDC.issuer/",
+            "subjectEmail": "expected-signing-user@example.com"
+          },
+          "rekorPublicKeyData": "cmVrb3JLZXlEYXRh",
+          "signedIdentity": {
+            "type": "remapIdentity",
+            "prefix": "example.com",
+            "signedPrefix": "mirror-example.com"
+          }
+        }
+      ],
+# ...
+----
+
+.. Examine the `sigstore-registries.yaml` file  by running the following command:
++
+[source,terminal]
+----
+sh-5.1# cat /etc/containers/registries.d/sigstore-registries.yaml
+----
++
+.Example output showing that the scoped registry was added
+[source,yaml]
+----
+docker:
+  example.com:
+    use-sigstore-attachments: true <1>
+  quay.io/openshift-release-dev/ocp-release:
+    use-sigstore-attachments: true
+----
+<1> When `true`, specifies that sigstore signatures are going to be read along with the image.
+// https://github.com/openshift/api/blob/master/config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clusterimagepolicies-TechPreviewNoUpgrade.crd.yaml
diff --git a/modules/nodes-sigstore-configure-image-policy.adoc b/modules/nodes-sigstore-configure-image-policy.adoc
new file mode 100644
index 000000000000..80f85864206f
--- /dev/null
+++ b/modules/nodes-sigstore-configure-image-policy.adoc
@@ -0,0 +1,261 @@
+// Module included in the following assemblies:
+//
+// * nodes/nodes-sigstore-using.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nodes-sigstore-configure-image-policy_{context}"]
+= Creating an image policy CR
+
+An `ImagePolicy` custom resource (CR) enables a cluster administrator or application developer to configure a sigstore signature verification policy for a specific namespace. The MCO watches `ImagePolicy` instances in different namespaces and updates the `/etc/crio/policies/<namespace>.json` and `/etc/containers/registries.d/sigstore-registries.yaml` files on all the nodes in the cluster.
+
+[NOTE]
+====
+If a scoped image or repository in an image policy is nested under one of the scoped images or repositories in a cluster image policy, only the policy from cluster image policy is applied. However, the image policy object is created with an error message. For example, if an image policy specifies `example.com/global/image`, and the cluster image policy specifies `example.com/global`, the namespace inherits the policy from the cluster image policy.
+====
+
+The following example shows general guidelines on how to configure an `ImagePolicy` object. For more details on the parameters, see "About cluster and image policy parameters".
+
+.Prerequisites
+// Taken from https://issues.redhat.com/browse/OCPSTRAT-918
+* You have a sigstore-supported public key infrastructure (PKI) or provide link:https://docs.sigstore.dev/cosign/[Cosign public and private key pair] for signing operations.
+* You have a signing process in place to sign your images.
+* You have access to a registry that supports Cosign signatures, if you are using Cosign signatures.
+* If registry mirrors are configured for the {product-title} release image repositories, `quay.io/openshift-release-dev/ocp-release` and `quay.io/openshift-release-dev/ocp-v4.0-art-dev`, before enabling the Technology Preview feature set, you must mirror the sigstore signatures for the {product-title} release images into your mirror registry. Otherwise, the default `openshift` cluster image policy, which enforces signature verification for the release repository, will block the ability of the Cluster Version Operator to move the CVO Pod to new nodes, which prevents the node update that results from the feature set change.
++
+You can use the `oc image mirror` command to mirror the signatures. For example:
++
+[source,terminal]
+----
+$ oc image mirror quay.io/openshift-release-dev/ocp-release:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig \
+mirror.com/image/repo:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig
+----
+
+* You enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`:
++
+[source,terminal]
+----
+$ oc edit featuregate cluster
+----
++
+.Example `FeatureGate` CR
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: FeatureGate
+metadata:
+  name: cluster
+spec:
+  featureSet: TechPreviewNoUpgrade <1>
+----
+<1> Enables the required `SigstoreImageVerification` feature.
++
+[WARNING]
+====
+Enabling the `TechPreviewNoUpgrade` feature set on your cluster cannot be undone and prevents minor version updates. This feature set allows you to enable these Technology Preview features on test clusters, where you can fully test them. Do not enable this feature set on production clusters.
+====
++
+After you save the changes, new machine configs are created, the machine config pools are updated, and scheduling on each node is disabled while the change is being applied.
+
+.Procedure
+
+. Create an image policy object similar to the following examples. See "About cluster and image policy parameters" for specific details on these parameters.
++
+--
+.Example image policy object with a public key policy and the `MatchRepository` match policy
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1alpha1
+kind: ImagePolicy <1>
+metadata:
+  name: p0
+  namespace: mynamespace <2>
+spec:
+  scopes: <3>
+    - example.io/crio/signed
+  policy: <4>
+    rootOfTrust: <5>
+      policyType: PublicKey <6>
+      publicKey:
+        keyData: a2V5RGF0YQ== <7>
+        rekorKeyData: cmVrb3JLZXlEYXRh <8>
+    signedIdentity:
+      matchPolicy: MatchRepository <9>
+----
+<1> Creates an `ImagePolicy` object.
+<2> Specifies the namespace where the image policy is applied.
+<3> Defines a list of repositories or images assigned to this policy.
+<4> Specifies the parameters that define how the images are verified.
+<5> Defines a root of trust for the policy.
+<6> Specifies the policy types that define the root of trust, either a public key or a link:https://docs.sigstore.dev/certificate_authority/overview/[Fulcio certificate]. Here, a public key with Rekor verification.
+<7> For a public key policy, specifies a base64-encoded public key in the PEM format. The maximum length is 8192 characters.
+<8> Optional: Specifies a base64-encoded Rekor public key in the PEM format. The maximum length is 8192 characters.
+<9> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity:
+* `MatchRepoDigestOrExact`.
+* `MatchRepository`.
+* `ExactRepository`. The `exactRepository` parameter must be specified.
+* `RemapIdentity`. The `prefix` and `signedPrefix` parameters must be specified.
+--
++
+--
+.Example image policy object with a Fulcio certificate policy and the `ExactRepository` match policy
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1alpha1
+kind: ImagePolicy <1>
+metadata:
+  name: p1
+  namespace: mynamespace <2>
+spec:
+  scopes: <3>
+    - example.io/crio/signed
+  policy: <4>
+    rootOfTrust: <5>
+      policyType: FulcioCAWithRekor <6>
+      fulcioCAWithRekor: <7>
+        fulcioCAData: a2V5RGF0YQ==
+        fulcioSubject:
+          oidcIssuer: "https://expected.OIDC.issuer/"
+          signedEmail: "expected-signing-user@example.com"
+        rekorKeyData: cmVrb3JLZXlEYXRh <8>
+    signedIdentity:
+      matchPolicy: ExactRepository <9>
+      exactRepository:
+        repository: quay.io/crio/signed <10>
+----
+<1> Creates an `ImagePolicy` object.
+<2> Specifies the namespace where the image policy is applied.
+<3> Defines a list of repositories or images assigned to this policy.
+<4> Specifies the parameters that define how the images are verified.
+<5> Defines a root of trust for the policy.
+<6> Specifies the policy types that define the root of trust, either a public key or a link:https://docs.sigstore.dev/certificate_authority/overview/[Fulcio certificate]. Here, a Fulcio certificate with required Rekor verification.
+<7> For a Fulcio certificate policy, the following parameters are required:
+* `fulcioCAData`: Specifies a base64-encoded Fulcio certificate in the PEM format. The maximum length is 8192 characters.
+* `fulcioSubject`: Specifies the OIDC issuer and the email of the Fulcio authentication configuration.
+<8> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
+<9> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity:
+* `MatchRepoDigestOrExact`.
+* `MatchRepository`.
+* `ExactRepository`. The `exactRepository` parameter must be specified.
+* `RemapIdentity`. The `prefix` and `signedPrefix` parameters must be specified.
+<10> For the `exactRepository` match policy, specifies the repository that contains the image identity and signature.
+--
+
+. Create the image policy object:
++
+[source,terminal]
+----
+$ oc create -f <file_name>.yaml
+----
++
+The Machine Config Operator (MCO) updates the machine config pools (MCP) in your cluster.
+
+.Verification
+
+* After the nodes in your cluster are updated, you can verify that the image policy has been configured:
+
+.. Start a debug pod for the node by running the following command:
++
+[source,terminal]
+----
+$ oc debug node/<node_name>
+----
+
+.. Set `/host` as the root directory within the debug shell by running the following command:
++
+[source,terminal]
+----
+sh-5.1# chroot /host/
+----
+
+.. Examine the `<namespace>.json` file by running the following command:
++
+[source,terminal]
+----
+sh-5.1# cat /etc/crio/policies/<namespace>.json
+----
++
+.Example output for the image policy object with a public key showing the new image policy
+[source,json]
+----
+# ...
+ "transports": {
+# ...
+  "docker": {
+   "example.io/crio/signed": [
+    {
+     "type": "sigstoreSigned",
+     "keyData": "a2V5RGF0YQ==",
+     "rekorPublicKeyData": "cmVrb3JLZXlEYXRh",
+     "signedIdentity": {
+      "type": "matchRepository",
+      "dockerRepository": "example.org/crio/signed"
+     }
+# ...
+----
++
+.Example output for the image policy object with a Fulcio certificate showing the new image policy
+[source,json]
+----
+# ...
+ "transports": {
+# ...
+  "docker": {
+   "example.io/crio/signed": [
+    {
+     "type": "sigstoreSigned",
+     "fulcio": {
+      "caData": "a2V5RGF0YQ==",
+      "oidcIssuer": "https://expected.OIDC.issuer/",
+      "subjectEmail": "expected-signing-user@example.com"
+     },
+     "rekorPublicKeyData": "cmVrb3JLZXlEYXRh",
+     "signedIdentity": {
+      "type": "exactRepository",
+      "dockerRepository": "quay.io/crio/signed"
+     }
+    }
+   ],
+# ...
+----
+
+.. Examine the `sigstore-registries.yaml` file  by running the following command:
++
+[source,terminal]
+----
+sh-5.1# cat /etc/containers/registries.d/sigstore-registries.yaml
+----
++
+.Example output showing that the scoped registry was added
+[source,yaml]
+----
+docker:
+  example.io/crio/signed:
+    use-sigstore-attachments: true <1>
+  quay.io/openshift-release-dev/ocp-release:
+    use-sigstore-attachments: true
+----
+<1> When `true`, specifies that sigstore signatures are going to be read along with the image.
+
+..  Check the crio log for sigstore signature verification by running the following command:
++
+[source,terminal]
+----
+sh-5.1#  journalctl -u crio | grep -A 100 "Pulling image: example.io/crio"
+----
++
+.Example output with timestamp removed
+[source,terminal]
+----
+# ...
+msg="IsRunningImageAllowed for image docker:example.io/crio/signed:latest" file="signature/policy_eval.go:274" <1>
+msg="Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150" <2>
+msg="Reading /var/lib/containers/sigstore/crio/signed@sha256=18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a/signature-1" file="docker/docker_image_src.go:545"
+msg="Looking for Sigstore attachments in quay.io/crio/signed:sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig" file="docker/docker_client.go:1138"
+msg="GET https://quay.io/v2/crio/signed/manifests/sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig" file="docker/docker_client.go:617"
+msg="Content-Type from manifest GET is \"application/vnd.oci.image.manifest.v1+json\"" file="docker/docker_client.go:989"
+msg="Found a Sigstore attachment manifest with 1 layers" file="docker/docker_image_src.go:639"
+msg="Fetching Sigstore attachment 1/1: sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45" file="docker/docker_image_src.go:644"
+# ...
+----
+<1> The `IsRunningImageAllowed` line confirms that image is allowed by the configured sigstore verification policy.
+<2> The `Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150` line confirms that the image policy has been applied.
diff --git a/modules/nodes-sigstore-configure.adoc b/modules/nodes-sigstore-configure.adoc
new file mode 100644
index 000000000000..22ed27b9976d
--- /dev/null
+++ b/modules/nodes-sigstore-configure.adoc
@@ -0,0 +1,87 @@
+// Module included in the following assemblies:
+//
+// * nodes/nodes-sigstore-using.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nodes-sigstore-configure_{context}"]
+= About configuring sigstore support
+
+You can use the `ClusterImagePolicy` and `ImagePolicy` custom resource (CR) objects to enable and configure sigstore support for the entire cluster or a specific namespace. These objects contain a policy that specifies the images and repositories to be verified by using sigstore tooling and how the signatures must be verified.
+
+* Cluster image policy. A cluster image policy object enables a cluster administrator to configure a sigstore signature verification policy for the entire cluster. When enabled, the Machine Config Operator (MCO) watches the `ClusterImagePolicy` object and updates the `/etc/containers/policy.json` and `/etc/containers/registries.d/sigstore-registries.yaml` files on all nodes in the cluster.
++
+[IMPORTANT]
+====
+The default `openshift` cluster image policy provides sigstore support for the required {product-title} images. You must not remove or modify this cluster image policy object.
+====
+
+* Image policy. An image policy enables a cluster administrator or application developer to configure a sigstore signature verification policy for a specific namespace. The MCO watches an `ImagePolicy` instance in different namespaces and creates or updates the `/etc/crio/policies/<namespace>.json` and `/etc/containers/registries.d/sigstore-registries.yaml` files on all nodes in the cluster.
++
+If the image or repository in an image policy is nested under one of the images or repositories in a cluster image policy, only the policy from cluster image policy is applied. For example, if an image policy specifies `example.com/global/image`, and the cluster image policy specifies `example.com/global`, the namespace uses the policy from the cluster image policy. The image policy object is created and shows an error similar to the following message:
++
+.Example image policy with a conflicting image identity
+[source,yaml]
+----
+API Version:  config.openshift.io/v1alpha1
+Kind:         ImagePolicy
+Name:         p0
+Namespace:    mynamespace
+# ...
+Status:
+  Conditions:
+    Message: has conflicting scope(s) ["example.com/global/image"] that equal to or nest inside existing clusterimagepolicy, only policy from clusterimagepolicy scope(s) will be applied
+    Reason: ConflictScopes
+# ...
+----
+
+[id="nodes-sigstore-configure-parameters_{context}"]
+== About cluster and image policy parameters
+
+The following parameters apply to cluster and image policies. For information on using these parameters, see "Creating a cluster image policy CR" and "Creating an image policy CR."
+
+// Based on https://github.com/openshift/api/blob/master/config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_imagepolicies-TechPreviewNoUpgrade.crd.yaml
+
+`scopes`:: Defines a list of repositories and images assigned to a policy. You must list at least one of the following scopes:
++
+--
+* An individual image, by using a tag or digest, such as `example.com/namespace/image:latest`
+* A repository, by omitting the tag or digest, such as `example.com`
+* A repository namespace, such as `example.com/namespace/`
+* A registry host, by specifying only the host name and port number or a wildcard expression starting with `\*.`, such as `*.example.com`
+--
++
+If multiple scopes match a single scope in the same a cluster or image policy, the policy for only the most specific scope applies.
++
+If a scoped image or repository in an image policy is nested under one of the scoped images or repositories in a cluster image policy, only the policy from cluster image policy is applied. However, the image policy object is created. For example, if an image policy specifies `example.com/global/image`, and the cluster image policy specifies `example.com/global`, the namespace inherits the policy from the cluster image policy.
+
+`policy`:: Contains configuration to allow images from the sources listed in `scopes` to be verified, and defines how images not matching the verification policy are treated. You must configure a `rootOfTrust` and optionally, a `signedIdentity`.
+* `rootOfTrust`: Specifies the root of trust for the policy. Configure either a public key or a link:https://docs.sigstore.dev/certificate_authority/overview/[Fulcio certificate].
+** `publicKey`: Indicates that the policy relies on a sigstore public key. You must specify a base64-encoded PEM format public key. You can optionally include link:https://docs.sigstore.dev/logging/overview/[Rekor verification].
+** `FulcioCAWithRekor`: Indicates that the policy is based on a Fulcio certificate. You must specify the following parameters:
+*** A base64-encoded PEM-format Fulcio CA
+*** An OpenID Connect (OIDC) issuer
+*** The email of the Fulcio authentication configuration
+*** The link:https://docs.sigstore.dev/logging/overview/[Rekor verification]
+* `signedIdentity`: Specifies the approach used to verify the image in the signature and the actual image itself. To configure a signed identity, you must specify one of the following parameters as the match policy:
+** `MatchRepoDigestOrExact`. The image referenced in the signature must be in the same repository as the image itself. If the image carries a tag, the image referenced in the signature must match exactly. This is the default.
+** `MatchRepository`. The image referenced in the signature must be in the same repository as the image itself. If the image carries a tag, the image referenced in the signature does not need to match exactly. This is useful to pull an image that contains the `latest` tag if the image is signed with a tag specifying an exact image version.
+** `ExactRepository`. The image referenced in the signature must be in the same repository that is specified by the `exactRepository` parameter. The `exactRepository` parameter must be specified.
+** `RemapIdentity`. If the scoped repository or image matches a specified `prefix`, that prefix is replaced by a specified `signedPrefix`. If the image identity does not match, the `prefix` is unchanged and no remapping takes place. This option can be used when verifying signatures for a mirror of some other repository namespace that preserves the vendor’s repository structure.
++
+The `prefix` and `signedPrefix` can be either `host[:port]` values that match the exact `host[:port]` string, repository namespaces, or repositories. The `prefix` and `signedPrefix` must not contain tags or digests. For example, to specify a single repository, use `example.com/library/busybox` and not `busybox`. To specify the parent namespace of `example.com/library/busybox`, you can use `example.com/library`.
++
+You must specify the following parameters:
++
+*** `prefix`: Specifies the image prefix to be matched.
+*** `signedPrefix`: Specifies the image prefix to be remapped, if needed.
+
+[id="nodes-sigstore-configure-parameters-modify_{context}"]
+== About modifying or removing image policies
+
+You can modify or remove a cluster image policy or an image policy by using the same commands as any other custom resource (CR) object.
+
+You can modify an existing policy by editing the policy YAML and running an `oc apply` command on the file or directly editing the `ClusterImagePolicy` or `ImagePolicy` object. Both methods apply the changes in the same manner.
+
+You can create multiple policies for a cluster or namespace. This allows you to create different policies for different images or repositories.
+
+You can remove a policy by deleting the `ClusterImagePolicy` and `ImagePolicy` objects.
diff --git a/modules/nodes-sigstore-using-about.adoc b/modules/nodes-sigstore-using-about.adoc
index 39ffe2ec583e..c306d91b457e 100644
--- a/modules/nodes-sigstore-using-about.adoc
+++ b/modules/nodes-sigstore-using-about.adoc
@@ -4,6 +4,9 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="nodes-sigstore-using-about_{context}"]
-= About the sigstore project
+= About sigstore
+
+The sigstore project enables developers to sign-off on what they build and administrators to verify signatures and monitor workflows at scale. With the sigstore project, signatures can be stored in the same registry as the build images. A second server is not needed. The identity piece of a signature is tied to the OpenID Connect (OIDC) identity through the Fulcio certificate authority, which simplifies the signature process by allowing key-less signing. Additionally, sigstore includes Rekor, which records signature metadata to an immutable, tamper-resistant ledger.
+
+You can use the `ClusterImagePolicy` and `ImagePolicy` custom resource (CR) objects to enable and configure sigstore support at the cluster or namespace scope. These objects specify the images and repositories to be verified and how the signatures must be verified.
 
-The sigstore project enables developers to sign-off on what they build and administrators to verify signatures and monitor workflows at scale. With the sigstore project, signatures can be stored in the same registry as the build images. A second server is not needed. The identity piece of a signature is tied to the OpenID Connect (OIDC) identity through the Fulcio certificate authority, which simplifies the signature process by allowing key-less signing. Additionally, sigstore includes Rekor, which records signature metadata to an immutable, tamper-resistant ledger.
\ No newline at end of file
diff --git a/modules/nvidia-gpu-enablement.adoc b/modules/nvidia-gpu-enablement.adoc
index 61abf456efbe..5c20e3308561 100644
--- a/modules/nvidia-gpu-enablement.adoc
+++ b/modules/nvidia-gpu-enablement.adoc
@@ -14,5 +14,5 @@ image::512_OpenShift_NVIDIA_GPU_enablement_1223.png[NVIDIA GPU enablement]
 
 [NOTE]
 ====
-MIG is only supported with A30, A100, A100X, A800, AX800, H100, and H800.
+MIG is supported on GPUs starting with the NVIDIA Ampere generation. For a list of GPUs that support MIG, see the link:https://docs.nvidia.com/datacenter/tesla/mig-user-guide/#supported-gpus[NVIDIA MIG User Guide].
 ====
diff --git a/modules/nw-cno-enable-ip-forwarding.adoc b/modules/nw-cno-enable-ip-forwarding.adoc
index eefcc4c55f3e..be2a1432e036 100644
--- a/modules/nw-cno-enable-ip-forwarding.adoc
+++ b/modules/nw-cno-enable-ip-forwarding.adoc
@@ -60,7 +60,7 @@ The status should eventually report as `Available`, `Progressing=False`, and `De
 +
 [source,terminal]
 ----
-$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}
+$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
 ----
 +
 [NOTE]
diff --git a/modules/nw-configuring-sriov-rdma-cni.adoc b/modules/nw-configuring-sriov-rdma-cni.adoc
new file mode 100644
index 000000000000..9ed6b8065ffd
--- /dev/null
+++ b/modules/nw-configuring-sriov-rdma-cni.adoc
@@ -0,0 +1,164 @@
+// Module included in the following assemblies:
+//
+// * networking/hardware_networks/configuring-sriov-rdma-cni.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-sriov-configuring-sriov-rdma-cni_{context}"]
+= Configuring SR-IOV RDMA CNI
+
+Configure an RDMA CNI on SR-IOV.
+
+[NOTE]
+====
+This procedure applies only to Mellanox devices.
+====
+
+.Prerequisites
+
+* You have installed the OpenShift CLI (`oc`).
+* You have access to the cluster as a user with the `cluster-admin` role.
+* You have installed the SR-IOV Network Operator.
+
+.Procedure
+
+. Create an `SriovNetworkPoolConfig` CR and save it as `sriov-nw-pool.yaml`, as shown in the following example:
++
+.Example `SriovNetworkPoolConfig` CR
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetworkPoolConfig
+metadata:
+  name: worker
+  namespace: openshift-sriov-network-operator
+spec:
+  maxUnavailable: 1 
+  nodeSelector:
+    matchLabels:
+      node-role.kubernetes.io/worker: ""
+  rdmaMode: exclusive <1>
+----
+<1> Set RDMA network namespace mode to `exclusive`.
+
+. Create the `SriovNetworkPoolConfig` resource by running the following command:
++
+[source,terminal]
+----
+$ oc create -f sriov-nw-pool.yaml
+----
+
+. Create an `SriovNetworkNodePolicy` CR and save it as `sriov-node-policy.yaml`, as shown in the following example: 
++
+.Example `SriovNetworkNodePolicy` CR
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetworkNodePolicy
+metadata:
+  name: sriov-nic-pf1
+  namespace: openshift-sriov-network-operator
+spec:
+  deviceType: netdevice
+  isRdma: true <1>
+  nicSelector:
+    pfNames: ["ens3f0np0"]
+  nodeSelector:
+    node-role.kubernetes.io/worker: ""
+  numVfs: 4
+  priority: 99
+  resourceName: sriov_nic_pf1
+----
+<1> Activate RDMA mode.
+
+. Create the `SriovNetworkNodePolicy` resource by running the following command:
++
+[source,terminal]
+----
+$ oc create -f sriov-node-policy.yaml
+----
+
+. Create an `SriovNetwork` CR and save it as `sriov-network.yaml`, as shown in the following example: 
++
+.Example `SriovNetwork` CR
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetwork
+metadata:
+  name: sriov-nic-pf1
+  namespace: openshift-sriov-network-operator
+spec:
+  networkNamespace: sriov-tests
+  resourceName: sriov_nic_pf1
+    ipam: |- 
+  metaPlugins: |
+    {
+      "type": "rdma" <1>
+    }
+----
+<1> Create the RDMA plugin.
+
+. Create the `SriovNetwork` resource by running the following command:
++
+[source,terminal]
+----
+$ oc create -f sriov-network.yaml
+----
+
+.Verification
+
+. Create a  `Pod` CR and save it as `sriov-test-pod.yaml`, as shown in the following example: 
++
+.Example runtime configuration
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: sample-pod
+  annotations:
+    k8s.v1.cni.cncf.io/networks: |-
+      [
+        {
+          "name": "net1",
+          "mac": "20:04:0f:f1:88:01",
+          "ips": ["192.168.10.1/24", "2001::1/64"]
+        }
+      ]
+spec:
+  containers:
+  - name: sample-container
+    image: <image>
+    imagePullPolicy: IfNotPresent
+    command: ["sleep", "infinity"]
+----
+
+. Create the test pod by running the following command:
++
+[source,terminal]
+----
+$ oc create -f sriov-test-pod.yaml
+----
+
+. Log in to the test pod by running the following command:
++
+[source,terminal]
+----
+$ oc rsh testpod1 -n sriov-tests
+----
+
+. Verify that the path to the `hw-counters` directory exists by running the following command:
++
+[source,terminal]
+----
+$ ls /sys/bus/pci/devices/${PCIDEVICE_OPENSHIFT_IO_SRIOV_NIC_PF1}/infiniband/*/ports/1/hw_counters/
+----
++
+.Example output
+[source,terminal]
+----
+duplicate_request       out_of_buffer req_cqe_flush_error           resp_cqe_flush_error        roce_adp_retrans        roce_slow_restart_trans
+implied_nak_seq_err     out_of_sequence req_remote_access_errors    resp_local_length_error     roce_adp_retrans_to     rx_atomic_requests
+lifespan                packet_seq_err req_remote_invalid_request   resp_remote_access_errors   roce_slow_restart       rx_read_requests
+local_ack_timeout_err  req_cqe_error resp_cqe_error                 rnr_nak_retry_err           roce_slow_restart_cnps  rx_write_requests
+----
\ No newline at end of file
diff --git a/modules/nw-controlling-dns-pod-placement.adoc b/modules/nw-controlling-dns-pod-placement.adoc
index d85d216ec1b3..c03d76ac92b5 100644
--- a/modules/nw-controlling-dns-pod-placement.adoc
+++ b/modules/nw-controlling-dns-pod-placement.adoc
@@ -8,7 +8,12 @@
 
 The DNS Operator has two daemon sets: one for CoreDNS called `dns-default` and one for managing the `/etc/hosts` file called `node-resolver`.
 
-You might find a need to control which nodes have CoreDNS pods assigned and running, although this is not a common operation. For example, if the cluster administrator has configured security policies that can prohibit communication between pairs of nodes, that would necessitate restricting the set of nodes on which the daemonset for CoreDNS runs. If DNS pods are running on some nodes in the cluster and the nodes where DNS pods are not running have network connectivity to nodes where DNS pods are running, DNS service will be available to all pods.
+You can assign and run CoreDNS pods on specified nodes. For example, if the cluster administrator has configured security policies that prohibit communication between pairs of nodes, you can configure CoreDNS pods to run on a restricted set of nodes.
+
+DNS service is available to all pods if the following circumstances are true:
+
+* DNS pods are running on some nodes in the cluster.
+* The nodes on which DNS pods are not running have network connectivity to nodes on which DNS pods are running, 
 
 The `node-resolver` daemon set must run on every node host because it adds an entry for the cluster image registry to support pulling images. The `node-resolver` pods have only one job: to look up the `image-registry.openshift-image-registry.svc` service's cluster IP address and add it to `/etc/hosts` on the node host so that the container runtime can resolve the service name.
 
@@ -23,15 +28,24 @@ As a cluster administrator, you can use a custom node selector to configure the
 .Procedure
 
 * To allow the daemon set for CoreDNS to run on certain nodes, configure a taint and toleration:
+
+. Set a taint on the nodes that you want to control DNS pod placement by entering the following command:
++
+[source,terminal]
+----
+$ oc adm taint nodes <node_name> dns-only=abc:NoExecute <1>
+----
 +
-. Modify the DNS Operator object named `default`:
+<1> Replace `<node_name>` with the actual name of the node.
+
+. Modify the DNS Operator object named `default` to include the corresponding toleration by entering the following command: 
 +
 [source,terminal]
 ----
 $ oc edit dns.operator/default
 ----
-+
-. Specify a taint key and a toleration for the taint:
+
+. Specify a taint key and a toleration for the taint. The following toleration matches the taint set on the nodes.
 +
 [source,yaml]
 ----
@@ -39,9 +53,24 @@ $ oc edit dns.operator/default
    nodePlacement:
      tolerations:
      - effect: NoExecute
-       key: "dns-only"
-       operators: Equal
+       key: "dns-only" <1>
+       operator: Equal
        value: abc
-       tolerationSeconds: 3600 <1>
+       tolerationSeconds: 3600 <2>
 ----
-<1> If the taint is `dns-only`, it can be tolerated indefinitely. You can omit `tolerationSeconds`.
+<1> If the `key` field is set to `dns-only`, it can be tolerated indefinitely.
+<2> The `tolerationSeconds` field is optional.
+
+. Optional: To specify node placement using a node selector, modify the default DNS Operator:
+
+.. Edit the DNS Operator object named `default` to include a node selector:
++
+[source,yaml]
+----
+ spec:
+   nodePlacement:
+     nodeSelector:    <1>
+       node-role.kubernetes.io/control-plane: ""
+----
++
+<1> This node selector ensures that the CoreDNS pods run only on control plane nodes.
\ No newline at end of file
diff --git a/modules/nw-creating-a-route.adoc b/modules/nw-creating-a-route.adoc
index 8529bca9a9c9..50b512a15c78 100644
--- a/modules/nw-creating-a-route.adoc
+++ b/modules/nw-creating-a-route.adoc
@@ -6,14 +6,13 @@
 [id="nw-creating-a-route_{context}"]
 = Creating an HTTP-based route
 
-A route allows you to host your application at a public URL. It can either be secure or unsecured, depending on the network security configuration of your application. An HTTP-based route is an unsecured route that uses the basic HTTP routing protocol and exposes a service on an unsecured application port.
+Create a route to host your application at a public URL. The route can either be secure or unsecured, depending on the network security configuration of your application. An HTTP-based route is an unsecured route that uses the basic HTTP routing protocol and exposes a service on an unsecured application port.
 
 The following procedure describes how to create a simple HTTP-based route to a web application, using the `hello-openshift` application as an example.
 //link:https://github.com/openshift/origin/tree/master/examples/hello-openshift[hello-openshift]
 
 .Prerequisites
 
-
 * You installed the OpenShift CLI (`oc`).
 * You are logged in as an administrator.
 * You have a web application that exposes a port and a TCP endpoint listening for traffic on the port.
@@ -66,15 +65,15 @@ kind: Route
 metadata:
   name: hello-openshift
 spec:
-  host: hello-openshift-hello-openshift.<Ingress_Domain> <1>
+  host: www.example.com <1>
   port:
     targetPort: 8080 <2>
   to:
     kind: Service
     name: hello-openshift
 ----
-<1> `<Ingress_Domain>` is the default ingress domain name. The `ingresses.config/cluster` object is created during the installation and cannot be changed. If you want to specify a different domain, you can specify an alternative cluster domain using the `appsDomain` option.
-<2> `targetPort` is the target port on pods that is selected by the service that this route points to.
+<1> The `host` field is an alias DNS record that points to the service. This field can be any valid DNS name, such as `www.example.com`. The DNS name must follow DNS952 subdomain conventions. If not specified, a route name is automatically generated. 
+<2> The `targetPort` field is the target port on pods that is selected by the service that this route points to.
 
 +
 [NOTE]
diff --git a/modules/nw-cudn-about.adoc b/modules/nw-cudn-about.adoc
new file mode 100644
index 000000000000..5cf8eb3a44da
--- /dev/null
+++ b/modules/nw-cudn-about.adoc
@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="about-cudn_{context}"]
+= About the ClusterUserDefinedNetwork CR
+
+The `ClusterUserDefinedNetwork` (UDN) custom resource (CR) provides cluster-scoped network segmentation and isolation for administrators only.
+
+The following diagram demonstrates how a cluster administrator can use the `ClusterUserDefinedNetwork` CR to create network isolation between tenants. This network configuration allows a network to span across many namespaces. In the diagram, network isolation is achieved through the creation of two user-defined networks, `udn-1` and `udn-2`. These networks are not connected and the `spec.namespaceSelector.matchLabels` field is used to select different namespaces. For example, `udn-1` configures and isolates communication for `namespace-1` and `namespace-2`, while `udn-2` configures and isolates communication for `namespace-3` and `namespace-4`. Isolated tenants (Tenants 1 and Tenants 2) are created by separating namespaces while also allowing pods in the same namespace to communicate.
+
+.Tenant isolation using a ClusterUserDefinedNetwork CR
+image::528-OpenShift-multitenant-0225.png[The tenant isolation concept in a user-defined network (UDN)]
\ No newline at end of file
diff --git a/modules/nw-cudn-best-practices.adoc b/modules/nw-cudn-best-practices.adoc
new file mode 100644
index 000000000000..5e6ad7a8dba0
--- /dev/null
+++ b/modules/nw-cudn-best-practices.adoc
@@ -0,0 +1,31 @@
+//module included in the following assembly:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="considerations-for-cudn_{context}"]
+= Best practices for ClusterUserDefinedNetwork CRs
+
+Before setting up a `ClusterUserDefinedNetwork` custom resource (CR), users should consider the following information:
+
+* A `ClusterUserDefinedNetwork` CR is intended for use by cluster administrators and should not be used by non-administrators. If used incorrectly, it might result in security issues with your deployment, cause disruptions, or break the cluster network. 
+
+* `ClusterUserDefinedNetwork` CRs should not select the `default` namespace. This can result in no isolation and, as a result, could introduce security risks to the cluster.
+
+* `ClusterUserDefinedNetwork` CRs should not select `openshift-*` namespaces.
+
+* {product-title} administrators should be aware that all namespaces of a cluster are selected when one of the following conditions are met:
+
+** The `matchLabels` selector is left empty.
+** The `matchExpressions` selector is left empty.
+** The `namespaceSelector` is initialized, but does not specify `matchExpressions` or `matchLabel`. For example: `namespaceSelector: {}`.
+
+* For primary networks, the namespace used for the `ClusterUserDefinedNetwork` CR must include the `k8s.ovn.org/primary-user-defined-network` label. This label cannot be updated, and can only be added when the namespace is created. The following conditions apply with the `k8s.ovn.org/primary-user-defined-network` namespace label:
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a pod is created, the pod attaches itself to the default network.
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a primary `ClusterUserDefinedNetwork` CR is created that matches the namespace, an error is reported and the network is not created.
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a primary `ClusterUserDefinedNetwork` CR already exists, a pod in the namespace is created and attached to the default network.
+
+** If the namespace _has_ the label, and a primary `ClusterUserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `ClusterUserDefinedNetwork` CR is created.
\ No newline at end of file
diff --git a/modules/nw-cudn-cr-ui.adoc b/modules/nw-cudn-cr-ui.adoc
new file mode 100644
index 000000000000..3efee58b5169
--- /dev/null
+++ b/modules/nw-cudn-cr-ui.adoc
@@ -0,0 +1,28 @@
+// Module included in the following assemblies:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-cudn-cr-ui_{context}"]
+= Creating a ClusterUserDefinedNetwork CR by using the web console
+
+You can create a `ClusterUserDefinedNetwork` custom resource (CR) in the {product-title} web console.
+
+.Prerequisites
+
+* You have access to the {product-title} web console as a user with `cluster-admin` permissions.
+* You have created a namespace and applied the `k8s.ovn.org/primary-user-defined-network` label.
+
+.Procedure
+
+. From the *Administrator* perspective, click *Networking* -> *UserDefinedNetworks*.
+
+. Click *ClusterUserDefinedNetwork*.
+
+. In the *Name* field, specify a name for the cluster-scoped UDN.
+
+. Specify a value in the *Subnet* field.
+
+. In the *Project(s) Match Labels* field, add the appropriate labels to select namespaces that the cluster UDN applies to.
+
+. Click *Create*. The cluster-scoped UDN serves as the default primary network for pods located in namespaces that contain the labels that you specified in step 5.
\ No newline at end of file
diff --git a/modules/nw-cudn-cr.adoc b/modules/nw-cudn-cr.adoc
new file mode 100644
index 000000000000..84e6e5f4abcc
--- /dev/null
+++ b/modules/nw-cudn-cr.adoc
@@ -0,0 +1,169 @@
+//module included in the following assembly:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-cudn-cr_{context}"]
+= Creating a ClusterUserDefinedNetwork CR by using the CLI
+
+The following procedure creates a `ClusterUserDefinedNetwork` custom resource (CR) by using the CLI. Based upon your use case, create your request using either the `cluster-layer-two-udn.yaml` example for a `Layer2` topology type or the `cluster-layer-three-udn.yaml` example for a `Layer3` topology type.
+
+[IMPORTANT]
+====
+* The `ClusterUserDefinedNetwork` CR is intended for use by cluster administrators and should not be used by non-administrators. If used incorrectly, it might result in security issues with your deployment, cause disruptions, or break the cluster network.
+* {VirtProductName} only supports the `Layer2` topology.
+====
+
+.Prerequisites
+
+* You have logged in as a user with `cluster-admin` privileges.
+
+.Procedure
+
+. Optional: For a `ClusterUserDefinedNetwork` CR that uses a primary network, create a namespace with the `k8s.ovn.org/primary-user-defined-network` label by entering the following command:
++
+[source,yaml]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: <cudn_namespace_name>      
+  labels:
+    k8s.ovn.org/primary-user-defined-network: ""
+EOF
+----
+
+. Create a request for either a `Layer2` or `Layer3` topology type cluster-wide user-defined network:
+
+.. Create a YAML file, such as `cluster-layer-two-udn.yaml`, to define your request for a `Layer2` topology as in the following example:
++
+[source, yaml]
+----
+apiVersion: k8s.ovn.org/v1
+kind: ClusterUserDefinedNetwork
+metadata:
+  name: <cudn_name> # <1>
+spec:
+  namespaceSelector: # <2>
+    matchLabels: # <3>
+    - "<example_namespace_one>":"" # <4>
+    - "<example_namespace_two>":"" # <4>
+  network: # <5>
+    topology: Layer2 # <6>
+    layer2: # <7>
+      role: Primary # <8>
+      subnets:
+        - "2001:db8::/64"
+        - "10.100.0.0/16" # <9>
+----
+<1> Name of your `ClusterUserDefinedNetwork` CR.
+<2> A label query over the set of namespaces that the cluster UDN CR applies to. Uses the standard Kubernetes `MatchLabel` selector. Must not point to `default` or `openshift-*` namespaces.
+<3> Uses the `matchLabels` selector type, where terms are evaluated with an `AND` relationship. 
+<4> Because the `matchLabels` selector type is used, provisions namespaces matching both `<example_namespace_one>` _and_ `<example_namespace_two>`.
+<5> Describes the network configuration.
+<6> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer2` topology type creates one logical switch that is shared by all nodes.
+<7> This field specifies the topology configuration. It can be `layer2` or `layer3`.
+<8> Specifies `Primary` or `Secondary`. `Primary` is the only `role` specification supported in {product-version}.
+<9> For `Layer2` topology types the following specifies config details for the `subnet` field:
++
+* The subnets field is optional.
+* The subnets field is of type `string` and accepts standard CIDR formats for both IPv4 and IPv6.
+* The subnets field accepts one or two items. For two items, they must be of a different family. For example, subnets values of `10.100.0.0/16` and `2001:db8::/64`.
+* `Layer2` subnets can be omitted. If omitted, users must configure static IP addresses for the pods. As a consequence, port security only prevents MAC spoofing. For more information, see "Configuring pods with a static IP address".
++
+.. Create a YAML file, such as `cluster-layer-three-udn.yaml`, to define your request for a `Layer3` topology as in the following example:
++
+[source, yaml]
+----
+apiVersion: k8s.ovn.org/v1
+kind: ClusterUserDefinedNetwork
+metadata:
+  name: <cudn_name> # <1>
+spec:
+  namespaceSelector: # <2>
+    matchExpressions: # <3>
+    - key: kubernetes.io/metadata.name # <4>
+      operator: In # <5>
+      values: ["<example_namespace_one>", "<example_namespace_two>"] # <6>
+  network: # <7>
+    topology: Layer3 # <8>
+    layer3: # <9>
+      role: Primary # <10>
+      subnets: # <11>
+        - cidr: 10.100.0.0/16
+          hostSubnet: 24
+----
+<1> Name of your `ClusterUserDefinedNetwork` CR.
+<2> A label query over the set of namespaces that the cluster UDN applies to. Uses the standard Kubernetes `MatchLabel` selector. Must not point to `default` or `openshift-*` namespaces.
+<3> Uses the `matchExpressions` selector type, where terms are evaluated with an `OR` relationship. 
+<4> Specifies the label key to match.
+<5> Specifies the operator. Valid values include: `In`, `NotIn`, `Exists`, and `DoesNotExist`.
+<6> Because the `matchExpressions` type is used, provisions namespaces matching either `<example_namespace_one>` or `<example_namespace_two>`.
+<7> Describes the network configuration.
+<8> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer3` topology type creates a layer 2 segment per node, each with a different subnet. Layer 3 routing is used to interconnect node subnets.
+<9> This field specifies the topology configuration. Valid values are `layer2` or `layer3`.
+<10> Specifies a `Primary` or `Secondary` role. `Primary` is the only `role` specification supported in {product-version}.
+<11> For `Layer3` topology types the following specifies config details for the `subnet` field:
++
+* The `subnets` field is mandatory.
+* The type for the `subnets` field is `cidr` and `hostSubnet`:
+** `cidr` is the cluster subnet and accepts a string value.
+** `hostSubnet` specifies the nodes subnet prefix that the cluster subnet is split to.
+** For IPv6, only a `/64` length is supported for `hostSubnet`.
++
+. Apply your request by running the following command:
++
+[source,terminal]
+----
+$ oc create --validate=true -f <example_cluster_udn>.yaml
+----
++
+Where `<example_cluster_udn>.yaml` is the name of your `Layer2` or `Layer3` configuration file.
+
+. Verify that your request is successful by running the following command:
++
+[source,terminal]
+----
+$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
+----
++
+Where `<cudn_name>` is the name you created of your cluster-wide user-defined network.
++
+.Example output
+[source,yaml]
+----
+apiVersion: k8s.ovn.org/v1
+kind: ClusterUserDefinedNetwork
+metadata:
+  creationTimestamp: "2024-12-05T15:53:00Z"
+  finalizers:
+  - k8s.ovn.org/user-defined-network-protection
+  generation: 1
+  name: my-cudn
+  resourceVersion: "47985"
+  uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
+spec:
+  namespaceSelector:
+    matchExpressions:
+    - key: custom.network.selector
+      operator: In
+      values:
+      - example-namespace-1
+      - example-namespace-2
+      - example-namespace-3
+  network:
+    layer3:
+      role: Primary
+      subnets:
+      - cidr: 10.100.0.0/16
+    topology: Layer3
+status:
+  conditions:
+  - lastTransitionTime: "2024-11-19T16:46:34Z"
+    message: 'NetworkAttachmentDefinition has been created in following namespaces:
+      [example-namespace-1, example-namespace-2, example-namespace-3]'
+    reason: NetworkAttachmentDefinitionReady
+    status: "True"
+    type: NetworkCreated
+----
diff --git a/modules/nw-disable-http2.adoc b/modules/nw-disable-http2.adoc
new file mode 100644
index 000000000000..1912ec94c62d
--- /dev/null
+++ b/modules/nw-disable-http2.adoc
@@ -0,0 +1,73 @@
+// Module included in the following assemblies:
+//
+// * networking/ingress-operator.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-disable-http2_{context}"]
+<<<<<<< HEAD
+= Disabling HTTP/2
+
+You can disable HTTP/2 on a specific Ingress Controller, or you can disable HTTP/2 for the entire cluster.
+
+.Procedure
+
+* To disable HTTP/2 on a specific Ingress Controller, enter the `oc annotate` command:
+=======
+= Disable HTTP/2 on an Ingress Controller
+
+== Disable HTTP/2 on a single Ingress Controller
+
+* To disable HTTP/2 on an Ingress Controller, enter the `oc annotate` command:
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
++
+[source,terminal]
+----
+$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false <1>
+----
+<<<<<<< HEAD
++
+<1> Replace `<ingresscontroller_name>` with the name of an Ingress Controller to disable HTTP/2.
+=======
+<1> This command adds the annotation `ingress.operator.openshift.io/default-enable-http2=false` to the specified Ingress Controller, disabling HTTP/2. Replace `<ingresscontroller_name>` with the actual name of the Ingress Controller to annotate.
++
+Replace `<ingresscontroller_name>` with the name of the Ingress Controller to annotate.
+
+== Disable HTTP/2 on the entire cluster
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+
+* To disable HTTP/2 for the entire cluster, enter the `oc annotate` command:
++
+[source,terminal]
+----
+<<<<<<< HEAD
+$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
+----
+
+[TIP]
+====
+Alternatively, you can apply the following YAML code to disable HTTP/2:
+=======
+$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false <2>
+----
+<2> This command adds the annotation `ingress.operator.openshift.io/default-enable-http2=false` to the cluster-wide Ingress configuration, disabling HTTP/2 for the entire cluster.
++
+[TIP]
+====
+You can alternatively apply the following YAML to add the annotation:
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Ingress
+metadata:
+  name: cluster
+  annotations:
+<<<<<<< HEAD
+    ingress.operator.openshift.io/default-enable-http2: "false"
+----
+=======
+    ingress.operator.openshift.io/default-enable-http2: "false" <3>
+----
+<3> This YAML configuration provides an alternative method to add the annotation `ingress.operator.openshift.io/default-enable-http2: "false"` to the cluster-wide Ingress configuration, disabling HTTP/2 for the entire cluster.
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+====
\ No newline at end of file
diff --git a/modules/nw-dual-stack-convert-back-single-stack.adoc b/modules/nw-dual-stack-convert-back-single-stack.adoc
index d14bf195b932..f1a5db901ff7 100644
--- a/modules/nw-dual-stack-convert-back-single-stack.adoc
+++ b/modules/nw-dual-stack-convert-back-single-stack.adoc
@@ -2,7 +2,12 @@
 [id="nw-dual-stack-convert-back-single-stack_{context}"]
 = Converting to a single-stack cluster network
 
-As a cluster administrator, you can convert your dual-stack cluster network to a single-stack cluster network.
+As a cluster administrator, you can convert your dual-stack cluster network to a single-stack cluster network. 
+
+[IMPORTANT]
+====
+If you originally converted your IPv4 single-stack cluster network to a dual-stack cluster, you can convert only back to the IPv4 single-stack cluster and not an IPv6 single-stack cluster network. The same restriction applies for converting back to an IPv6 single-stack cluster network. 
+====
 
 .Prerequisites
 
@@ -14,13 +19,12 @@ As a cluster administrator, you can convert your dual-stack cluster network to a
 
 .Procedure
 
-. Edit the `networks.config.openshift.io` custom resource (CR) by running the
-following command:
+. Edit the `networks.config.openshift.io` custom resource (CR) by running the following command:
 +
 [source,terminal]
 ----
 $ oc edit networks.config.openshift.io
 ----
 
-. Remove the IPv6 specific configuration that you have added to the `cidr` and `hostPrefix` fields in the previous procedure.
+. Remove the IPv4 or IPv6 configuration that you added to the `cidr` and the `hostPrefix` parameters from completing the "Converting to a dual-stack cluster network " procedure steps.
 
diff --git a/modules/nw-dual-stack-convert.adoc b/modules/nw-dual-stack-convert.adoc
index 0b07b0bec5cc..cf85e6c37e1b 100644
--- a/modules/nw-dual-stack-convert.adoc
+++ b/modules/nw-dual-stack-convert.adoc
@@ -56,7 +56,7 @@ If you already upgraded your cluster to {product-title} 4.16 or later and you ne
   path: /spec/serviceNetwork/-
   value: fd02::/112 <2>
 ----
-<1> Specify an object with the `cidr` and `hostPrefix` fields. The host prefix must be `64` or greater. The IPv6 Classless Inter-Domain Routing (CIDR) prefix must be large enough to accommodate the specified host prefix.
+<1> Specify an object with the `cidr` and `hostPrefix` parameters. The host prefix must be `64` or greater. The IPv6 Classless Inter-Domain Routing (CIDR) prefix must be large enough to accommodate the specified host prefix.
 <2> Specify an IPv6 CIDR with a prefix of `112`. Kubernetes uses only the lowest 16 bits. For a prefix of `112`, IP addresses are assigned from `112` to `128` bits.
 
 . Patch the cluster network configuration by entering the following command in your CLI:
diff --git a/modules/nw-egress-service-cr.adoc b/modules/nw-egress-service-cr.adoc
index d2e2f956b50a..7e2d27f5e781 100644
--- a/modules/nw-egress-service-cr.adoc
+++ b/modules/nw-egress-service-cr.adoc
@@ -26,7 +26,7 @@ spec:
 <2> Specify the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the load-balancer service that you want to modify. The egress service is namespace-scoped.
 <3> Specify the source IP address of egress traffic for pods behind a service. Valid values are `LoadBalancerIP` or `Network`. Use the `LoadBalancerIP` value to assign the `LoadBalancer` service ingress IP address as the source IP address for egress traffic. Specify `Network` to assign the network interface IP address as the source IP address for egress traffic.
 <4> Optional: If you use the `LoadBalancerIP` value for the `sourceIPBy` specification, a single node handles the `LoadBalancer` service traffic. Use the `nodeSelector` field to limit which node can be assigned this task. When a node is selected to handle the service traffic, OVN-Kubernetes labels the node in the following format: `egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""`. When the `nodeSelector` field is not specified, any node can manage the `LoadBalancer` service traffic.
-<5> Optional: Specify the routing table for egress traffic. If you do not include the `network` specification, the egress service uses the default host network.
+<5> Optional: Specify the routing table ID for egress traffic. Ensure that the value matches the `route-table-id` ID defined in the `NodeNetworkConfigurationPolicy` resource. If you do not include the `network` specification, the egress service uses the default host network.
 
 .Example egress service specification
 [source,yaml]
diff --git a/modules/nw-egress-service-ovn.adoc b/modules/nw-egress-service-ovn.adoc
index cd51a56189c4..5a63327107e1 100644
--- a/modules/nw-egress-service-ovn.adoc
+++ b/modules/nw-egress-service-ovn.adoc
@@ -15,6 +15,7 @@ The following example configures the egress traffic to have the same source IP a
 * Install the OpenShift CLI (`oc`).
 * Log in as a user with `cluster-admin` privileges.
 * You configured MetalLB `BGPPeer` resources.
+* You use OVN-Kubernetes configured with the `gatewayConfig.routingViaHost` specification set to `true` only.
 
 .Procedure
 
@@ -53,7 +54,7 @@ metadata:
   name: example-service
   namespace: example-namespace
   annotations:
-    metallb.universe.tf/address-pool: example-pool <1>
+    metallb.io/address-pool: example-pool <1>
 spec:
   selector:
     app: example
@@ -105,7 +106,7 @@ metadata:
 spec:
   ipAddressPools:
   - example-pool
-  nodeSelector:
+  nodeSelectors:
   - matchLabels:
       egress-service.k8s.ovn.org/example-namespace-example-service: "" <1>
 ----
diff --git a/modules/nw-egressnetworkpolicy-object.adoc b/modules/nw-egressnetworkpolicy-object.adoc
index af1e2e18a23e..080333f449b2 100644
--- a/modules/nw-egressnetworkpolicy-object.adoc
+++ b/modules/nw-egressnetworkpolicy-object.adoc
@@ -95,7 +95,7 @@ spec:
 <1> A collection of egress firewall policy rule objects.
 
 ifdef::ovn[]
-The following example defines a policy rule that denies traffic to the host at the `172.16.1.1` IP address, if the traffic is using either the TCP protocol and destination port `80` or any protocol and destination port `443`.
+The following example defines a policy rule that denies traffic to the host at the `172.16.1.1/32` IP address, if the traffic is using either the TCP protocol and destination port `80` or any protocol and destination port `443`.
 
 [source,yaml,subs="attributes+"]
 ----
@@ -107,7 +107,7 @@ spec:
   egress:
   - type: Deny
     to:
-      cidrSelector: 172.16.1.1
+      cidrSelector: 172.16.1.1/32
     ports:
     - port: 80
       protocol: TCP
diff --git a/modules/nw-enable-http2.adoc b/modules/nw-enable-http2.adoc
new file mode 100644
index 000000000000..b679cebe144b
--- /dev/null
+++ b/modules/nw-enable-http2.adoc
@@ -0,0 +1,75 @@
+// Module included in the following assemblies:
+//
+// * networking/ingress-operator.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-enable-http2_{context}"]
+<<<<<<< HEAD
+= Enabling HTTP/2
+
+You can enable HTTP/2 on a specific Ingress Controller, or you can enable HTTP/2 for the entire cluster.
+
+.Procedure
+
+* To enable HTTP/2 on a specific Ingress Controller, enter the `oc annotate` command:
+=======
+= Enable HTTP/2 on an Ingress Controller
+
+== Enable HTTP/2 on a single Ingress Controller
+
+.Procedure
+
+* To enable HTTP/2 on an Ingress Controller, enter the `oc annotate` command:
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
++
+[source,terminal]
+----
+$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true <1>
+----
+<<<<<<< HEAD
++
+<1> Replace `<ingresscontroller_name>` with the name of an Ingress Controller to enable HTTP/2.
+=======
+<1> This command adds the annotation `ingress.operator.openshift.io/default-enable-http2=true` to the specified Ingress Controller, enabling HTTP/2. Replace `<ingresscontroller_name>` with the actual name of the Ingress Controller to annotate.
++
+Replace `<ingresscontroller_name>` with the name of the Ingress Controller to annotate.
+
+== Enable HTTP/2 on the entire cluster
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+
+* To enable HTTP/2 for the entire cluster, enter the `oc annotate` command:
++
+[source,terminal]
+----
+<<<<<<< HEAD
+$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
+----
+
+[TIP]
+====
+Alternatively, you can apply the following YAML code to enable HTTP/2:
+=======
+$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true <2>
+----
+<2> This command adds the annotation `ingress.operator.openshift.io/default-enable-http2=true` to the cluster-wide Ingress configuration, enabling HTTP/2 for the entire cluster.
++
+[TIP]
+====
+You can alternatively apply the following YAML to add the annotation:
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Ingress
+metadata:
+  name: cluster
+  annotations:
+<<<<<<< HEAD
+    ingress.operator.openshift.io/default-enable-http2: "true"
+----
+=======
+    ingress.operator.openshift.io/default-enable-http2: "true" <3>
+----
+<3> This YAML configuration provides an alternative method to add the annotation `ingress.operator.openshift.io/default-enable-http2: "true"` to the cluster-wide Ingress configuration, enabling HTTP/2 for the entire cluster.
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+====
\ No newline at end of file
diff --git a/modules/nw-enabling-hsts-per-route.adoc b/modules/nw-enabling-hsts-per-route.adoc
index ba9d069ce890..d84ff7342924 100644
--- a/modules/nw-enabling-hsts-per-route.adoc
+++ b/modules/nw-enabling-hsts-per-route.adoc
@@ -19,19 +19,14 @@ endif::microshift[]
 
 .Procedure
 
-* To enable HSTS on a route, add the `haproxy.router.openshift.io/hsts_header` value to the edge-terminated or re-encrypt route. You can use the `oc annotate` tool to do this by running the following command:
+* To enable HSTS on a route, add the `haproxy.router.openshift.io/hsts_header` value to the edge-terminated or re-encrypt route. You can use the `oc annotate` tool to do this by running the following command. To properly run the command, ensure that the semicolon (`;`) in the `haproxy.router.openshift.io/hsts_header` route annotation is also surrounded by double quotation marks (`""`).
 +
+.Example `annotate` command that sets the maximum age to `31536000` ms (approximetly 8.5 hours)
 [source,terminal]
 ----
-$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ <1>
+$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
 includeSubDomains;preload"
 ----
-<1> In this example, the maximum age is set to `31536000` ms, which is approximately 8.5 hours.
-+
-[NOTE]
-====
-In this example, the equal sign (`=`) is in quotes. This is required to properly execute the annotate command.
-====
 +
 .Example route configured with an annotation
 [source,yaml]
@@ -41,13 +36,14 @@ kind: Route
 metadata:
   annotations:
     haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload <1> <2> <3>
-...
+# ...
 spec:
   host: def.abc.com
   tls:
     termination: "reencrypt"
     ...
   wildcardPolicy: "Subdomain"
+# ...
 ----
 <1> Required. `max-age` measures the length of time, in seconds, that the HSTS policy is in effect. If set to `0`, it negates the policy.
 <2> Optional. When included, `includeSubDomains` tells the client
diff --git a/modules/nw-externalip-about.adoc b/modules/nw-externalip-about.adoc
index 85c2b01ff210..9031b637d080 100644
--- a/modules/nw-externalip-about.adoc
+++ b/modules/nw-externalip-about.adoc
@@ -6,174 +6,31 @@
 [id="nw-externalip-about_{context}"]
 = About ExternalIP
 
-For non-cloud environments, {product-title} supports the assignment of external IP addresses to a `Service` object `spec.externalIPs[]` field through the *ExternalIP* facility.
-By setting this field, {product-title} assigns an additional virtual IP address to the service. The IP address can be outside the service network defined for the cluster.
-A service configured with an ExternalIP functions similarly to a service with `type=NodePort`, allowing you to direct traffic to a local node for load balancing.
+For non-cloud environments, {product-title} supports the use of the ExternalIP facility to specify external IP addresses in the `spec.externalIPs[]` parameter of the `Service` object. A service configured with an ExternalIP functions similarly to a service with `type=NodePort`, whereby you traffic directs to a local node for load balancing.
 
-You must configure your networking infrastructure to ensure that the external IP address blocks that you define are routed to the cluster. As a result, the IP address is not configured in the network interfaces from nodes. To handle the traffic, you must configure the routing and access to the external IP by using a method such as static Address Resolution Protocol (ARP) entries.
-
-{product-title} extends the ExternalIP functionality in Kubernetes by adding the following capabilities:
-
-- Restrictions on the use of external IP addresses by users through a configurable policy
-- Allocation of an external IP address automatically to a service upon request
-
-[WARNING]
+[IMPORTANT]
 ====
-Disabled by default, use of ExternalIP functionality can be a security risk, because in-cluster traffic to an external IP address is directed to that service.
-This could allow cluster users to intercept sensitive traffic destined for external resources.
+For cloud environments, use the load balancer services for automatic deployment of a cloud load balancer to target the endpoints of a service.
 ====
 
-[IMPORTANT]
+After you specify a value for the parameter, {product-title} assigns an additional virtual IP address to the service. The IP address can exist outside of the service network that you defined for your cluster.
+
+[WARNING]
 ====
-This feature is supported only in non-cloud deployments.
-For cloud deployments, use the load balancer services for automatic deployment of a cloud load balancer to target the endpoints of a service.
+Because ExternalIP is disabled by default, enabling the ExternalIP functionality might introduce security risks for the service, because in-cluster traffic to an external IP address is directed to that service. This configuration means that cluster users could intercept sensitive traffic destined for external resources.
 ====
 
 You can use either a MetalLB implementation or an IP failover deployment to attach an ExternalIP resource to a service in the following ways:
 
 Automatic assignment of an external IP::
-{product-title} automatically assigns an IP address from the `autoAssignCIDRs` CIDR block to the `spec.externalIPs[]` array when you create a `Service` object with `spec.type=LoadBalancer` set.
-In this case, {product-title} implements a non-cloud version of the load balancer service type and assigns IP addresses to the services.
-Automatic assignment is disabled by default and must be configured by a cluster administrator as described in the following section.
+{product-title} automatically assigns an IP address from the `autoAssignCIDRs` CIDR block to the `spec.externalIPs[]` array when you create a `Service` object with `spec.type=LoadBalancer` set. For this configuration, {product-title} implements a cloud version of the load balancer service type and assigns IP addresses to the services. Automatic assignment is disabled by default and must be configured by a cluster administrator as described in the "Configuration for ExternalIP" section.
 
 Manual assignment of an external IP::
 {product-title} uses the IP addresses assigned to the `spec.externalIPs[]` array when you create a `Service` object. You cannot specify an IP address that is already in use by another service.
 
-[id="configuration-externalip_{context}"]
-== Configuration for ExternalIP
-
-Use of an external IP address in {product-title} is governed by the following fields in the `Network.config.openshift.io` CR named `cluster`:
-
-* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This can be simpler than having to manage the port space of a limited number of shared IP addresses when manually assigning ExternalIPs to services. If automatic assignment is enabled, a `Service` object with `spec.type=LoadBalancer` is allocated an external IP address.
-* `spec.externalIP.policy` defines the permissible IP address blocks when manually specifying an IP address. {product-title} does not apply policy rules to IP address blocks defined by `spec.externalIP.autoAssignCIDRs`.
-
-If routed correctly, external traffic from the configured external IP address block can reach service endpoints through any TCP or UDP port that the service exposes.
-
-[IMPORTANT]
-====
-As a cluster administrator, you must configure routing to externalIPs. You must also ensure that the IP address block you assign terminates at one or more nodes in your cluster. For more information, see link:https://kubernetes.io/docs/concepts/services-networking/service/#external-ips[*Kubernetes External IPs*].
-====
-
-{product-title} supports both the automatic and manual assignment of IP
-addresses, and each address is guaranteed to be assigned to a maximum of one
-service. This ensures that each service can expose its chosen ports regardless
-of the ports exposed by other services.
+After using either the MetalLB implementation or an IP failover deployment to host external IP address blocks, you must configure your networking infrastructure to ensure that the external IP address blocks are routed to your cluster. This configuration means that the IP address is not configured in the network interfaces from nodes. To handle the traffic, you must configure the routing and access to the external IP by using a method, such as static Address Resolution Protocol (ARP) entries.
 
-[NOTE]
-====
-To use IP address blocks defined by `autoAssignCIDRs` in {product-title}, you must configure the necessary IP address assignment and routing for your host network.
-====
-
-The following YAML describes a service with an external IP address configured:
-
-.Example `Service` object with `spec.externalIPs[]` set
-[source,yaml]
-----
-apiVersion: v1
-kind: Service
-metadata:
-  name: http-service
-spec:
-  clusterIP: 172.30.163.110
-  externalIPs:
-  - 192.168.132.253
-  externalTrafficPolicy: Cluster
-  ports:
-  - name: highport
-    nodePort: 31903
-    port: 30102
-    protocol: TCP
-    targetPort: 30102
-  selector:
-    app: web
-  sessionAffinity: None
-  type: LoadBalancer
-status:
-  loadBalancer:
-    ingress:
-    - ip: 192.168.132.253
-----
-
-[id="restrictions-on-ip-assignment_{context}"]
-== Restrictions on the assignment of an external IP address
-
-As a cluster administrator, you can specify IP address blocks to allow and to reject.
-
-Restrictions apply only to users without `cluster-admin` privileges. A cluster administrator can always set the service `spec.externalIPs[]` field to any IP address.
-
-You configure IP address policy with a `policy` object defined by specifying the `spec.ExternalIP.policy` field.
-The policy object has the following shape:
-
-[source,json]
-----
-{
-  "policy": {
-    "allowedCIDRs": [],
-    "rejectedCIDRs": []
-  }
-}
-----
-
-When configuring policy restrictions, the following rules apply:
-
-- If `policy={}` is set, then creating a `Service` object with `spec.ExternalIPs[]` set will fail. This is the default for {product-title}. The behavior when `policy=null` is set is identical.
-- If `policy` is set and either `policy.allowedCIDRs[]` or `policy.rejectedCIDRs[]` is set, the following rules apply:
-
-* If `allowedCIDRs[]` and `rejectedCIDRs[]` are both set, then `rejectedCIDRs[]` has precedence over `allowedCIDRs[]`.
-* If `allowedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are allowed.
-* If `rejectedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are not rejected.
-
-[id="example-policy-objects_{context}"]
-== Example policy objects
-
-The examples that follow demonstrate several different policy configurations.
-
-- In the following example, the policy prevents {product-title} from creating any service with an external IP address specified:
-+
-.Example policy to reject any value specified for `Service` object `spec.externalIPs[]`
-[source,yaml]
-----
-apiVersion: config.openshift.io/v1
-kind: Network
-metadata:
-  name: cluster
-spec:
-  externalIP:
-    policy: {}
-  ...
-----
-
-- In the following example, both the `allowedCIDRs` and `rejectedCIDRs` fields are set.
-+
-.Example policy that includes both allowed and rejected CIDR blocks
-[source,yaml]
-----
-apiVersion: config.openshift.io/v1
-kind: Network
-metadata:
-  name: cluster
-spec:
-  externalIP:
-    policy:
-      allowedCIDRs:
-      - 172.16.66.10/23
-      rejectedCIDRs:
-      - 172.16.66.10/24
-  ...
-----
+{product-title} extends the ExternalIP functionality in Kubernetes by adding the following capabilities:
 
-- In the following example, `policy` is set to `null`.
-If set to `null`, when inspecting the configuration object by entering `oc get networks.config.openshift.io -o yaml`, the `policy` field will not appear in the output.
-+
-.Example policy to allow any value specified for `Service` object `spec.externalIPs[]`
-[source,yaml]
-----
-apiVersion: config.openshift.io/v1
-kind: Network
-metadata:
-  name: cluster
-spec:
-  externalIP:
-    policy: null
-  ...
-----
+- Restrictions on the use of external IP addresses by users through a configurable policy
+- Allocation of an external IP address automatically to a service upon request
diff --git a/modules/nw-http2-haproxy.adoc b/modules/nw-http2-haproxy.adoc
index b501451fa8b8..68a872ddece2 100644
--- a/modules/nw-http2-haproxy.adoc
+++ b/modules/nw-http2-haproxy.adoc
@@ -2,22 +2,53 @@
 //
 // * networking/ingress-operator.adoc
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="nw-http2-haproxy_{context}"]
+<<<<<<< HEAD
+<<<<<<< HEAD
+= Enable or disable HTTP/2 on Ingress Controllers
+
+You can enable or disable transparent end-to-end HTTP/2 connectivity in HAProxy. Application owners can use HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more.
+=======
+= Enabling and Disabling HTTP/2 Ingress Connectivity
+
+You can enable or disable transparent end-to-end HTTP/2 connectivity in HAProxy. This allows application owners to make use of HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more.
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+=======
 = Enabling HTTP/2 Ingress connectivity
 
 You can enable transparent end-to-end HTTP/2 connectivity in HAProxy. It allows application owners to make use of HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more.
+>>>>>>> 788a488821 (fixing a mistake)
 
 You can enable HTTP/2 connectivity for an individual Ingress Controller or for the entire cluster.
 
-To enable the use of HTTP/2 for the connection from the client to HAProxy, a route must specify a custom certificate. A route that uses the default certificate cannot use HTTP/2. This restriction is necessary to avoid problems from connection coalescing, where the client re-uses a connection for different routes that use the same certificate.
+[NOTE]
+====
+If you enable or disable HTTP/2 connectivity for an individual Ingress Controller and for the entire cluster, the HTTP/2 configuration for the Ingress Controller takes precedence over the HTTP/2 configuration for the cluster. 
+====
+
+To enable the use of HTTP/2 for a connection from the client to an HAProxy instance, a route must specify a custom certificate. A route that uses the default certificate cannot use HTTP/2. This restriction is necessary to avoid problems from connection coalescing, where the client re-uses a connection for different routes that use the same certificate.
+
+Consider the following use cases for an HTTP/2 connection for each route type: 
 
-The connection from HAProxy to the application pod can use HTTP/2 only for re-encrypt routes and not for edge-terminated or insecure routes. This restriction is because HAProxy uses Application-Level Protocol Negotiation (ALPN), which is a TLS extension, to negotiate the use of HTTP/2 with the back-end. The implication is that end-to-end HTTP/2 is possible with passthrough and re-encrypt and not with insecure or edge-terminated routes.
+* For a re-encrypt route, the connection from HAProxy to the application pod can use HTTP/2 if the application supports using Application-Level Protocol Negotiation (ALPN) to negotiate HTTP/2 with HAProxy. You cannot use HTTP/2 with a re-encrypt route unless the Ingress Controller has HTTP/2 enabled.
+* For a passthrough route, the connection can use HTTP/2 if the application supports using ALPN to negotiate HTTP/2 with the client. You can use HTTP/2 with a passthrough route if the Ingress Controller has HTTP/2 enabled or disabled.
+* For an edge-terminated secure route, the connection uses HTTP/2 if the service specifies only `appProtocol: kubernetes.io/h2c`. You can use HTTP/2 with an edge-terminated secure route if the Ingress Controller has HTTP/2 enabled or disabled.
+* For an insecure route, the connection uses HTTP/2 if the service specifies only `appProtocol: kubernetes.io/h2c`. You can use HTTP/2 with an insecure route if the Ingress Controller has HTTP/2 enabled or disabled.
 
 [IMPORTANT]
 ====
+<<<<<<< HEAD
+For non-passthrough routes, the Ingress Controller negotiates its connection to the application independently of the connection from the client. This means a client might connect to the Ingress Controller and negotiate HTTP/1.1. The Ingress Controller might then connect to the application, negotiate HTTP/2, and forward the request from the client HTTP/1.1 connection by using the HTTP/2 connection to the application. 
+
+This sequence of events causes an issue if the client subsequently tries to upgrade its connection from HTTP/1.1 to the WebSocket protocol. Consider that if you have an application that is intending to accept WebSocket connections, and the application attempts to allow for HTTP/2 protocol negotiation, the client fails any attempt to upgrade to the WebSocket protocol.
+====
+=======
 For non-passthrough routes, the Ingress Controller negotiates its connection to the application independently of the connection from the client. This means a client may connect to the Ingress Controller and negotiate HTTP/1.1, and the Ingress Controller may then connect to the application, negotiate HTTP/2, and forward the request from the client HTTP/1.1 connection using the HTTP/2 connection to the application. This poses a problem if the client subsequently tries to upgrade its connection from HTTP/1.1 to the WebSocket protocol, because the Ingress Controller cannot forward WebSocket to HTTP/2 and cannot upgrade its HTTP/2 connection to WebSocket. Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol.
 ====
+<<<<<<< HEAD
+>>>>>>> 2d40d24744 (ocpbugs18820 Document how to disable HTTP2)
+=======
 
 .Procedure
 
@@ -54,3 +85,7 @@ metadata:
     ingress.operator.openshift.io/default-enable-http2: "true"
 ----
 ====
+<<<<<<< HEAD
+>>>>>>> 788a488821 (fixing a mistake)
+=======
+>>>>>>> e32922f821 (fixing spacing)
diff --git a/modules/nw-ingress-aws-static-eip-nlb-configuration.adoc b/modules/nw-ingress-aws-static-eip-nlb-configuration.adoc
new file mode 100644
index 000000000000..e68595ee3c50
--- /dev/null
+++ b/modules/nw-ingress-aws-static-eip-nlb-configuration.adoc
@@ -0,0 +1,74 @@
+// Modules included in the following assemblies:
+//
+// * networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-aws.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-ingress-aws-static-eip-nlb-configuration_{context}"]
+= Configuring AWS Elastic IP (EIP) addresses for a Network Load Balancer (NLB)
+
+You can specify static IPs, otherwise known as elastic IPs, for your network load balancer (NLB) in the Ingress Controller. This is useful in situations where you want to configure appropriate firewall rules for your cluster network.
+
+.Prerequisites
+* You must have an installed AWS cluster.
+* You must know the names or IDs of the subnets to which you intend to map your `IngressController`.
+
+.Procedure
+
+. Create a YAML file that contains the following content:
++
+.`sample-ingress.yaml`
+[source,yaml]
+----
+apiVersion: operator.openshift.io/v1
+kind: IngressController
+metadata:
+  namespace: openshift-ingress-operator
+  name: <name> <1>
+spec:
+  domain: <domain> <2>
+  endpointPublishingStrategy:
+    loadBalancer:
+      scope: External <3>
+      type: LoadBalancerService
+      providerParameters:
+        type: AWS
+        aws:
+          type: NLB
+          networkLoadBalancer:
+            subnets: <4>
+              ids:
+              - <subnet_ID>
+              names:
+              - <subnet_A>
+              - <subnet_B>
+            eipAllocations: <5>
+            - <eipalloc_A>
+            - <eipalloc_B>
+            - <eipalloc_C>
+----
+<1> Replace the `<name>` placeholder with a name for the Ingress Controller.
+<2> Replace the `<domain>` placeholder with the DNS name serviced by the Ingress Controller.
+<3> The scope must be set to the value `External` and be Internet-facing in order to allocate EIPs.
+<4> Specify the IDs and names for your subnets. The total number of IDs and names must be equal to your allocated EIPs.
+<5> Specify the EIP addresses.
++
+[IMPORTANT]
+====
+You can specify a maximum of one subnet per availability zone. Only provide public subnets for external Ingress Controllers. You can associate one EIP address per subnet.
+====
+
+. Save and apply the CR file by entering the following command:
++
+[source,terminal]
+----
+$  oc apply -f sample-ingress.yaml
+----
+
+.Verification
+
+. Confirm the load balancer was provisioned successfully by checking the `IngressController` conditions by running the following command:
++
+[source,terminal]
+----
+$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC
+----
diff --git a/modules/nw-ingress-reencrypt-route-custom-cert.adoc b/modules/nw-ingress-reencrypt-route-custom-cert.adoc
index a9b11ff079d3..0c065a84d43c 100644
--- a/modules/nw-ingress-reencrypt-route-custom-cert.adoc
+++ b/modules/nw-ingress-reencrypt-route-custom-cert.adoc
@@ -17,6 +17,26 @@ The `route.openshift.io/destination-ca-certificate-secret` annotation can be use
 
 .Procedure
 
+. Create a secret for the destination CA certificate by entering the following command:
++
+[source,terminal]
+----
+$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>
+----
++
+For example:
++
+[source,terminal]
+----
+$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt
+----
++
+.Example output
+[source,terminal]
+----
+secret/dest-ca-cert created
+----
+
 . Add the `route.openshift.io/destination-ca-certificate-secret` to the Ingress annotations:
 +
 [source,yaml]
diff --git a/modules/nw-ingress-sharding.adoc b/modules/nw-ingress-sharding.adoc
index 0f06fc1362d7..7308eb2017e5 100644
--- a/modules/nw-ingress-sharding.adoc
+++ b/modules/nw-ingress-sharding.adoc
@@ -6,25 +6,35 @@
 [id="nw-ingress-sharding_{context}"]
 = Ingress Controller sharding
 
-You can use Ingress sharding, also known as router sharding, to distribute a set of routes across multiple routers by adding labels to routes, namespaces, or both. The Ingress Controller uses a corresponding set of selectors to admit only the routes that have a specified label. Each Ingress shard comprises the routes that are filtered using a given selection expression.
+You can use Ingress sharding, also known as router sharding, to distribute a set of routes across multiple routers by adding labels to routes, namespaces, or both. The Ingress Controller uses a corresponding set of selectors to admit only the routes that have a specified label. Each Ingress shard comprises the routes that are filtered by using a given selection expression.
 
 As the primary mechanism for traffic to enter the cluster, the demands on the Ingress Controller can be significant. As a cluster administrator, you can shard the routes to:
 
-* Balance Ingress Controllers, or routers, with several routes to speed up responses to changes.
-* Allocate certain routes to have different reliability guarantees than other routes.
+* Balance Ingress Controllers, or routers, with several routes to accelerate responses to changes.
+* Assign certain routes to have different reliability guarantees than other routes.
 * Allow certain Ingress Controllers to have different policies defined.
 * Allow only specific routes to use additional features.
 * Expose different routes on different addresses so that internal and external users can see different routes, for example.
-* Transfer traffic from one version of an application to another during a blue green deployment.
+* Transfer traffic from one version of an application to another during a blue-green deployment.
 
-When Ingress Controllers are sharded, a given route is admitted to zero or more Ingress Controllers in the group. A route's status describes whether an Ingress Controller has admitted it or not. An Ingress Controller will only admit a route if it is unique to its shard.
+When Ingress Controllers are sharded, a given route is admitted to zero or more Ingress Controllers in the group. The status of a route describes whether an Ingress Controller has admitted the route. An Ingress Controller only admits a route if the route is unique to a shard.
 
-An Ingress Controller can use three sharding methods:
+With sharding, you can distribute subsets of routes over multiple Ingress Controllers. These subsets can be nonoverlapping, also called _traditional_ sharding, or overlapping, otherwise known as _overlapped_ sharding.
 
-* Adding only a namespace selector to the Ingress Controller, so that all routes in a namespace with labels that match the namespace selector are in the Ingress shard.
+The following table outlines three sharding methods:
 
-* Adding only a route selector to the Ingress Controller, so that all routes with labels that match the route selector are in the Ingress shard.
+[cols="1,3",options="header"]
+|===
+|Sharding method
+|Description
 
-* Adding both a namespace selector and route selector to the Ingress Controller, so that routes with labels that match the route selector in a namespace with labels that match the namespace selector are in the Ingress shard.
+|Namespace selector
+|After you add a namespace selector to the Ingress Controller, all routes in a namespace that have matching labels for the namespace selector are included in the Ingress shard. Consider this method when an Ingress Controller serves all routes created in a namespace.
+
+|Route selector
+|After you add a route selector to the Ingress Controller, all routes with labels that match the route selector are included in the Ingress shard. Consider this method when you want an Ingress Controller to serve only a subset of routes or a specific route in a namespace.
+
+|Namespace and route selectors
+|Provides your Ingress Controller scope for both namespace selector and route selector methods. Consider this method when you want the flexibility of both the namespace selector and the route selector methods.
+|===
 
-With sharding, you can distribute subsets of routes over multiple Ingress Controllers. These subsets can be non-overlapping, also called _traditional_ sharding, or overlapping, otherwise known as _overlapped_ sharding.
diff --git a/modules/nw-ipfailover-environment-variables.adoc b/modules/nw-ipfailover-environment-variables.adoc
index 44c265fad7d8..3ecc907593cc 100644
--- a/modules/nw-ipfailover-environment-variables.adoc
+++ b/modules/nw-ipfailover-environment-variables.adoc
@@ -19,7 +19,9 @@ The following table contains the variables used to configure IP failover.
 
 |`OPENSHIFT_HA_NETWORK_INTERFACE`
 |
-|The interface name that IP failover uses to send Virtual Router Redundancy Protocol (VRRP) traffic. The default value is `eth0`.
+|The interface name that IP failover uses to send Virtual Router Redundancy Protocol (VRRP) traffic. The default value is `eth0`. 
+
+If your cluster uses the OVN-Kubernetes network plugin, set this value to `br-ex` to avoid packet loss. For a cluster that uses the OVN-Kubernetes network plugin, all listening interfaces do not serve VRRP but instead expect inbound traffic over a `br-ex` bridge.
 
 |`OPENSHIFT_HA_REPLICA_COUNT`
 |`2`
diff --git a/modules/nw-load-balancing-about.adoc b/modules/nw-load-balancing-about.adoc
new file mode 100644
index 000000000000..fc4e001185ea
--- /dev/null
+++ b/modules/nw-load-balancing-about.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-load-balancing-about_{context}"]
+= Supported load balancers
+
+Load balancing distributes incoming network traffic across multiple servers to maintain the health and efficiency of your clusters by ensuring that no single server bears too much load. Load balancers are devices that perform load balancing. They act as intermediaries between clients and servers to manage and direct traffic based on predefined rules. 
+
+{product-title} supports the following types of load balancers:
+
+* Classic Load Balancer (CLB)
+* Elastic Load Balancing (ELB)
+* Network Load Balancer (NLB)
+* Application Load Balancer (ALB)
+
+ELB is the default load-balancer type for AWS routers. CLB is the default for self-managed environments. NLB is the default for Red Hat OpenShift Service on AWS (ROSA).
+
+[IMPORTANT]
+====
+Use ALB in front of an application but not in front of a router. Using an ALB requires the AWS Load Balancer Operator add-on. This operator is not supported for all {aws-first} regions or for all {product-title} profiles.
+====
\ No newline at end of file
diff --git a/modules/nw-load-balancing-configure-define-type.adoc b/modules/nw-load-balancing-configure-define-type.adoc
new file mode 100644
index 000000000000..178e733d54ec
--- /dev/null
+++ b/modules/nw-load-balancing-configure-define-type.adoc
@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-load-balancing-configure-define-type_{context}"]
+= Define the default load balancer type
+
+When installing the cluster, you can specify the type of load balancer that you want to use. The type of load balancer you choose at cluster installation gets applied to the entire cluster.
+
+This example shows how to define the default load-balancer type for a cluster deployed on {aws-short}.You can apply the procedure on other supported platforms.
+
+[source,yaml]
+----
+apiVersion: v1
+kind: Network
+metadata:
+   name: cluster
+platform:
+  aws: <1>
+    lbType: classic <2>
+----
+<1> The `platform` key represents the platform on which you have deployed your cluster. This example uses `aws`.
+<2> The `lbType` key represents the load balancer type. This example uses the Classic Load Balancer, `classic`.
\ No newline at end of file
diff --git a/modules/nw-load-balancing-configure-specify-behavior.adoc b/modules/nw-load-balancing-configure-specify-behavior.adoc
new file mode 100644
index 000000000000..0420ac3ed7d4
--- /dev/null
+++ b/modules/nw-load-balancing-configure-specify-behavior.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-load-balancing-configure-specify-behavior_{context}"]
+= Specify load balancer behavior for an Ingress Controller
+
+After you install a cluster, you can configure your Ingress Controller to specify how services are exposed to external networks, so that you can better control the settings and behavior of a load balancer.
+
+[NOTE]
+====
+Changing the load balancer settings on an Ingress Controller might override the load balancer settings you specified at installation.
+====
+
+[source,yaml]
+----
+apiVersion: v1
+kind: Network
+metadata:
+  name: cluster
+endpointPublishingStrategy:
+  loadBalancer: <1>
+    dnsManagementPolicy: Managed
+    providerParameters:
+      aws:
+        classicLoadBalancer: <2>
+          connectionIdleTimeout: 0s
+        type: Classic
+      type: AWS
+    scope: External
+  type: LoadBalancerService
+----
+<1> The `loadBalancer' field specifies the load balancer configuration settings.
+<2> The `classicLoadBalancer` field sets the load balancer to `classic` and includes settings specific to the CLB on {aws-short}.
\ No newline at end of file
diff --git a/modules/nw-load-balancing-configure.adoc b/modules/nw-load-balancing-configure.adoc
new file mode 100644
index 000000000000..b4d50bdfafc4
--- /dev/null
+++ b/modules/nw-load-balancing-configure.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-load-balancing-configure_{context}"]
+= Configuring Load balancers
+
+You can define your default load-balancer type during cluster installation. After installation, you can configure your ingress controller to behave in a specific way that is not covered by the global platform configuration that you defined at cluster installation.
\ No newline at end of file
diff --git a/modules/nw-metallb-addresspool-cr.adoc b/modules/nw-metallb-addresspool-cr.adoc
index b931ad7d0977..c6d91d2b495a 100644
--- a/modules/nw-metallb-addresspool-cr.adoc
+++ b/modules/nw-metallb-addresspool-cr.adoc
@@ -19,7 +19,7 @@ The fields for the `IPAddressPool` custom resource are described in the followin
 |`metadata.name`
 |`string`
 |Specifies the name for the address pool.
-When you add a service, you can specify this pool name in the `metallb.universe.tf/address-pool` annotation to select an IP address from a specific pool.
+When you add a service, you can specify this pool name in the `metallb.io/address-pool` annotation to select an IP address from a specific pool.
 The names `doc-example`, `silver`, and `gold` are used throughout the documentation.
 
 |`metadata.namespace`
@@ -40,7 +40,7 @@ Specify each range in CIDR notation or as starting and ending IP addresses separ
 |`spec.autoAssign`
 |`boolean`
 |Optional: Specifies whether MetalLB automatically assigns IP addresses from this pool.
-Specify `false` if you want explicitly request an IP address from this pool with the `metallb.universe.tf/address-pool` annotation.
+Specify `false` if you want explicitly request an IP address from this pool with the `metallb.io/address-pool` annotation.
 The default value is `true`.
 
 |`spec.avoidBuggyIPs`
diff --git a/modules/nw-metallb-bgpadvertisement-cr.adoc b/modules/nw-metallb-bgpadvertisement-cr.adoc
index 0bfb2fd3faaa..0237a1795411 100644
--- a/modules/nw-metallb-bgpadvertisement-cr.adoc
+++ b/modules/nw-metallb-bgpadvertisement-cr.adoc
@@ -70,5 +70,6 @@ This BGP attribute applies to BGP sessions within the Autonomous System.
 
 |`spec.peers`
 |`string`
-|Optional: Peers limits the BGP peer to advertise the IPs of the selected pools to. When empty, the load balancer IP is announced to all the BGP peers configured.
+|Optional: Use a list to specify the `metadata.name` values for each `BGPPeer` resource that receives advertisements for the MetalLB service IP address. The MetalLB service IP address is assigned from the IP address pool. By default, the MetalLB service IP address is advertised to all configured `BGPPeer` resources. Use this field to limit the advertisement to specific `BGPpeer` resources.
+
 |===
diff --git a/modules/nw-metallb-bgppeer-cr.adoc b/modules/nw-metallb-bgppeer-cr.adoc
index 0025172e3751..fdc9f06297d1 100644
--- a/modules/nw-metallb-bgppeer-cr.adoc
+++ b/modules/nw-metallb-bgppeer-cr.adoc
@@ -45,6 +45,19 @@ If you use this field, you cannot specify a value in the `spec.peerASN` field.
 |`spec.peerAddress`
 |`string`
 |Specifies the IP address of the peer to contact for establishing the BGP session.
+If you use this field, you cannot specify a value in the `spec.interface` field.
+
+|`spec.interface`
+|`string`
+|Specifies the interface name to use when establishing a session. 
+Use this field to configure unnumbered BGP peering.
+You must establish a point-to-point, layer 2 connection between the two BGP peers.
+You can use unnumbered BGP peering with IPv4, IPv6, or dual-stack, but you must enable IPv6 RAs (Router Advertisements).
+Each interface is limited to one BGP connection.
+If you use this field, you cannot specify a value in the `spec.peerAddress` field.
+The `spec.bgp.routers.neighbors.interface` field is a Technology Preview feature only. 
+For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
+
 
 |`spec.sourceAddress`
 |`string`
diff --git a/modules/nw-metallb-configure-address-pool-vlan.adoc b/modules/nw-metallb-configure-address-pool-vlan.adoc
index bd0040ad8070..6ccd44bc5612 100644
--- a/modules/nw-metallb-configure-address-pool-vlan.adoc
+++ b/modules/nw-metallb-configure-address-pool-vlan.adoc
@@ -45,7 +45,7 @@ $ oc apply -f ipaddresspool-vlan.yaml
 +
 [source,terminal]
 ----
-$ oc edit network.config.openshift/cluster
+$ oc edit network.operator.openshift/cluster
 ----
 +
 .. Update the `spec.defaultNetwork.ovnKubernetesConfig` section to include the `gatewayConfig.ipForwarding` set to `Global`. It should look something like this:
diff --git a/modules/nw-metallb-configure-return-traffic-proc.adoc b/modules/nw-metallb-configure-return-traffic-proc.adoc
index ac38d7bff345..47ea8b9eb335 100644
--- a/modules/nw-metallb-configure-return-traffic-proc.adoc
+++ b/modules/nw-metallb-configure-return-traffic-proc.adoc
@@ -10,11 +10,11 @@ You can configure symmetric network routing for applications behind a MetalLB se
 
 This example associates a VRF routing table with MetalLB and an egress service to enable symmetric routing for ingress and egress traffic for pods behind a `LoadBalancer` service.
 
-[NOTE]
+[IMPORTANT]
 ====
 * If you use the `sourceIPBy: "LoadBalancerIP"` setting in the `EgressService` CR, you must specify the load-balancer node in the `BGPAdvertisement` custom resource (CR).
 
-* You can use the `sourceIPBy: "Network"` setting on clusters that use OVN-Kubernetes configured with the `gatewayConfig.routingViaHost` specification set to `true` only. Additionally, if you use the `sourceIPBy: "Network"` setting, you must schedule the application workload on nodes configured with the network VRF instance.
+* To configure an egress service for pods behind a load balancer service, you must configure OVN-Kubernetes with the `gatewayConfig.routingViaHost` specification set to `true`. For more information about this configuration, see "Cluster Network Operator in {product-title}" in _Networking Operators_.
 ====
 
 .Prerequisites
@@ -73,6 +73,9 @@ spec:
       - ip-to: 10.132.0.0/14
         priority: 998
         route-table: 254
+      - ip-to: 169.254.0.0/17
+        priority: 998
+        route-table: 254
 ----
 <1> The name of the policy.
 <2> This example applies the policy to all nodes with the label `vrf:true`.
@@ -82,7 +85,7 @@ spec:
 <6> The name of the route table ID for the VRF.
 <7> The IPv4 address of the interface associated with the VRF. 
 <8> Defines the configuration for network routes. The `next-hop-address` field defines the IP address of the next hop for the route. The `next-hop-interface` field defines the outgoing interface for the route. In this example, the VRF routing table is `2`, which references the ID that you define in the `EgressService` CR.
-<9> Defines additional route rules. The `ip-to` fields must match the `Cluster Network` CIDR and `Service Network` CIDR. You can view the values for these CIDR address specifications by running the following command: `oc describe network.config/cluster`.
+<9> Defines additional route rules. The `ip-to` fields must match the `Cluster Network` CIDR, `Service Network` CIDR, and `Internal Masquerade` subnet CIDR. You can view the values for these CIDR address specifications by running the following command: `oc describe network.operator/cluster`.
 <10> The main routing table that the Linux kernel uses when calculating routes has the ID `254`.
 
 .. Apply the policy by running the following command:
@@ -193,7 +196,7 @@ spec:
 <2> Specify the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the load-balancer service that you want to modify. The egress service is namespace-scoped.
 <3> This example assigns the `LoadBalancer` service ingress IP address as the source IP address for egress traffic.
 <4> If you specify `LoadBalancer` for the `sourceIPBy` specification, a single node handles the `LoadBalancer` service traffic. In this example, only a node with the label `vrf: "true"` can handle the service traffic. If you do not specify a node, OVN-Kubernetes selects a worker node to handle the service traffic. When a node is selected, OVN-Kubernetes labels the node in the following format: `egress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: ""`.
-<5> Specify the routing table for egress traffic.
+<5> Specify the routing table ID for egress traffic. Ensure that the value matches the `route-table-id` ID defined in the `NodeNetworkConfigurationPolicy` resource, for example, `route-table-id: 2`. 
 
 .. Apply the configuration for the egress service by running the following command:
 +
@@ -212,5 +215,4 @@ $ curl <external_ip_address>:<port_number> <1>
 ----
 <1> Update the external IP address and port number to suit your application endpoint.
 
-. Optional: If you assigned the `LoadBalancer` service ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.
-
+. Optional: If you assigned the `LoadBalancer` service ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.
\ No newline at end of file
diff --git a/modules/nw-metallb-configure-secondary-interface.adoc b/modules/nw-metallb-configure-secondary-interface.adoc
index 35704a6dd59a..e62a48ae48e3 100644
--- a/modules/nw-metallb-configure-secondary-interface.adoc
+++ b/modules/nw-metallb-configure-secondary-interface.adoc
@@ -128,5 +128,5 @@ The output indicates that IPv4 and IPv6 packet forwarding is enabled on the `bri
 
 [source,terminal]
 ----
-$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}
+$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
 ----
\ No newline at end of file
diff --git a/modules/nw-metallb-configure-svc.adoc b/modules/nw-metallb-configure-svc.adoc
index ccc3b38b573b..8820d3d89b74 100644
--- a/modules/nw-metallb-configure-svc.adoc
+++ b/modules/nw-metallb-configure-svc.adoc
@@ -51,7 +51,7 @@ $ oc describe service <service_name>
 Name:                     <service_name>
 Namespace:                default
 Labels:                   <none>
-Annotations:              metallb.universe.tf/address-pool: doc-example  <1>
+Annotations:              metallb.io/address-pool: doc-example  <1>
 Selector:                 app=service_name
 Type:                     LoadBalancer  <2>
 IP Family Policy:         SingleStack
diff --git a/modules/nw-metallb-configure-vrf-bgppeer.adoc b/modules/nw-metallb-configure-vrf-bgppeer.adoc
index 56bab10eafb9..126c81c99737 100644
--- a/modules/nw-metallb-configure-vrf-bgppeer.adoc
+++ b/modules/nw-metallb-configure-vrf-bgppeer.adoc
@@ -8,9 +8,6 @@
 
 You can expose a service through a virtual routing and forwarding (VRF) instance by associating a VRF on a network interface with a BGP peer.
 
-:FeatureName: Exposing a service through a VRF on a BGP peer
-include::snippets/technology-preview.adoc[]
-
 By using a VRF on a network interface to expose a service through a BGP peer, you can segregate traffic to the service, configure independent routing decisions, and enable multi-tenancy support on a network interface.
 
 [NOTE]
diff --git a/modules/nw-metallb-example-bgppeer.adoc b/modules/nw-metallb-example-bgppeer.adoc
index 4c51a723e577..3a46ac7142bb 100644
--- a/modules/nw-metallb-example-bgppeer.adoc
+++ b/modules/nw-metallb-example-bgppeer.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="nw-metallb-example-bgppeer_{context}"]
 = Example BGP peer configurations
+:FeatureName: The `spec.interface` field  
 
 [id="nw-metallb-example-limit-nodes-bgppeer_{context}"]
 == Example: Limit which nodes connect to a BGP peer
@@ -82,3 +83,31 @@ spec:
   peerASN: 64500
   myASN: 64500
 ----
+
+[id="nw-metallb-example-unnumbered-bgp-peering_{context}"]
+== Example: Specify BGP peers for unnumbered BGP peering
+
+include::snippets/technology-preview.adoc[]
+
+To configure unnumbered BGP peering, specify the interface in the `spec.interface` field by using the following example configuration:
+
+[source,yaml]
+----
+apiVersion: metallb.io/v1beta2
+kind: BGPPeer
+metadata:
+  name: peer-unnumber
+  namespace: metallb-system
+spec:
+  myASN: 64512
+  ASN: 645000
+  interface: net0
+----
+[NOTE]
+====
+To use the `interface` field, you must establish a point-to-point, layer 2 connection between the two BGP peers.
+You can use unnumbered BGP peering with IPv4, IPv6, or dual-stack, but you must enable IPv6 RAs (Router Advertisements).
+Each interface is limited to one BGP connection.
+
+If you use this field, you cannot specify a value in the `spec.bgp.routers.neighbors.address` field.
+====
\ No newline at end of file
diff --git a/modules/nw-metallb-frr-k8s-configuration-crd.adoc b/modules/nw-metallb-frr-k8s-configuration-crd.adoc
index db2377035c37..e293a17090e9 100644
--- a/modules/nw-metallb-frr-k8s-configuration-crd.adoc
+++ b/modules/nw-metallb-frr-k8s-configuration-crd.adoc
@@ -6,6 +6,8 @@
 [id="nw-metallb-frrconfiguration-crd_{context}"]
 = Configuring the FRRConfiguration CRD
 
+:FeatureName: The `spec.bgp.routers.neighbors.interface` field  
+
 The following section provides reference examples that use the `FRRConfiguration` custom resource (CR).
 
 [id="nw-metallb-frrconfiguration-crd-routers_{context}"]
@@ -208,6 +210,57 @@ spec:
     foo: "bar"
 ----
 
+[id="nw-metallb-frrconfiguration-crd-interface_{context}"]
+== The interface field
+
+include::snippets/technology-preview.adoc[]
+
+You can use the `interface` field to configure unnumbered BGP peering by using the following example configuration:
+
+.Example `FRRConfiguration` CR
+[source,yaml]
+----
+apiVersion: frrk8s.metallb.io/v1beta1
+kind: FRRConfiguration
+metadata:
+  name: test
+  namespace: frr-k8s-system
+spec:
+  bgp:
+    bfdProfiles:
+    - echoMode: false
+      name: simple
+      passiveMode: false
+    routers:
+    - asn: 64512
+      neighbors:
+      - asn: 64512
+        bfdProfile: simple
+        disableMP: false
+        interface: net10 <1>
+        port: 179
+        toAdvertise:
+          allowed:
+            mode: filtered
+            prefixes:
+            - 5.5.5.5/32
+        toReceive:
+          allowed:
+            mode: filtered
+      prefixes:
+      - 5.5.5.5/32
+----
+<1> Activates unnumbered BGP peering.
+
+[NOTE]
+====
+To use the `interface` field, you must establish a point-to-point, layer 2 connection between the two BGP peers.
+You can use unnumbered BGP peering with IPv4, IPv6, or dual-stack, but you must enable IPv6 RAs (Router Advertisements).
+Each interface is limited to one BGP connection.
+
+If you use this field, you cannot specify a value in the `spec.bgp.routers.neighbors.address` field.
+====
+
 The fields for the `FRRConfiguration` custom resource are described in the following table:
 
 .MetalLB FRRConfiguration custom resource
@@ -252,6 +305,17 @@ If you use this field, you cannot specify a value in the `spec.bgp.routers.neigh
 |`spec.bgp.routers.neighbors.address`
 |`string`
 |Specifies the IP address to establish the session with.
+If you use this field, you cannot specify a value in the `spec.bgp.routers.neighbors.interface` field.
+
+|`spec.bgp.routers.neighbors.interface`
+|`string`
+|Specifies the interface name to use when establishing a session. 
+Use this field to configure unnumbered BGP peering.
+There must be a point-to-point, layer 2 connection between the two BGP peers.
+You can use unnumbered BGP peering with IPv4, IPv6, or dual-stack, but you must enable IPv6 RAs (Router Advertisements).
+Each interface is limited to one BGP connection.
+The `spec.bgp.routers.neighbors.interface` field is a Technology Preview feature only.
+For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
 
 |`spec.bgp.routers.neighbors.port`
 |`integer`
diff --git a/modules/nw-modifying-operator-install-config.adoc b/modules/nw-modifying-operator-install-config.adoc
index 8597d7efd156..046269465461 100644
--- a/modules/nw-modifying-operator-install-config.adoc
+++ b/modules/nw-modifying-operator-install-config.adoc
@@ -14,6 +14,9 @@ ifeval::["{context}" == "installing-vsphere-network-customizations"]
 :ignition-config:
 :vsphere:
 endif::[]
+ifeval::["{context}" == "installing-vsphere-installer-provisioned-network-customizations"]
+:vsphere-ipi:
+endif::[]
 ifeval::["{context}" == "installing-ibm-cloud-network-customizations"]
 :ibm-cloud:
 endif::[]
@@ -47,7 +50,7 @@ $ ./openshift-install create manifests --dir <installation_directory> <1>
 
 . Create a stub manifest file for the advanced network configuration that is named `cluster-network-03-config.yml` in the `<installation_directory>/manifests/` directory:
 +
-[source,terminal]
+[source,yaml]
 ----
 apiVersion: operator.openshift.io/v1
 kind: Network
@@ -78,8 +81,8 @@ spec:
 installation program consumes the `manifests/` directory when you create the
 Ignition config files.
 
-ifdef::vsphere[]
-. Remove the Kubernetes manifest files that define the control plane machines and compute machineSets:
+ifndef::vsphere-ipi[]
+. Remove the Kubernetes manifest files that define the control plane machines and compute `MachineSets`:
 +
 [source,terminal]
 ----
@@ -89,8 +92,8 @@ $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_o
 Because you create and manage these resources yourself, you do not have
 to initialize them.
 +
-* You can preserve the MachineSet files to create compute machines by using the machine API, but you must update references to them to match your environment.
-endif::vsphere[]
+* You can preserve the `MachineSet` files to create compute machines by using the machine API, but you must update references to them to match your environment.
+endif::[]
 
 ifeval::["{context}" == "installing-bare-metal-network-customizations"]
 :!ignition-config:
@@ -99,6 +102,9 @@ ifeval::["{context}" == "installing-vsphere-network-customizations"]
 :!ignition-config:
 :!vsphere:
 endif::[]
+ifeval::["{context}" == "installing-vsphere-installer-provisioned-network-customizations"]
+:!vsphere-ipi:
+endif::[]
 ifeval::["{context}" == "installing-ibm-cloud-network-customizations"]
 :!ibm-cloud:
 endif::[]
diff --git a/modules/nw-multus-add-pod.adoc b/modules/nw-multus-add-pod.adoc
index a968ef9676eb..f4ecfbb1d267 100644
--- a/modules/nw-multus-add-pod.adoc
+++ b/modules/nw-multus-add-pod.adoc
@@ -1,7 +1,8 @@
 // Module included in the following assemblies:
 //
 // * networking/multiple_networks/attaching-pod.adoc
-// * networking/hardware_networks/add-pod.adoc
+// * networking/hardware_networks/configuring-sriov-ib-attach.adoc
+// * networking/hardware_networks/configuring-sriov-net-attach.adoc
 
 ifeval::["{context}" == "configuring-sr-iov"]
 :sriov:
diff --git a/modules/nw-multus-create-network-apply.adoc b/modules/nw-multus-create-network-apply.adoc
index f992de70c2f3..4ddc0631a857 100644
--- a/modules/nw-multus-create-network-apply.adoc
+++ b/modules/nw-multus-create-network-apply.adoc
@@ -8,8 +8,9 @@
 
 .Prerequisites
 
-* Install the OpenShift CLI (`oc`).
-* Log in as a user with `cluster-admin` privileges.
+* You have installed the {oc-first}.
+* You have logged in as a user with `cluster-admin` privileges.
+* You are working in the namespace where the NAD is to be deployed.
 
 .Procedure
 
@@ -26,6 +27,7 @@ spec:
     {
       "cniVersion": "0.3.1",
       "name": "work-network",
+      "namespace": "namespace2", #<1>
       "type": "host-device",
       "device": "eth1",
       "ipam": {
@@ -33,6 +35,7 @@ spec:
       }
     }
 ----
+<1> Optional: You can specify a namespace to which the NAD is applied. If you are working in the namespace where the NAD is to be deployed, this spec is not necessary.
 
 . To create the additional network, enter the following command:
 +
diff --git a/modules/nw-multus-ipam-object.adoc b/modules/nw-multus-ipam-object.adoc
index 560c74624e3e..16b6b2a559a7 100644
--- a/modules/nw-multus-ipam-object.adoc
+++ b/modules/nw-multus-ipam-object.adoc
@@ -9,25 +9,33 @@
 // for the Macvlan CNI plugin only. In the future other Multus plugins
 // might be managed the same way by the CNO.
 
-ifeval::["{context}" == "configuring-sriov-net-attach"]
-:sr-iov:
-endif::[]
-
 :_mod-docs-content-type: CONCEPT
 [id="nw-multus-ipam-object_{context}"]
-= Configuration of IP address assignment for an additional network
+= Configuration of IP address assignment for a network attachment
+
+For additional networks, IP addresses can be assigned using an IP Address Management (IPAM) CNI plugin, which supports various assignment methods, including Dynamic Host Configuration Protocol (DHCP) and static assignment.
+
+The DHCP IPAM CNI plugin responsible for dynamic assignment of IP addresses operates with two distinct components:
+
+* *CNI Plugin*: Responsible for integrating with the Kubernetes networking stack to request and release IP addresses.
+* *DHCP IPAM CNI Daemon*: A listener for DHCP events that coordinates with existing DHCP servers in the environment to handle IP address assignment requests. This daemon is _not_ a DHCP server itself.
 
-The IP address management (IPAM) Container Network Interface (CNI) plugin provides IP addresses for other CNI plugins.
+For networks requiring `type: dhcp` in their IPAM configuration, ensure the following:
 
-You can use the following IP address assignment types:
+* A DHCP server is available and running in the environment. The DHCP server is external to the cluster and is expected to be part of the customer's existing network infrastructure.
+* The DHCP server is appropriately configured to serve IP addresses to the nodes.
+
+In cases where a DHCP server is unavailable in the environment, it is recommended to use the Whereabouts IPAM CNI plugin instead. The Whereabouts CNI provides similar IP address management capabilities without the need for an external DHCP server.
+
+[NOTE]
+====
+Use the Whereabouts CNI plugin when there is no external DHCP server or where static IP address management is preferred. The Whereabouts plugin includes a reconciler daemon to manage stale IP address allocations.
+====
 
-- Static assignment.
-- Dynamic assignment through a DHCP server. The DHCP server you specify must be reachable from the additional network.
-- Dynamic assignment through the Whereabouts IPAM CNI plugin.
+A DHCP lease must be periodically renewed throughout the container's lifetime, so a separate daemon, the DHCP IPAM CNI Daemon, is required. To deploy the DHCP IPAM CNI daemon, modify the Cluster Network Operator (CNO) configuration to trigger the deployment of this daemon as part of the additional network setup.
 
 ////
-IMPORTANT: If you set the `type` parameter to the `DHCP` value, you cannot set
-any other parameters.
+IMPORTANT: If you set the `type` parameter to the `DHCP` value, you cannot set any other parameters.
 ////
 
 [id="nw-multus-static_{context}"]
@@ -130,16 +138,12 @@ such as `example-host`, during a DNS lookup query.
 [id="nw-multus-dhcp_{context}"]
 == Dynamic IP address (DHCP) assignment configuration
 
-The following JSON describes the configuration for dynamic IP address address assignment with DHCP.
+A pod obtains its original DHCP lease when it is created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster.
 
-.Renewal of DHCP leases
 [IMPORTANT]
 ====
-A pod obtains its original DHCP lease when it is created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster.
-
-ifdef::sr-iov[]
-The SR-IOV Network Operator does not create a DHCP server deployment; The Cluster Network Operator is responsible for creating the minimal DHCP server deployment.
-endif::sr-iov[]
+For an Ethernet network attachment, the SR-IOV Network Operator does not create a DHCP server deployment; the Cluster Network Operator is responsible for creating the minimal DHCP server deployment.
+====
 
 To trigger the deployment of the DHCP server, you must create a shim network attachment by editing the Cluster Network Operator configuration, as in the following example:
 
@@ -166,7 +170,8 @@ spec:
       }
   # ...
 ----
-====
+
+The following table describes the configuration parameters for dynamic IP address address assignment with DHCP.
 
 .`ipam` DHCP configuration object
 [cols=".^2,.^2,.^6",options="header"]
@@ -179,6 +184,8 @@ spec:
 
 |====
 
+The following JSON example describes the configuration p for dynamic IP address address assignment with DHCP.
+
 .Dynamic IP address (DHCP) assignment configuration example
 [source,json]
 ----
@@ -274,7 +281,3 @@ The following example shows a dynamic IP address assignment that uses overlappin
 }
 ----
 <1> Optional. If set, must match the `network_name` of `NetworkAttachmentDefinition 1`. 
-
-ifdef::sr-iov[]
-:!sr-iov:
-endif::[]
\ No newline at end of file
diff --git a/modules/nw-multus-macvlan-object.adoc b/modules/nw-multus-macvlan-object.adoc
index d11e64ebd3d4..374b1eef60ec 100644
--- a/modules/nw-multus-macvlan-object.adoc
+++ b/modules/nw-multus-macvlan-object.adoc
@@ -5,9 +5,9 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="nw-multus-macvlan-object_{context}"]
-= Configuration for a macvlan additional network
+= Configuration for a MACVLAN additional network
 
-The following object describes the configuration parameters for the MACVLAN CNI plugin:
+The following object describes the configuration parameters for the MAC Virtual LAN (MACVLAN) Container Network Interface (CNI) plugin:
 
 .MACVLAN CNI plugin JSON configuration object
 [cols=".^2,.^2,.^6",options="header"]
@@ -39,7 +39,7 @@ The following object describes the configuration parameters for the MACVLAN CNI
 |Optional: The host network interface to associate with the newly created macvlan interface. If a value is not specified, then the default route interface is used.
 
 |`mtu`
-|`string`
+|`integer`
 |Optional: The maximum transmission unit (MTU) to the specified value. The default value is automatically set by the kernel.
 
 |`linkInContainer`
diff --git a/modules/nw-ne-changes-externalip-ovn.adoc b/modules/nw-ne-changes-externalip-ovn.adoc
new file mode 100644
index 000000000000..715781025411
--- /dev/null
+++ b/modules/nw-ne-changes-externalip-ovn.adoc
@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-ne-changes-externalip-ovn_{context}"]
+= Understanding changes in external IP behavior with OVN-Kubernetes
+
+When migrating from OpenShift SDN to OVN-Kubernetes (OVN-K), services that use external IPs might become inaccessible across namespaces due to `NetworkPolicy` enforcement.
+
+In OpenShift SDN, external IPs were accessible across namespaces by default. However, in OVN-K, network policies strictly enforce multitenant isolation, preventing access to services exposed via external IPs from other namespaces.
+
+To ensure accessibility, consider the following alternatives:
+
+* Use an ingress or route: Instead of exposing services by using external IPs, configure an ingress or route to allow external access while maintaining security controls.
+
+* Adjust `NetworkPolicies`: Modify `NetworkPolicy` rules to explicitly allow access from required namespaces and ensure that traffic is allowed to the designated service ports. Without allowing traffic to the required ports, access might still be blocked, even if the namespace is explicitly allowed.
+
+* Use a `LoadBalancer` service: If applicable, deploy a `LoadBalancer` service instead of relying on external IPs.
+
+For more information on configuring NetworkPolicies, see "Configuring NetworkPolicies".
diff --git a/modules/nw-network-config.adoc b/modules/nw-network-config.adoc
index e50b1cef9c8d..b639dd365af1 100644
--- a/modules/nw-network-config.adoc
+++ b/modules/nw-network-config.adoc
@@ -24,6 +24,7 @@ Phase 1:: You can customize the following network-related fields in the `install
 * `networking.clusterNetwork`
 * `networking.serviceNetwork`
 * `networking.machineNetwork`
+* `nodeNetworking`
 +
 For more information, see "Installation configuration parameters".
 +
diff --git a/modules/nw-networkpolicy-deny-all-allowed.adoc b/modules/nw-networkpolicy-deny-all-allowed.adoc
index 000fe1516896..7109e326a606 100644
--- a/modules/nw-networkpolicy-deny-all-allowed.adoc
+++ b/modules/nw-networkpolicy-deny-all-allowed.adoc
@@ -16,14 +16,12 @@ endif::[]
 [id="nw-networkpolicy-deny-all-multi-network-policy_{context}"]
 = Creating a default deny all {name} policy
 
-This is a fundamental policy, blocking all cross-pod networking other than network traffic allowed by the configuration of other deployed network policies. This procedure enforces a default `deny-by-default` policy.
+This policy blocks all cross-pod networking other than network traffic allowed by the configuration of other deployed network policies and traffic between host-networked pods. This procedure enforces a strong deny policy by applying a `deny-by-default` policy in the `my-project` namespace.
 
-ifndef::microshift[]
-[NOTE]
+[WARNING]
 ====
-If you log in with a user with the `cluster-admin` role, then you can create a network policy in any namespace in the cluster.
+Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic communication, the following policy might cause communication problems across your cluster.
 ====
-endif::microshift[]
 
 .Prerequisites
 ifndef::microshift[]
@@ -46,7 +44,7 @@ apiVersion: k8s.cni.cncf.io/v1beta1
 kind: MultiNetworkPolicy
 metadata:
   name: deny-by-default
-  namespace: default <1>
+  namespace: my-project <1>
   annotations:
     k8s.v1.cni.cncf.io/policy-for: <namespace_name>/<network_name> <2>
 spec:
@@ -60,23 +58,23 @@ kind: NetworkPolicy
 apiVersion: networking.k8s.io/v1
 metadata:
   name: deny-by-default
-  namespace: default <1>
+  namespace: my-project <1>
 spec:
   podSelector: {} <2>
   ingress: [] <3>
 endif::multi[]
 ----
 ifdef::multi[]
-<1> `namespace: default` deploys this policy to the `default` namespace.
-<2> `network_name`: specifies the name of a network attachment definition.
-<3> `podSelector:` is empty, this means it matches all the pods. Therefore, the policy applies to all pods in the default namespace.
-<4> `policyTypes:` a list of rule types that the `NetworkPolicy` relates to.
-<5> Specifies as `Ingress` only `policyType`.
-<6> There are no `ingress` rules specified. This causes incoming traffic to be dropped to all pods.
+<1> Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
+<2> Specifies the name of a network attachment definition.
+<3> If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
+<4> Specifies a list of rule types that the `NetworkPolicy` relates to.
+<5> Specifies `Ingress` only `policyTypes`.
+<6> Specifies `ingress` rules. If not specified, all incoming traffic is dropped to all pods.
 endif::multi[]
 ifndef::multi[]
-<1> `namespace: default` deploys this policy to the `default` namespace.
-<2> `podSelector:` is empty, this means it matches all the pods. Therefore, the policy applies to all pods in the default namespace.
+<1> `Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
+<2> If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
 <3> There are no `ingress` rules specified. This causes incoming traffic to be dropped to all pods.
 endif::multi[]
 +
diff --git a/modules/nw-networkpolicy-optimize-ovn.adoc b/modules/nw-networkpolicy-optimize-ovn.adoc
index 236e7857ec55..d393babd4484 100644
--- a/modules/nw-networkpolicy-optimize-ovn.adoc
+++ b/modules/nw-networkpolicy-optimize-ovn.adoc
@@ -102,3 +102,40 @@ spec:
 ----
 +
 You can apply this optimization when only multiple selectors are expressed as one. In cases where selectors are based on different labels, it may not be possible to apply this optimization. In those cases, consider applying some new labels for network policy optimization specifically.
+
+[id="nw-networkpolicy-external-ip-ovn_{context}"]
+== NetworkPolicies and external IPs in OVN-Kubernetes
+
+In OVN-Kubernetes, `NetworkPolicies` enforce strict isolation rules. If a service is exposed using an external IP, `NetworkPolicies` can block access from other namespaces unless explicitly configured.
+
+To allow access to external IPs across namespaces, create a `NetworkPolicy` that explicitly permits ingress from the required namespaces and ensures traffic is allowed to the designated service ports. Without allowing traffic to the required ports, access might still be restricted.
+
+.Example output
+[source,yaml]
+----
+  apiVersion: networking.k8s.io/v1
+  kind: NetworkPolicy
+  metadata:
+    annotations:
+    name: <policy_name> <1>
+    namespace: openshift-ingress
+  spec:
+    ingress:
+    - ports:
+      - port: 80
+        protocol: TCP
+    - ports:
+      - port: 443
+        protocol: TCP
+    - from:
+      - namespaceSelector:
+          matchLabels:
+          kubernetes.io/metadata.name: <namespace_name> <2>
+    podSelector: {}
+    policyTypes:
+    - Ingress
+----
+<1> Specify the policy name. 
+<2> Specify the namespace name. 
+
+For more details, see "About network policy".
\ No newline at end of file
diff --git a/modules/nw-nodeport-service-range-edit.adoc b/modules/nw-nodeport-service-range-edit.adoc
index 5a2e4acdc7ac..bb17579ddf4c 100644
--- a/modules/nw-nodeport-service-range-edit.adoc
+++ b/modules/nw-nodeport-service-range-edit.adoc
@@ -8,6 +8,14 @@
 
 You can expand the node port range for the cluster.
 
+[IMPORTANT]
+====
+You can expand the node port range into the protected port range, which is between 0 and 32767. However, after expansion, you cannot change the range. Attempting to change the range returns the following error:
+`The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the previous range 0-32767`. 
+
+Before making changes, ensure that the new range you set is appropriate for your cluster.
+====
+
 .Prerequisites
 
 * Install the OpenShift CLI (`oc`).
diff --git a/modules/nw-openstack-sr-iov-testpmd-pod.adoc b/modules/nw-openstack-sr-iov-testpmd-pod.adoc
index 730149155727..ae98dd0983d9 100644
--- a/modules/nw-openstack-sr-iov-testpmd-pod.adoc
+++ b/modules/nw-openstack-sr-iov-testpmd-pod.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/hardware_networks/add-pod.adoc
+// * networking/hardware_networks/configuring-sriov-device.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="nw-openstack-ovs-sr-iov-testpmd-pod_{context}"]
diff --git a/modules/nw-operator-cr.adoc b/modules/nw-operator-cr.adoc
index 6671f88875c6..c9fb0c959bd7 100644
--- a/modules/nw-operator-cr.adoc
+++ b/modules/nw-operator-cr.adoc
@@ -138,7 +138,7 @@ The values for the `defaultNetwork` object are defined in the following table:
 |`OVNKubernetes`. The {openshift-networking} network plugin is selected during installation. This value cannot be changed after cluster installation.
 [NOTE]
 ====
-{product-title} uses the OVN-Kubernetes network plugin by default. OpenShift SDN is no longer available as an installation choice for new clusters.
+{product-title} uses the OVN-Kubernetes network plugin by default.
 ====
 
 |`ovnKubernetesConfig`
@@ -311,6 +311,10 @@ If you set this field to `true`, you do not receive the performance benefits of
 |`ipForwarding`
 |`object`
 |You can control IP forwarding for all traffic on OVN-Kubernetes managed interfaces by using the `ipForwarding` specification in the `Network` resource. Specify `Restricted` to only allow IP forwarding for Kubernetes related traffic. Specify `Global` to allow forwarding of all IP traffic. For new installations, the default is `Restricted`. For updates to {product-title} 4.14 or later, the default is `Global`.
+[NOTE]
+====
+The default value of `Restricted` sets the IP forwarding to drop.
+====
 
 |`ipv4`
 |`object`
diff --git a/modules/nw-osp-specify-floating-ip.adoc b/modules/nw-osp-specify-floating-ip.adoc
new file mode 100644
index 000000000000..96e14de0749b
--- /dev/null
+++ b/modules/nw-osp-specify-floating-ip.adoc
@@ -0,0 +1,64 @@
+// Modules included in the following assemblies:
+//
+// * networking/load-balancing-openstack.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-osp-specify-floating-ip_{context}"]
+= Specifying a floating IP address in the Ingress Controller
+
+By default, a floating IP address gets randomly assigned to your {product-title} cluster on {rh-openstack-first} upon deployment. This floating IP address is associated with your Ingress port.
+
+You might want to pre-create a floating IP address before updating your DNS records and cluster deployment. In this situation, you can define a floating IP address to the Ingress Controller. You can do this regardless of whether you are using Octavia or a user-managed cluster.
+
+.Procedure
+
+. Create the Ingress Controller custom resource (CR) file with the floating IPs:
++
+.Example Ingress config `sample-ingress.yaml`
+[source,yaml]
+----
+apiVersion: operator.openshift.io/v1
+kind: IngressController
+metadata:
+  namespace: openshift-ingress-operator
+  name: <name> <1>
+spec:
+  domain: <domain> <2>
+  endpointPublishingStrategy:
+    type: LoadBalancerService
+    loadBalancer:
+      scope: External <3>
+      providerParameters:
+        type: OpenStack
+        openstack:
+          floatingIP: <ingress_port_IP> <4>
+----
+<1> The name of your Ingress Controller. If you are using the default Ingress Controller, the value for this field is `default`.
+<2> The DNS name serviced by the Ingress Controller.
+<3> You must set the scope to `External` to use a floating IP address.
+<4> The floating IP address associated with the port your Ingress Controller is listening on.
+
+. Apply the CR file by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f sample-ingress.yaml
+----
+
+. Update your DNS records with the Ingress Controller endpoint:
++
+[source,text]
+----
+*.apps.<name>.<domain>. IN A <ingress_port_IP>
+----
+
+. Continue with creating your {product-title} cluster.
+
+.Verification
+
+* Confirm that the load balancer was successfully provisioned by checking the `IngressController` conditions using the following command:
++
+[source,terminal]
+----
+$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC
+----
diff --git a/modules/nw-ovn-k-day-2-masq-subnet.adoc b/modules/nw-ovn-k-day-2-masq-subnet.adoc
index 7d34ce18bd0c..ee5e1b8d5cc2 100644
--- a/modules/nw-ovn-k-day-2-masq-subnet.adoc
+++ b/modules/nw-ovn-k-day-2-masq-subnet.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="nw-ovn-k-day-2-masq-subnet_{context}"]
-= Configuring the OVN-Kubernetes masquerade subnet as a Day 2 operation
+= Configuring the OVN-Kubernetes masquerade subnet as a post-installation operation
 
-You can change the masquerade subnet used by OVN-Kubernetes as a Day 2 operation in order to avoid conflicts with any existing subnets that are already in use in your environment.
+You can change the masquerade subnet used by OVN-Kubernetes as a post-installation operation to avoid conflicts with any existing subnets that are already in use in your environment.
 
 .Prerequisites
 
@@ -15,8 +15,8 @@ You can change the masquerade subnet used by OVN-Kubernetes as a Day 2 operation
 
 .Procedure
 
-. Change your cluster's masquerade subnet:
-
+* Change your cluster's masquerade subnet:
++
 ** For dualstack clusters using IPv6, run the following command:
 +
 [source,terminal]
@@ -25,11 +25,11 @@ $ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"def
 ----
 +
 where:
-
-`ipv4_masquerade_subnet`:: Specifies an IP address to be used as the IPv4 masquerade subnet. This range cannot overlap with any other subnets used by {product-title} or on the host itself. The default value for IPv4 is `169.254.169.0/29`.
-
++
+`ipv4_masquerade_subnet`:: Specifies an IP address to be used as the IPv4 masquerade subnet. This range cannot overlap with any other subnets used by {product-title} or on the host itself. In versions of {product-title} earlier than 4.17, the default value for IPv4 was `169.254.169.0/29`, and clusters that were upgraded to version 4.17 maintain this value. For new clusters starting from version 4.17, the default value is `169.254.0.0/17`. 
++
 `ipv6_masquerade_subnet`:: Specifies an IP address to be used as the IPv6 masquerade subnet. This range cannot overlap with any other subnets used by {product-title} or on the host itself. The default value for IPv6 is `fd69::/125`.
-
++
 ** For clusters using IPv4, run the following command:
 +
 [source,terminal]
@@ -38,5 +38,5 @@ $ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"def
 ----
 +
 where:
-
-`ipv4_masquerade_subnet`:: Specifies an IP address to be used as the IPv4 masquerade subnet. This range cannot overlap with any other subnets used by {product-title} or on the host itself. The default value for IPv4 is `169.254.169.0/29`.
++
+`ipv4_masquerade_subnet`::Specifies an IP address to be used as the IPv4 masquerade subnet. This range cannot overlap with any other subnets used by {product-title} or on the host itself. In versions of {product-title} earlier than 4.17, the default value for IPv4 was `169.254.169.0/29`, and clusters that were upgraded to version 4.17 maintain this value. For new clusters starting from version 4.17, the default value is `169.254.0.0/17`.
diff --git a/modules/nw-ovn-kubernetes-change-join-subnet.adoc b/modules/nw-ovn-kubernetes-change-join-subnet.adoc
index 85319607b04c..8945acffa043 100644
--- a/modules/nw-ovn-kubernetes-change-join-subnet.adoc
+++ b/modules/nw-ovn-kubernetes-change-join-subnet.adoc
@@ -16,7 +16,7 @@ You can change the join subnet used by OVN-Kubernetes to avoid conflicting with
 
 .Procedure
 
-. To change the OVN-Kubernetes join subnet, enter the following command:
+* To change the OVN-Kubernetes join subnet, enter the following command:
 +
 [source,terminal]
 ----
@@ -48,7 +48,7 @@ $ oc get network.operator.openshift.io \
   -o jsonpath="{.items[0].spec.defaultNetwork}"
 ----
 +
-It can take up to 30 minutes for this change to take effect.
+The command operation can take up to 30 minutes for this change to take effect.
 +
 .Example output
 ----
diff --git a/modules/nw-ovn-kubernetes-change-transit-subnet.adoc b/modules/nw-ovn-kubernetes-change-transit-subnet.adoc
index 1f253aede2b1..17108d4824ff 100644
--- a/modules/nw-ovn-kubernetes-change-transit-subnet.adoc
+++ b/modules/nw-ovn-kubernetes-change-transit-subnet.adoc
@@ -16,7 +16,7 @@ You can change the transit subnet used by OVN-Kubernetes to avoid conflicting wi
 
 .Procedure
 
-. To change the OVN-Kubernetes transit subnet, enter the following command:
+* To change the OVN-Kubernetes transit subnet, enter the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/nw-ovn-kubernetes-features.adoc b/modules/nw-ovn-kubernetes-features.adoc
index 3e94b47d546c..3cc0f4bd6c8e 100644
--- a/modules/nw-ovn-kubernetes-features.adoc
+++ b/modules/nw-ovn-kubernetes-features.adoc
@@ -15,8 +15,8 @@ The OVN-Kubernetes network plugin supports the following capabilities:
 
 * Hybrid clusters that can run both Linux and Microsoft Windows workloads. This environment is known as _hybrid networking_.
 * Offloading of network data processing from the host central processing unit (CPU) to compatible network cards and data processing units (DPUs). This is known as _hardware offloading_.
-* IPv4-primary dual-stack networking on bare-metal, {vmw-full}, {ibm-power-name}, {ibm-z-name}, and {rh-openstack} platforms.
-* IPv6 single-stack networking on a bare-metal platform.
+* IPv4-primary dual-stack networking on bare-metal, {vmw-full}, {ibm-power-name}, {ibm-z-name}, and {rh-openstack-first} platforms.
+* IPv6 single-stack networking on {rh-openstack} and bare metal platforms.
 * IPv6-primary dual-stack networking for a cluster running on a bare-metal, a {vmw-full}, or an {rh-openstack} platform.
 * Egress firewall devices and egress IP addresses.
 * Egress router devices that operate in redirect mode.
diff --git a/modules/nw-ovn-kubernetes-observability.adoc b/modules/nw-ovn-kubernetes-observability.adoc
index 2ae9481ac152..a1c6ab068c1a 100644
--- a/modules/nw-ovn-kubernetes-observability.adoc
+++ b/modules/nw-ovn-kubernetes-observability.adoc
@@ -13,7 +13,7 @@ OVN-Kubernetes network traffic can be viewed with OVS sampling via the CLI for t
 * `NetworkPolicy`
 * `AdminNetworkPolicy`
 * `BaselineNetworkPolicy`
-* `UserDefinesdNetwork` isolation
+* `UserDefinedNetwork` isolation
 * `EgressFirewall`
 * Multicast ACLs. 
 
@@ -29,7 +29,7 @@ Use the following procedure to view OVN-Kubernetes network traffic using the CLI
 
 * You are logged in to the cluster as a user with `cluster-admin` privileges.
 * You have created a source pod and a destination pod and ran traffic between them.
-* You have created at least one of the following network APIs: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinesdNetwork` isolation, multicast, or egress firewalls.
+* You have created at least one of the following network APIs: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinedNetwork` isolation, multicast, or egress firewalls.
 
 .Procedure
 
diff --git a/modules/nw-patch-fields-example.adoc b/modules/nw-patch-fields-example.adoc
new file mode 100644
index 000000000000..86dc28de5ef4
--- /dev/null
+++ b/modules/nw-patch-fields-example.adoc
@@ -0,0 +1,38 @@
+// Module included in the following assemblies:
+//
+// * networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-patch-fields.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-patch-fields-example_{context}"]
+= Patching Ingress objects to resolve an ingressWithoutClassName alert
+
+The `ingressClassName` field specifies the name of the `IngressClass` object. You must define the `ingressClassName` field for each `Ingress` object.
+
+If you have not defined the `ingressClassName` field for an `Ingress` object, you could experience routing issues. After 24 hours, you will receive an `ingressWithoutClassName` alert to remind you to set the `ingressClassName` field.
+
+.Procedure
+
+Patch the `Ingress` objects with a completed `ingressClassName` field to ensure proper routing and functionality.
+
+. List all `IngressClass` objects:
++
+[source,terminal]
+----
+$ oc get ingressclass
+----
+
+. List all `Ingress` objects in all namespaces:
++
+[source,terminal]
+----
+$ oc get ingress -A
+----
+
+. Patch the `Ingress` object:
++
+[source,terminal]
+----
+$ oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'
+----
++ 
+Replace `<ingress_name>` with the name of the `Ingress` object. This command patches the `Ingress` object to include the desired ingress class name.
\ No newline at end of file
diff --git a/modules/nw-proxy-configure-object.adoc b/modules/nw-proxy-configure-object.adoc
index 4d2dc0744d25..c9e5f1b6aeba 100644
--- a/modules/nw-proxy-configure-object.adoc
+++ b/modules/nw-proxy-configure-object.adoc
@@ -102,9 +102,18 @@ spec:
 --
 <1> A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be `http`.
 <2> A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either `http` or `https`. Specify a URL for the proxy that supports the URL scheme. For example, most proxies will report an error if they are configured to use `https` but they only support `http`. This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens for `https` connections from the cluster, you may need to configure the cluster to accept the CAs and certificates that the proxy uses.
-<3> A comma-separated list of destination domain names, domains, IP addresses or other network CIDRs to exclude proxying.
+<3> A comma-separated list of destination domain names, domains, IP addresses (or other network CIDRs), and port numbers to exclude proxying.
++
+[NOTE]
+====
+Port numbers are only supported when configuring IPv6 addresses. Port numbers are not supported when configuring IPv4 addresses.
+====
 +
 Preface a domain with `.` to match subdomains only. For example, `.y.com` matches `x.y.com`, but not `y.com`. Use `*` to bypass proxy for all destinations.
++
+If your `noproxy` field needs to include a domain address, you must explicitly specify that FQDN, or prefix-matched subdomain, in the `noproxy` field. You cannot use the IP address or CIDR range that encapsulates the domain. This is because the cluster does not wait for DNS to return the IP address before assigning the route connection, and checks explicitly against the request being made.
+For example, if you have a CIDR block value, such as `10.0.0.0/24`, for the `noproxy` field and attempt to access `\https://10.0.0.11`, it will match successfully. However, attempting to access `\https://exampleserver.externaldomain.com`, whose A record entry is `10.0.0.11`, will fail. An additional value of `.externaldomain.com` for your `noproxy` field is necessary.
++
 If you scale up workers that are not included in the network defined by the `networking.machineNetwork[].cidr` field from the installation configuration, you must add them to this list to prevent connection issues.
 +
 This field is ignored if neither the `httpProxy` or `httpsProxy` fields are set.
diff --git a/modules/nw-ptp-e810-hardware-configuration-reference.adoc b/modules/nw-ptp-e810-hardware-configuration-reference.adoc
index 69a28a118ff3..6102e37a0fc1 100644
--- a/modules/nw-ptp-e810-hardware-configuration-reference.adoc
+++ b/modules/nw-ptp-e810-hardware-configuration-reference.adoc
@@ -31,19 +31,31 @@ The `SMA2` connector is bidirectional.
 ====
 
 Set `spec.profile.plugins.e810.ublxCmds` parameters to configure the GNSS clock in the `PtpConfig` custom resource (CR).
+
+[IMPORTANT]
+====
+You must configure an offset value to compensate for T-GM GPS antenna cable signal delay.
+To configure the optimal T-GM antenna offset value, make precise measurements of the GNSS antenna cable signal delay.
+Red{nbsp}Hat cannot assist in this measurement or provide any values for the required delay offsets.
+====
+
 Each of these `ublxCmds` stanzas correspond to a configuration that is applied to the host NIC by using `ubxtool` commands.
 For example:
 
 [source,yaml]
 ----
 ublxCmds:
-  - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
+  - args:
       - "-P"
       - "29.20"
       - "-z"
       - "CFG-HW-ANT_CFG_VOLTCTRL,1"
+      - "-z"
+      - "CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>"<1>
     reportOutput: false
 ----
+<1> Measured T-GM antenna delay offset in nanoseconds.
+To get the required delay offset value, you must measure the cable delay using external test equipment.
 
 The following table describes the equivalent `ubxtool` commands:
 
@@ -51,7 +63,7 @@ The following table describes the equivalent `ubxtool` commands:
 [width="90%", options="header"]
 |====
 |ubxtool command|Description
-|`ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1`|Enables antenna voltage control. Enables antenna status to be reported in the `UBX-MON-RF` and `UBX-INF-NOTICE` log messages.
+|`ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 -z CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>`|Enables antenna voltage control, allows antenna status to be reported in the `UBX-MON-RF` and `UBX-INF-NOTICE` log messages, and sets a `<antenna_delay_offset>` value in nanoseconds that offsets the GPS antenna cable signal delay.
 |`ubxtool -P 29.20 -e GPS`|Enables the antenna to receive GPS signals.
 |`ubxtool -P 29.20 -d Galileo`|Configures the antenna to receive signal from the Galileo GPS satellite.
 |`ubxtool -P 29.20 -d GLONASS`|Disables the antenna from receiving signal from the GLONASS GPS satellite.
@@ -60,41 +72,3 @@ The following table describes the equivalent `ubxtool` commands:
 |`ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000`| Configures the GNSS receiver survey-in process to improve its initial position estimate. This can take up to 24 hours to achieve an optimal result.
 |`ubxtool -P 29.20 -p MON-HW`|Runs a single automated scan of the hardware and reports on the NIC state and configuration settings.
 |====
-
-The E810 plugin implements the following interfaces:
-
-.E810 plugin interfaces
-[cols="1,3", width="90%", options="header"]
-|====
-|Interface
-|Description
-
-|`OnPTPConfigChangeE810`
-|Runs whenever you update the `PtpConfig` CR.
-The function parses the plugin options and applies the required configurations to the network device pins based on the configuration data.
-
-|`AfterRunPTPCommandE810`
-|Runs after launching the PTP processes and running the `gpspipe` PTP command.
-The function processes the plugin options and runs `ubxtool` commands, storing the output in the plugin-specific data.
-
-|`PopulateHwConfigE810`
-|Populates the `NodePtpDevice` CR based on hardware-specific data in the `PtpConfig` CR.
-|====
-
-The E810 plugin has the following structs and variables:
-
-.E810 plugin structs and variables
-[cols="1,3", width="90%", options="header"]
-|====
-|Struct
-|Description
-
-|`E810Opts`
-|Represents options for the E810 plugin, including boolean flags and a map of network device pins.
-
-|`E810UblxCmds`
-|Represents configurations for `ubxtool` commands with a boolean flag and a slice of strings for command arguments.
-
-|`E810PluginData`
-|Holds plugin-specific data used during plugin execution.
-|====
diff --git a/modules/nw-ptp-holdover-in-a-grandmaster-clock.adoc b/modules/nw-ptp-holdover-in-a-grandmaster-clock.adoc
index 678742d31af5..237325a06432 100644
--- a/modules/nw-ptp-holdover-in-a-grandmaster-clock.adoc
+++ b/modules/nw-ptp-holdover-in-a-grandmaster-clock.adoc
@@ -6,7 +6,7 @@
 [id="holdover-in-a-grandmaster-clock_{context}"]
 = Holdover in a grandmaster clock with GNSS as the source
 
-Holdover allows the grandmaster (T-GM) clock to maintain synchronization performance when the GNSS source is unavailable. During this period, the T-GM clock relies on its internal oscillator and holdover parameters to reduce timing disruptions.
+Holdover allows the grandmaster (T-GM) clock to maintain synchronization performance when the global navigation satellite system (GNSS) source is unavailable. During this period, the T-GM clock relies on its internal oscillator and holdover parameters to reduce timing disruptions.
 
 You can define the holdover behavior by configuring the following holdover parameters in the `PTPConfig` custom resource (CR):
 
@@ -37,5 +37,22 @@ The T-GM clock reaches the maximum offset in 60 seconds.
 
 [NOTE]
 ====
-The phase offset is converted from picoseconds to nanoseconds. As a result, the calculated phase offset during holdover is expressed in nanoseconds per second, and the resulting slope is measured in nanoseconds per second.
+The phase offset is converted from picoseconds to nanoseconds. As a result, the calculated phase offset during holdover is expressed in nanoseconds, and the resulting slope is expressed in nanoseconds per second.
 ====
+
+The following figure illustrates the holdover behavior in a T-GM clock with GNSS as the source:
+
+.Holdover in a T-GM clock with GNSS as the source
+image::holdover_in_t_gm.png[Holdover in a T-GM clock with GNSS as the source]
+
+image:darkcircle-1.png[20,20] The GNSS signal is lost, causing the T-GM clock to enter the `HOLDOVER` mode. The T-GM clock maintains time accuracy using its internal clock.
+
+image:darkcircle-2.png[20,20] The GNSS signal is restored and the T-GM clock re-enters the `LOCKED` mode. When the GNSS signal is restored, the T-GM clock re-enters the `LOCKED` mode only after all dependent components in the synchronization chain, such as `ts2phc` offset, digital phase-locked loop (DPLL) phase offset, and GNSS offset, reach a stable `LOCKED` mode.
+
+image:darkcircle-3.png[20,20] The GNSS signal is lost again, and the T-GM clock re-enters the `HOLDOVER` mode. The time error begins to increase.
+
+image:darkcircle-4.png[20,20] The time error exceeds the `MaxInSpecOffset` threshold due to prolonged loss of traceability.
+
+image:darkcircle-5.png[20,20] The GNSS signal is restored, and the T-GM clock resumes synchronization. The time error starts to decrease.
+
+image:darkcircle-6.png[20,20] The time error decreases and falls back within the `MaxInSpecOffset` threshold.
\ No newline at end of file
diff --git a/modules/nw-route-override-cni.adoc b/modules/nw-route-override-cni.adoc
new file mode 100644
index 000000000000..5df37ad8f41e
--- /dev/null
+++ b/modules/nw-route-override-cni.adoc
@@ -0,0 +1,84 @@
+// Module included in the following assemblies:
+//
+// * networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
+// * networking/multiple_networks/configuring-additional-network.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-route-override-cni_{context}"]
+= Configuring routes using the route-override plugin on an additional network
+
+The following object describes the configuration parameters for the `route-override` CNI plugin:
+
+.Route override CNI plugin JSON configuration object
+[cols=".^2,.^2,.^6",options="header"]
+|====
+|Field|Type|Description
+
+|`type`
+|`string`
+|The name of the CNI plugin to configure: `route-override`.
+
+|`flushroutes`
+|`boolean`
+|Optional: Set to `true` to flush any existing routes.
+
+|`flushgateway`
+|`boolean`
+|Optional: Set to `true` to flush the default route namely the gateway route.
+
+|`delroutes`
+|`object`
+|Optional: Specify the list of routes to delete from the container namespace.
+
+|`addroutes`
+|`object`
+|Optional: Specify the list of routes to add to the container namespace. Each route is a dictionary with `dst` and optional `gw` fields. If `gw` is omitted, the plugin uses the default gateway value.
+
+|`skipcheck`
+|`boolean`
+|Optional: Set this to `true` to skip the check command. By default, CNI plugins verify the network setup during the container lifecycle. When modifying routes dynamically with `route-override`, skipping this check ensures the final configuration reflects the updated routes.
+|====
+
+[id="nw-route-override-config-example_{context}"]
+== Route-override plugin configuration example
+
+The `route-override` CNI is a type of CNI that it is designed to be used when chained with a parent CNI. It does not operate independently, but relies on the parent CNI to first create the network interface and assign IP addresses before it can modify the routing rules.
+
+The following example configures an additional network named `mymacvlan`. The parent CNI creates a network interface attached to `eth1` and assigns an IP address in the `192.168.1.0/24` range using `host-local` IPAM. The `route-override` CNI is then chained to the parent CNI and modifies the routing rules by flushing existing routes, deleting the route to `192.168.0.0/24`, and adding a new route for `192.168.0.0/24` with a custom gateway. 
+
+[source,json]
+----
+{
+    "cniVersion": "0.3.0",
+    "name": "mymacvlan",
+    "plugins": [
+        {
+            "type": "macvlan",         <1>      
+            "master": "eth1",
+            "mode": "bridge",
+            "ipam": {
+                "type": "host-local",
+                "subnet": "192.168.1.0/24"
+            }
+        },
+        {
+            "type": "route-override",    <2>   
+            "flushroutes": true,
+            "delroutes": [
+                {
+                    "dst": "192.168.0.0/24"
+                }
+            ],
+            "addroutes": [
+                {
+                    "dst": "192.168.0.0/24",
+                    "gw": "10.1.254.254"
+                }
+            ]
+        }
+    ]
+}
+----
+
+<1> The parent CNI creates a network interface attached to `eth1`.
+<2> The chained `route-override` CNI modifies the routing rules. 
\ No newline at end of file
diff --git a/modules/nw-route-specific-annotations.adoc b/modules/nw-route-specific-annotations.adoc
index 6793eb73f419..f774f91a2f43 100644
--- a/modules/nw-route-specific-annotations.adoc
+++ b/modules/nw-route-specific-annotations.adoc
@@ -19,7 +19,7 @@ To create an allow list with multiple source IPs or subnets, use a space-delimit
 [cols="3*", options="header"]
 |===
 |Variable | Description | Environment variable used as default
-|`haproxy.router.openshift.io/balance`| Sets the load-balancing algorithm. Available options are `random`, `source`, `roundrobin`, and `leastconn`.  The default value is `source` for TLS passthrough routes. For all other routes, the default is `random`. |`ROUTER_TCP_BALANCE_SCHEME` for passthrough routes. Otherwise, use `ROUTER_LOAD_BALANCE_ALGORITHM`.
+|`haproxy.router.openshift.io/balance`| Sets the load-balancing algorithm. Available options are `random`, `source`, `roundrobin`[^1^], and `leastconn`.  The default value is `source` for TLS passthrough routes. For all other routes, the default is `random`. |`ROUTER_TCP_BALANCE_SCHEME` for passthrough routes. Otherwise, use `ROUTER_LOAD_BALANCE_ALGORITHM`.
 |`haproxy.router.openshift.io/disable_cookies`| Disables the use of cookies to track related connections. If set to `'true'` or `'TRUE'`, the balance algorithm is used to choose which back-end serves connections for each incoming HTTP request. |
 |`router.openshift.io/cookie_name`| Specifies an optional cookie to use for
 this route. The name must consist of any combination of upper and lower case letters, digits, "_",
@@ -41,7 +41,7 @@ Note: Using this annotation provides basic protection against denial-of-service
 |`haproxy.router.openshift.io/ip_allowlist`
 | Sets an allowlist for the route. The allowlist is a space-separated list of IP addresses and CIDR ranges for the approved source addresses. Requests from IP addresses that are not in the allowlist are dropped.
 
-The maximum number of IP addresses and CIDR ranges directly visible in the `haproxy.config` file is 61. [^1^] |
+The maximum number of IP addresses and CIDR ranges directly visible in the `haproxy.config` file is 61. [^2^] |
 
 |`haproxy.router.openshift.io/hsts_header` | Sets a Strict-Transport-Security header for the edge terminated or re-encrypt route. |
 |`haproxy.router.openshift.io/rewrite-target` | Sets the rewrite path of the request on the backend. |
@@ -68,7 +68,8 @@ This value is applicable to re-encrypt and edge routes only. For more informatio
 |===
 [.small]
 --
-1. If the number of IP addresses and CIDR ranges in an allowlist exceeds 61, they are written into a separate file that is then referenced from `haproxy.config`. This file is stored in the `var/lib/haproxy/router/allowlists` folder.
+1. By default, the router reloads every 5 s which resets the balancing connection across pods from the beginning. As a result, the `roundrobin` state is not preserved across reloads. This algorithm works best when pods have nearly identical computing capabilites and storage capacity. If your application or service has continuously changing endpoints, for example, due to the use of a CI/CD pipeline, uneven balancing can result. In this case, use a different algorithm.
+2. If the number of IP addresses and CIDR ranges in an allowlist exceeds 61, they are written into a separate file that is then referenced from the `haproxy.config` file. This file is stored in the `/var/lib/haproxy/router/allowlists` folder.
 +
 [NOTE]
 ====
diff --git a/modules/nw-sr-iov-network-node-configuration-examples.adoc b/modules/nw-sr-iov-network-node-configuration-examples.adoc
new file mode 100644
index 000000000000..6d83bf3a9a82
--- /dev/null
+++ b/modules/nw-sr-iov-network-node-configuration-examples.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// * networking/hardware_networks/configuring-sriov-device.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-sr-iov-network-node-configuration-examples_{context}"]
+= SR-IOV network node configuration examples
+
+The following example describes the configuration for an InfiniBand device:
+
+.Example configuration for an InfiniBand device
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetworkNodePolicy
+metadata:
+  name: <name>
+  namespace: openshift-sriov-network-operator
+spec:
+  resourceName: <sriov_resource_name>
+  nodeSelector:
+    feature.node.kubernetes.io/network-sriov.capable: "true"
+  numVfs: <num>
+  nicSelector:
+    vendor: "<vendor_code>"
+    deviceID: "<device_id>"
+    rootDevices:
+      - "<pci_bus_id>"
+  linkType: <link_type>
+  isRdma: true
+# ...
+----
+
+The following example describes the configuration for an SR-IOV network device in a {rh-openstack} virtual machine:
+
+.Example configuration for an SR-IOV device in a virtual machine
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovNetworkNodePolicy
+metadata:
+  name: <name>
+  namespace: openshift-sriov-network-operator
+spec:
+  resourceName: <sriov_resource_name>
+  nodeSelector:
+    feature.node.kubernetes.io/network-sriov.capable: "true"
+  numVfs: 1 <1>
+  nicSelector:
+    vendor: "<vendor_code>"
+    deviceID: "<device_id>"
+    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" <2>
+# ...
+----
+<1> When configuring the node network policy for a virtual machine, the `numVfs` parameter is always set to `1`.
+<2> When the virtual machine is deployed on {rh-openstack}, the `netFilter` parameter must refer to a network ID. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object.
+
diff --git a/modules/nw-sriov-configuring-operator.adoc b/modules/nw-sriov-configuring-operator.adoc
index dcfabf6b1c86..211be629915f 100644
--- a/modules/nw-sriov-configuring-operator.adoc
+++ b/modules/nw-sriov-configuring-operator.adoc
@@ -15,21 +15,20 @@
 apiVersion: sriovnetwork.openshift.io/v1
 kind: SriovOperatorConfig
 metadata:
-  name: default 
+  name: default <1>
   namespace: openshift-sriov-network-operator 
 spec:
   disableDrain: false
-  enableInjector: true
-  enableOperatorWebhook: true
+  enableInjector: true <2>
+  enableOperatorWebhook: true <3>
   logLevel: 2
   featureGates:
     metricsExporter: false
 ----
 +
-[NOTE]
-====
-The only valid name for the `SriovOperatorConfig` resource is `default` and it must be in the namespace where the Operator is deployed. 
-====
+<1> The only valid name for the `SriovOperatorConfig` resource is `default` and it must be in the namespace where the Operator is deployed. 
+<2> The `enableInjector` field, if not specified in the CR or explicitly set to `true`, defaults to `false` or `<none>`, preventing any `network-resources-injector` pod from running in the namespace. The recommended setting is `true`. 
+<3> The `enableOperatorWebhook` field, if not specified in the CR or explicitly set to true, defaults to `false` or `<none>`, preventing any `operator-webhook` pod from running in the namespace. The recommended setting is `true`. 
 
 .. Create the resource by running the following command:
 +
@@ -75,12 +74,11 @@ For single-node clusters, set this field to `true` after installing the Operator
 |`spec.enableInjector`
 |`boolean`
 |Specifies whether to enable or disable the Network Resources Injector daemon set.
-By default, this field is set to `true`.
 
 |`spec.enableOperatorWebhook`
 |`boolean`
 |Specifies whether to enable or disable the Operator Admission Controller webhook daemon set.
-By default, this field is set to `true`.
+
 
 |`spec.logLevel`
 |`integer`
@@ -96,18 +94,24 @@ By default, this field is set to `2`.
 |`boolean`
 |Specifies whether to enable or disable the SR-IOV Network Operator metrics. By default, this field is set to `false`.
 
+|`spec.featureGates.mellanoxFirmwareReset`
+|`boolean`
+|Specifies whether to reset the firmware on virtual function (VF) changes in the SR-IOV Network Operator. Some chipsets, such as the Intel C740 Series, do not completely power off the PCI-E devices, which is required to configure VFs on NVIDIA/Mellanox NICs. By default, this field is set to `false`.
+
+:FeatureName: The `spec.featureGates.mellanoxFirmwareReset` parameter
+include::snippets/technology-preview.adoc[]
+
 |====
 
 [id="about-network-resource-injector_{context}"]
 == About the Network Resources Injector
 
-The Network Resources Injector is a Kubernetes Dynamic Admission Controller
-application. It provides the following capabilities:
+The Network Resources Injector is a Kubernetes Dynamic Admission Controller application, which provides the following capabilities:
 
 * Mutation of resource requests and limits in a pod specification to add an SR-IOV resource name according to an SR-IOV network attachment definition annotation.
 * Mutation of a pod specification with a Downward API volume to expose pod annotations, labels, and huge pages requests and limits. Containers that run in the pod can access the exposed information as files under the `/etc/podnetinfo` path.
 
-By default, the Network Resources Injector is enabled by the SR-IOV Network Operator and runs as a daemon set on all control plane nodes. The following is an example of Network Resources Injector pods running in a cluster with three control plane nodes:
+The Network Resources Injector is enabled by the SR-IOV Network Operator when the `enableInjector` is set to `true` in the `SriovOperatorConfig` CR. The `network-resources-injector` pod runs as a daemon set on all control plane nodes. The following is an example of Network Resources Injector pods running in a cluster with three control plane nodes:
 
 [source,terminal]
 ----
@@ -123,49 +127,33 @@ network-resources-injector-dwqpx          1/1     Running   0          10m
 network-resources-injector-lktz5          1/1     Running   0          10m
 ----
 
-[id="about-sr-iov-operator-admission-control-webhook_{context}"]
-== About the SR-IOV Network Operator admission controller webhook
-
-The SR-IOV Network Operator Admission Controller webhook is a Kubernetes Dynamic
-Admission Controller application. It provides the following capabilities:
+By default, the `failurePolicy` field in the Network Resources Injector webhook is set to `Ignore`. This default setting prevents pod creation from being blocked if the webhook is unavailable.
 
-* Validation of the `SriovNetworkNodePolicy` CR when it is created or updated.
-* Mutation of the `SriovNetworkNodePolicy` CR by setting the default value for the `priority` and `deviceType` fields when the CR is created or updated.
-
-By default the SR-IOV Network Operator Admission Controller webhook is enabled by the Operator and runs as a daemon set on all control plane nodes.
-
-[NOTE]
-====
-Use caution when disabling the SR-IOV Network Operator Admission Controller webhook. You can disable the webhook under specific circumstances, such as troubleshooting, or if you want to use unsupported devices. For information about configuring unsupported devices, see link:https://access.redhat.com/articles/7010183[Configuring the SR-IOV Network Operator to use an unsupported NIC].
-====
+If you set the `failurePolicy` field to `Fail`, and the Network Resources Injector webhook is unavailable, the webhook attempts to mutate all pod creation and update requests. This behavior can block pod creation and disrupt normal cluster operations. To prevent such issues, you can enable the `featureGates.resourceInjectorMatchCondition` feature in the `SriovOperatorConfig` object to limit the scope of the Network Resources Injector webhook. If this feature is enabled, the webhook applies only to pods with the secondary network annotation `k8s.v1.cni.cncf.io/networks`.
 
-The following is an example of the Operator Admission Controller webhook pods running in a cluster with three control plane nodes:
+If you set the `failurePolicy` field to `Fail` after enabling the `resourceInjectorMatchCondition` feature, the webhook applies only to pods with the secondary network annotation `k8s.v1.cni.cncf.io/networks`. If the webhook is unavailable, pods without this annotation are still deployed, preventing unnecessary disruptions to cluster operations.
 
-[source,terminal]
-----
-$ oc get pods -n openshift-sriov-network-operator
-----
+The `featureGates.resourceInjectorMatchCondition` feature is disabled by default. To enable this feature, set the `featureGates.resourceInjectorMatchCondition` field to `true` in the `SriovOperatorConfig` object.
 
-.Example output
-[source,terminal]
+.Example `SriovOperatorConfig` object configuration
+[source,yaml]
 ----
-NAME                                      READY   STATUS    RESTARTS   AGE
-operator-webhook-9jkw6                    1/1     Running   0          16m
-operator-webhook-kbr5p                    1/1     Running   0          16m
-operator-webhook-rpfrl                    1/1     Running   0          16m
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovOperatorConfig
+metadata:
+  name: default
+  namespace: sriov-network-operator
+spec:
+# ...
+  featureGates:
+    resourceInjectorMatchCondition: true
+# ...
 ----
 
-[id="about-custom-node-selectors_{context}"]
-== About custom node selectors
-
-The SR-IOV Network Config daemon discovers and configures the SR-IOV network devices on cluster nodes.
-By default, it is deployed to all the `worker` nodes in the cluster.
-You can use node labels to specify on which nodes the SR-IOV Network Config daemon runs.
-
 [id="disable-enable-network-resource-injector_{context}"]
 == Disabling or enabling the Network Resources Injector
 
-To disable or enable the Network Resources Injector, which is enabled by default, complete the following procedure.
+To disable or enable the Network Resources Injector, complete the following procedure.
 
 .Prerequisites
 
@@ -200,10 +188,41 @@ spec:
 ----
 ====
 
+[id="about-sr-iov-operator-admission-control-webhook_{context}"]
+== About the SR-IOV Network Operator admission controller webhook
+
+The SR-IOV Network Operator Admission Controller webhook is a Kubernetes Dynamic Admission Controller application. It provides the following capabilities:
+
+* Validation of the `SriovNetworkNodePolicy` CR when it is created or updated.
+* Mutation of the `SriovNetworkNodePolicy` CR by setting the default value for the `priority` and `deviceType` fields when the CR is created or updated.
+
+The SR-IOV Network Operator Admission Controller webhook is enabled by the Operator when the `enableOperatorWebhook` is set to `true` in the `SriovOperatorConfig` CR. The `operator-webhook` pod runs as a daemon set on all control plane nodes.
+
+[NOTE]
+====
+Use caution when disabling the SR-IOV Network Operator Admission Controller webhook. You can disable the webhook under specific circumstances, such as troubleshooting, or if you want to use unsupported devices. For information about configuring unsupported devices, see link:https://access.redhat.com/articles/7010183[Configuring the SR-IOV Network Operator to use an unsupported NIC].
+====
+
+The following is an example of the Operator Admission Controller webhook pods running in a cluster with three control plane nodes:
+
+[source,terminal]
+----
+$ oc get pods -n openshift-sriov-network-operator
+----
+
+.Example output
+[source,terminal]
+----
+NAME                                      READY   STATUS    RESTARTS   AGE
+operator-webhook-9jkw6                    1/1     Running   0          16m
+operator-webhook-kbr5p                    1/1     Running   0          16m
+operator-webhook-rpfrl                    1/1     Running   0          16m
+----
+
 [id="disable-enable-sr-iov-operator-admission-control-webhook_{context}"]
 == Disabling or enabling the SR-IOV Network Operator admission controller webhook
 
-To disable or enable the admission controller webhook, which is enabled by default, complete the following procedure.
+To disable or enable the admission controller webhook, complete the following procedure.
 
 .Prerequisites
 
@@ -238,6 +257,13 @@ spec:
 ----
 ====
 
+[id="about-custom-node-selectors_{context}"]
+== About custom node selectors
+
+The SR-IOV Network Config daemon discovers and configures the SR-IOV network devices on cluster nodes.
+By default, it is deployed to all the `worker` nodes in the cluster.
+You can use node labels to specify on which nodes the SR-IOV Network Config daemon runs.
+
 [id="configuring-custom-nodeselector_{context}"]
 == Configuring a custom NodeSelector for the SR-IOV Network Config daemon
 
diff --git a/modules/nw-sriov-expose-mtu.adoc b/modules/nw-sriov-expose-mtu.adoc
index 5616c0678e5d..60ea999af1c5 100644
--- a/modules/nw-sriov-expose-mtu.adoc
+++ b/modules/nw-sriov-expose-mtu.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
-// * networking/hardware_networks/add-pod.adoc
+// * networking/hardware_networks/configuring-sriov-ib-attach.adoc
+// * networking/hardware_networks/configuring-sriov-net-attach.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="nw-sriov-expose-mtu_{context}"]
diff --git a/modules/nw-sriov-networknodepolicy-object.adoc b/modules/nw-sriov-networknodepolicy-object.adoc
index 086c07f44453..f955a91f677e 100644
--- a/modules/nw-sriov-networknodepolicy-object.adoc
+++ b/modules/nw-sriov-networknodepolicy-object.adoc
@@ -120,55 +120,3 @@ Do not set linkType to `eth` for SriovNetworkNodePolicy, because this can lead t
 <19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading, see "Configuring hardware offloading".
 
 <20> Optional: To exclude advertising an SR-IOV network resource's NUMA node to the Topology Manager, set the value to `true`. The default value is `false`.
-
-[id="sr-iov-network-node-configuration-examples_{context}"]
-== SR-IOV network node configuration examples
-
-The following example describes the configuration for an InfiniBand device:
-
-.Example configuration for an InfiniBand device
-[source,yaml]
-----
-apiVersion: sriovnetwork.openshift.io/v1
-kind: SriovNetworkNodePolicy
-metadata:
-  name: policy-ib-net-1
-  namespace: openshift-sriov-network-operator
-spec:
-  resourceName: ibnic1
-  nodeSelector:
-    feature.node.kubernetes.io/network-sriov.capable: "true"
-  numVfs: 4
-  nicSelector:
-    vendor: "15b3"
-    deviceID: "101b"
-    rootDevices:
-      - "0000:19:00.0"
-  linkType: ib
-  isRdma: true
-----
-
-The following example describes the configuration for an SR-IOV network device in a {rh-openstack} virtual machine:
-
-.Example configuration for an SR-IOV device in a virtual machine
-[source,yaml]
-----
-apiVersion: sriovnetwork.openshift.io/v1
-kind: SriovNetworkNodePolicy
-metadata:
-  name: policy-sriov-net-openstack-1
-  namespace: openshift-sriov-network-operator
-spec:
-  resourceName: sriovnic1
-  nodeSelector:
-    feature.node.kubernetes.io/network-sriov.capable: "true"
-  numVfs: 1 <1>
-  nicSelector:
-    vendor: "15b3"
-    deviceID: "101b"
-    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" <2>
-----
-
-<1> The `numVfs` field is always set to `1` when configuring the node network policy for a virtual machine.
-
-<2> The `netFilter` field must refer to a network ID when the virtual machine is deployed on {rh-openstack}. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object.
diff --git a/modules/nw-sriov-nic-mlx-secure-boot.adoc b/modules/nw-sriov-nic-mlx-secure-boot.adoc
new file mode 100644
index 000000000000..68cfd04a14ef
--- /dev/null
+++ b/modules/nw-sriov-nic-mlx-secure-boot.adoc
@@ -0,0 +1,84 @@
+// Module included in the following assemblies:
+//
+// * networking/hardware_networks/configuring-sriov-device.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-sriov-nic-mlx-secure-boot_{context}"]
+= Configuring the SR-IOV Network Operator on Mellanox cards when Secure Boot is enabled
+
+The SR-IOV Network Operator supports an option to skip the firmware configuration for Mellanox devices. This option allows you to create virtual functions by using the SR-IOV Network Operator when the system has secure boot enabled. You must manually configure and allocate the number of virtual functions in the firmware before switching the system to secure boot.
+
+[NOTE]
+====
+The number of virtual functions in the firmware is the maximum number of virtual functions that you can request in the policy.
+====
+
+.Procedure
+
+. Configure the virtual functions (VFs) by running the following command when the system is without a secure boot when using the sriov-config daemon:
++
+[source,terminal]
+----
+$ mstconfig -d -0001:b1:00.1 set SRIOV_EN=1 NUM_OF_VFS=16 <1> <2>
+----
+<1> The `SRIOV_EN` environment variable enables the SR-IOV Network Operator support on the Mellanox card.
+<2> The `NUM_OF_VFS` environment variable specifies the number of virtual functions to enable in the firmware.
+
+. Configure the SR-IOV Network Operator by disabling the Mellanox plugin. See the following `SriovOperatorConfig` example configuration:
++
+[source,yaml]
+----
+apiVersion: sriovnetwork.openshift.io/v1
+kind: SriovOperatorConfig
+metadata:
+  name: default
+  namespace: openshift-sriov-network-operator
+spec:
+  configDaemonNodeSelector: {}
+  configurationMode: daemon
+  disableDrain: false
+  disablePlugins:
+  - mellanox
+  enableInjector: true
+  enableOperatorWebhook: true
+  logLevel: 2
+----
+
+. Reboot the system to enable the virtual functions and the configuration settings.
+
+. Check the virtual functions (VFs) after rebooting the system by running the following command:
++
+[source,terminal]
+----
+$ oc -n openshift-sriov-network-operator get sriovnetworknodestate.sriovnetwork.openshift.io worker-0 -oyaml
+----
++
+.Example output 
+[source,yaml]
+----
+- deviceID: 101d
+    driver: mlx5_core
+    eSwitchMode: legacy
+    linkSpeed: -1 Mb/s
+    linkType: ETH
+    mac: 08:c0:eb:96:31:25
+    mtu: 1500
+    name: ens3f1np1
+    pciAddress: 0000:b1:00.1 <1>
+    totalvfs: 16
+    vendor: 15b3
+----
+<1> The `totalvfs` value is the same number used in the `mstconfig` command earlier in the procedure. 
+
+. Enable secure boot to prevent unauthorized operating systems and malicious software from loading during the device's boot process. 
+
+.. Enable secure boot using the BIOS (Basic Input/Output System).
++
+[source,terminal]
+----
+Secure Boot: Enabled
+Secure Boot Policy: Standard
+Secure Boot Mode: Mode Deployed
+----
+
+.. Reboot the system.
diff --git a/modules/nw-sriov-runtime-config.adoc b/modules/nw-sriov-runtime-config-ethernet.adoc
similarity index 52%
rename from modules/nw-sriov-runtime-config.adoc
rename to modules/nw-sriov-runtime-config-ethernet.adoc
index 07b34087c3f2..3973ea05a93b 100644
--- a/modules/nw-sriov-runtime-config.adoc
+++ b/modules/nw-sriov-runtime-config-ethernet.adoc
@@ -1,17 +1,15 @@
 // Module included in the following assemblies:
 //
-// * networking/hardware_networks/add-pod.adoc
+// * networking/hardware_networks/configuring-sriov-net-attach.adoc
 
-[id="nw-sriov-runtime-config_{context}"]
-= Runtime configuration for a network attachment
+:_mod-docs-content-type: REFERENCE
+[id="nw-sriov-runtime-config-ethernet_{context}"]
+= Runtime configuration for an Ethernet-based SR-IOV attachment
 
 When attaching a pod to an additional network, you can specify a runtime configuration to make specific customizations for the pod. For example, you can request a specific MAC hardware address.
 
 You specify the runtime configuration by setting an annotation in the pod specification. The annotation key is `k8s.v1.cni.cncf.io/networks`, and it accepts a JSON object that describes the runtime configuration.
 
-[id="runtime-config-ethernet_{context}"]
-== Runtime configuration for an Ethernet-based SR-IOV attachment
-
 The following JSON describes the runtime configuration options for an Ethernet-based SR-IOV network attachment.
 
 [source,json]
@@ -51,46 +49,3 @@ spec:
     imagePullPolicy: IfNotPresent
     command: ["sleep", "infinity"]
 ----
-
-[id="runtime-config-infiniband_{context}"]
-== Runtime configuration for an InfiniBand-based SR-IOV attachment
-
-The following JSON describes the runtime configuration options for an InfiniBand-based SR-IOV network attachment.
-
-[source,json]
-----
-[
-  {
-    "name": "<network_attachment>", <1>
-    "infiniband-guid": "<guid>", <2>
-    "ips": ["<cidr_range>"] <3>
-  }
-]
-----
-<1> The name of the SR-IOV network attachment definition CR.
-<2> The InfiniBand GUID for the SR-IOV device. To use this feature, you also must specify `{ "infinibandGUID": true }` in the `SriovIBNetwork` object.
-<3> The IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovIBNetwork` object.
-
-.Example runtime configuration
-[source,yaml]
-----
-apiVersion: v1
-kind: Pod
-metadata:
-  name: sample-pod
-  annotations:
-    k8s.v1.cni.cncf.io/networks: |-
-      [
-        {
-          "name": "ib1",
-          "infiniband-guid": "c2:11:22:33:44:55:66:77",
-          "ips": ["192.168.10.1/24", "2001::1/64"]
-        }
-      ]
-spec:
-  containers:
-  - name: sample-container
-    image: <image>
-    imagePullPolicy: IfNotPresent
-    command: ["sleep", "infinity"]
-----
diff --git a/modules/nw-sriov-runtime-config-sriov-ib.adoc b/modules/nw-sriov-runtime-config-sriov-ib.adoc
new file mode 100644
index 000000000000..ddc9ba23f4c5
--- /dev/null
+++ b/modules/nw-sriov-runtime-config-sriov-ib.adoc
@@ -0,0 +1,51 @@
+// Module included in the following assemblies:
+//
+// * networking/hardware_networks/configuring-sriov-ib-attach.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-sriov-runtime-config-sriov-ib_{context}"]
+= Runtime configuration for an InfiniBand-based SR-IOV attachment
+
+When attaching a pod to an additional network, you can specify a runtime configuration to make specific customizations for the pod. For example, you can request a specific MAC hardware address.
+
+You specify the runtime configuration by setting an annotation in the pod specification. The annotation key is `k8s.v1.cni.cncf.io/networks`, and it accepts a JSON object that describes the runtime configuration.
+
+The following JSON describes the runtime configuration options for an InfiniBand-based SR-IOV network attachment.
+
+[source,json]
+----
+[
+  {
+    "name": "<network_attachment>", <1>
+    "infiniband-guid": "<guid>", <2>
+    "ips": ["<cidr_range>"] <3>
+  }
+]
+----
+<1> The name of the SR-IOV network attachment definition CR.
+<2> The InfiniBand GUID for the SR-IOV device. To use this feature, you also must specify `{ "infinibandGUID": true }` in the `SriovIBNetwork` object.
+<3> The IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovIBNetwork` object.
+
+.Example runtime configuration
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: sample-pod
+  annotations:
+    k8s.v1.cni.cncf.io/networks: |-
+      [
+        {
+          "name": "ib1",
+          "infiniband-guid": "c2:11:22:33:44:55:66:77",
+          "ips": ["192.168.10.1/24", "2001::1/64"]
+        }
+      ]
+spec:
+  containers:
+  - name: sample-container
+    image: <image>
+    imagePullPolicy: IfNotPresent
+    command: ["sleep", "infinity"]
+----
diff --git a/modules/nw-sriov-supported-devices.adoc b/modules/nw-sriov-supported-devices.adoc
index c87646bdaf98..c681343fda8c 100644
--- a/modules/nw-sriov-supported-devices.adoc
+++ b/modules/nw-sriov-supported-devices.adoc
@@ -77,6 +77,31 @@
 |8086
 |1593
 
+|Intel
+|Ice E810-XXV Backplane
+|8086
+|1599
+
+|Intel
+|Ice E823L Backplane
+|8086
+|124c
+
+|Intel
+|Ice E823L SFP
+|8086
+|124d
+
+|Marvell
+|OCTEON Fusion CNF105XX
+|177d
+|ba00
+
+|Marvell
+|OCTEON10 CN10XXX
+|1177d
+|b900
+
 |Mellanox
 |MT27700 Family [ConnectX&#8209;4]
 |15b3
diff --git a/modules/nw-sriov-topology-manager.adoc b/modules/nw-sriov-topology-manager.adoc
index 232085025f7f..607ef62c4f90 100644
--- a/modules/nw-sriov-topology-manager.adoc
+++ b/modules/nw-sriov-topology-manager.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/hardware_networks/add-pod.adoc
+// * networking/hardware_networks/configuring-sriov-device.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="nw-sriov-topology-manager_{context}"]
diff --git a/modules/nw-udn-about.adoc b/modules/nw-udn-about.adoc
new file mode 100644
index 000000000000..9d5e3a6317f8
--- /dev/null
+++ b/modules/nw-udn-about.adoc
@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="about-udn_{context}"]
+= About the UserDefinedNetwork CR
+
+The `UserDefinedNetwork` (UDN) custom resource (CR) provides advanced network segmentation and isolation for users and administrators.
+
+The following diagram shows four cluster namespaces, where each namespace has a single assigned user-defined network (UDN), and each UDN has an assigned custom subnet for its pod IP allocations. The OVN-Kubernetes handles any overlapping UDN subnets. Without using the Kubernetes network policy, a pod attached to a UDN can communicate with other pods in that UDN. By default, these pods are isolated from communicating with pods that exist in other UDNs. For microsegmentation, you can apply network policy within a UDN. You can assign one or more UDNs to a namespace, with a limitation of only one primary UDN to a namespace, and one or more namespaces to a UDN.
+
+.Namespace isolation using a UserDefinedNetwork CR
+image::527-OpenShift-UDN-isolation-012025.png[The namespace isolation concept in a user-defined network (UDN)]
\ No newline at end of file
diff --git a/modules/nw-udn-additional-config-details.adoc b/modules/nw-udn-additional-config-details.adoc
index 7b8926ee2f18..32167e15da22 100644
--- a/modules/nw-udn-additional-config-details.adoc
+++ b/modules/nw-udn-additional-config-details.adoc
@@ -1,12 +1,12 @@
 //module included in the following assembly:
 //
-// *networking/multiple_networks/understanding-user-defined-networks.adoc
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="nw-udn-additional-config-details_{context}"]
-== Additional configuration details for a UserDefinedNetworks CR
+= Additional configuration details for user-defined networks
 
-The following table explains additional configurations for UDN that are optional. It is not recommended to set these fields without explicit need and understanding of OVN-Kubernetes network topology.
+The following table explains additional configurations for `ClusterUserDefinedNetwork` and `UserDefinedNetwork` custom resources (CRs) that are optional. It is not recommended to set these fields without explicit need and understanding of OVN-Kubernetes network topology.
 
 .`UserDefinedNetworks` optional configurations
 [cols="1,1,7", options="header"]
@@ -20,12 +20,25 @@ The following table explains additional configurations for UDN that are optional
 
 The `joinSubnets` field configures the routing between different segments within a user-defined network. Dual-stack clusters can set 2 subnets, one for each IP family; otherwise, only 1 subnet is allowed. This field is only allowed for the `Primary` network.
 
-|`spec.IPAMLifecycle`
+|`spec.ipam.lifecycle`
 |object
-|The `IPAMLifecycle` field configures the IP address management system (IPAM). You might use this field for virtual workloads to ensure persistent IP addresses. This field is allowed when `topology` is `layer2`. The `subnets` field must be specified when this field is specified. Setting a value of `Persistent` ensures that your virtual workloads have persistent IP addresses across reboots and migration. These are assigned by the container network interface (CNI) and used by OVN-Kubernetes to program pod IP addresses. You must not change this for pod annotations.
+|The `spec.ipam.lifecycle` field configures the IP address management system (IPAM). You might use this field for virtual workloads to ensure persistent IP addresses. The only allowed value is `Persistent`, which 
+ensures that your virtual workloads have persistent IP addresses across reboots and migration. These are assigned by the container network interface (CNI) and used by OVN-Kubernetes to program pod IP addresses. You must not change this for pod annotations. 
+
+Setting a value of `Persistent` is only supported when `spec.ipam.mode` is set to `Enabled`. 
+
+|`spec.ipam.mode`
+|object
+|The `spec.ipam.mode` field controls how much of the IP configuration is managed by OVN-Kubernetes. The following options are available:
+
+**Enabled:** +
+When enabled, OVN-Kubernetes applies the IP configuration to the SDN infrastructure and assigns IP addresses from the selected subnet to the individual pods. This is the default setting. When set to `Enabled`, the `subnets` field must be defined. `Enabled` is the default configuration.
+
+**Disabled:** +
+When disabled, OVN-Kubernetes only assigns MAC addresses and provides layer 2 communication, which allows users to configure IP addresses. `Disabled` is only available for layer 2 (secondary) networks. By disabling IPAM, features that rely on selecting pods by IP, for example, network policy, services, and so on, no longer function. Additionally, IP port security is also disabled for interfaces attached to this network. The `subnets` field must be empty when `spec.ipam.mode` is set to `Disabled.`
 
 |`spec.layer2.mtu` and `spec.layer3.mtu`
 |integer
-|The maximum transmission units (MTU). The default value is `1400`. The boundary for IPv4 is `574`, and for IPv6 it is `1280`.
+|The maximum transmission units (MTU). The default value is `1400`. The boundary for IPv4 is `576`, and for IPv6 it is `1280`.
 
 |====
\ No newline at end of file
diff --git a/modules/nw-udn-benefits.adoc b/modules/nw-udn-benefits.adoc
index b0117fe1b063..f36243b26ebb 100644
--- a/modules/nw-udn-benefits.adoc
+++ b/modules/nw-udn-benefits.adoc
@@ -13,7 +13,7 @@ User-defined networks provide the following benefits:
 
 . Network flexibility
 +
-* **Layer 2 and layer 3 support**: Cluster administrators can configure primary networks as layer 2 or layer 3 network types. This provides the flexibility of a secondary network to the primary network.
+* **Layer 2 and layer 3 support**: Cluster administrators can configure primary networks as layer 2 or layer 3 network types.
 
 . Simplified network management
 +
@@ -29,4 +29,8 @@ User-defined networks provide the following benefits:
 +
 * **Network parity**: With user-defined networking, the migration of applications from OpenStack to {product-title} is simplified by providing similar network isolation and configuration options.
 
-Developers and administrators can create a user-defined network that is namespace scoped using the custom resource. An overview of the process is: create a namespace, create and configure the custom resource, create pods in the namespace.
\ No newline at end of file
+Developers and administrators can create a user-defined network that is namespace scoped using the custom resource. An overview of the process is as follows:
+
+. An administrator creates a namespace for a user-defined network with the `k8s.ovn.org/primary-user-defined-network` label.
+. The `UserDefinedNetwork` CR is created by either the cluster administrator or the user.
+. The user creates pods in the namespace.
\ No newline at end of file
diff --git a/modules/nw-udn-best-practices.adoc b/modules/nw-udn-best-practices.adoc
index afff32b3551f..98882df02494 100644
--- a/modules/nw-udn-best-practices.adoc
+++ b/modules/nw-udn-best-practices.adoc
@@ -1,33 +1,48 @@
 //module included in the following assembly:
 //
-// *networkking/multiple_networks/understanding-user-defined-networks.adoc
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="considerations-for-udn_{context}"]
-= Best practices for UserDefinedNetwork
+= Best practices for UserDefinedNetwork CRs
 
-Before setting up a `UserDefinedNetwork` (UDN) resource, users should consider the following information:
+Before setting up a `UserDefinedNetwork` custom resource (CR), you should consider the following information:
 
 //These will not go live till 4.18 GA
 //* To eliminate errors and ensure connectivity, you should create a namespace scoped UDN CR before creating any workload in the namespace.
 
 //* You might want to allow access to any Kubernetes services on the cluster default  network. By default, KAPI and DNS are accessible.
 
-* `openshift-*` namespaces should not be used to set up a UDN.
+* `openshift-*` namespaces should not be used to set up a `UserDefinedNetwork` CR.
+
+* `UserDefinedNetwork` CRs should not be created in the default namespace. This can result in no isolation and, as a result, could introduce security risks to the cluster.
+
+* For primary networks, the namespace used for the `UserDefinedNetwork` CR must include the `k8s.ovn.org/primary-user-defined-network` label. This label cannot be updated, and can only be added when the namespace is created. The following conditions apply with the `k8s.ovn.org/primary-user-defined-network` namespace label:
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a pod is created, the pod attaches itself to the default network.
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a primary `UserDefinedNetwork` CR is created that matches the namespace, a status error is reported and the network is not created.
+
+** If the namespace is missing the `k8s.ovn.org/primary-user-defined-network` label and a primary `UserDefinedNetwork` CR already exists, a pod in the namespace is created and attached to the default network.
+
+** If the namespace _has_ the label, and a primary `UserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `UserDefinedNetwork` CR is created.
 
 * 2 masquerade IP addresses are required for user defined networks. You must reconfigure your masquerade subnet to be large enough to hold the required number of networks.
 +
 [IMPORTANT]
 ====
 * For {product-title} 4.17 and later, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should be avoided by users. For updated clusters, there is no change to the default masquerade subnet.
-* Changing the cluster's masquerade subnet is unsupported after a user-defined network has been configured for a project. Attempting to modify the masquerade subnet after a UDN has been set up can disrupt the network connectivity and cause configuration issues.
+* Changing the cluster's masquerade subnet is unsupported after a user-defined network has been configured for a project. Attempting to modify the masquerade subnet after a `UserDefinedNetwork` CR has been set up can disrupt the network connectivity and cause configuration issues.
 ====
 // May be something that is downstream only.
 //* No active primary UDN managed pod can also be a candidate for `v1.multus-cni.io/default-network`
 
-* Ensure tenants are using the `UserDefinedNetwork` resource and not the `NetworkAttachmentDefinition` (NAD) resource. This can create security risks between tenants.
+* Ensure tenants are using the `UserDefinedNetwork` resource and not the `NetworkAttachmentDefinition` (NAD) CR. This can create security risks between tenants.
+
+* When creating network segmentation, you should only use the `NetworkAttachmentDefinition` CR if user-defined network segmentation cannot be completed using the `UserDefinedNetwork` CR.
 
-* When creating network segmentation, you should only use the NAD resource if user-defined network segmentation cannot be completed using the UDN resource.
+* The cluster subnet and services CIDR for a `UserDefinedNetwork` CR cannot overlap with the default cluster subnet CIDR. OVN-Kubernetes network plugin uses `100.64.0.0/16` as the default join subnet for the network. You must not use that value to configure a `UserDefinedNetwork` CR's `joinSubnets` field. If the default address values are used anywhere in the network for the cluster you must override the default values by setting the `joinSubnets` field. For more information, see "Additional configuration details for user-defined networks".
 
-* The cluster subnet and services CIDR for a UDN cannot overlap with the default cluster subnet CIDR. OVN-Kubernetes network plugin uses `100.64.0.0/16` as the default network's join subnet, you must not use that value to configure a UDN `joinSubnets` field. If the default address values are used anywhere in the cluster's network you must override it by setting the `joinSubnets` field. For more information, see "Additional configuration details for a UserDefinedNetworks CR".
+* A layer 2 topology creates a virtual switch that is distributed across all nodes in a cluster. Virtual machines and pods connect to this virtual switch so that all these components can communicate with each other within the same subnet. If you decide not to specify a layer 2 subnet, then you must manually configure IP addresses for each pod in your cluster. When not specifying a layer 2 subnet, port security is limited to preventing Media Access Control (MAC) spoofing only, and does not include IP spoofing. A layer 2 topology creates a single broadcast domain that can be challenging in large network environments, whereby the topology might cause a broadcast storm that can degrade network performance. 
 
+* A layer 3 topology creates a unique layer 2 segment for each node in a cluster. The layer 3 routing mechanism interconnects these segments so that virtual machines and pods that are hosted on different nodes can communicate with each other. A layer 3 topology can effectively manage large broadcast domains by assigning each domain to a specific node, so that broadcast traffic has a reduced scope. To configure a layer 3 topology, you must configure `cidr` and `hostSubnet` parameters.
diff --git a/modules/nw-udn-cr-ui.adoc b/modules/nw-udn-cr-ui.adoc
new file mode 100644
index 000000000000..1ccbaa085bc5
--- /dev/null
+++ b/modules/nw-udn-cr-ui.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: PROCEDURE                                    
+[id="nw-udn-cr-ui_{context}"]                                   
+= Creating a UserDefinedNetwork CR by using the web console
+
+You can create a `UserDefinedNetwork` custom resource by using the {product-title} web console.
+
+.Prerequisites
+
+* You have access to the {product-title} web console as a user with `cluster-admin` permissions.
+* You have created a namespace and applied the `k8s.ovn.org/primary-user-defined-network` label.
+
+.Procedure
+
+. From the *Administrator* perspective, click *Networking* -> *UserDefinedNetworks*.
+
+. Click *Create UserDefinedNetwork*.
+
+. From the *Project name* list, select the namespace that you previously created.
+
+. Specify a value in the *Subnet* field.
+
+. Click *Create*. The user-defined network serves as the default primary network for pods that you create in this namespace.
\ No newline at end of file
diff --git a/modules/nw-udn-cr.adoc b/modules/nw-udn-cr.adoc
index 9dcb954574e2..712cac91c7bd 100644
--- a/modules/nw-udn-cr.adoc
+++ b/modules/nw-udn-cr.adoc
@@ -1,21 +1,35 @@
 //module included in the following assembly:
 //
-// *networking/multiple_networks/understanding-user-defined-networks.adoc
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="nw-udn-cr_{context}"]
-= Creating a UserDefinedNetwork custom resource
+= Creating a UserDefinedNetwork CR by using the CLI
 
-The following procedure creates a user-defined network that is namespace scoped. Based upon your use case, create your request using either the `my-layer-two-udn.yaml` example for a `Layer2` topology type or the `my-layer-three-udn.yaml` example for a `Layer3` topology type.
+The following procedure creates a `UserDefinedNetwork` CR that is namespace scoped. Based upon your use case, create your request by using either the `my-layer-two-udn.yaml` example for a `Layer2` topology type or the `my-layer-three-udn.yaml` example for a `Layer3` topology type.
 
 //We won't have these pieces till GA in 4.18.
 //[NOTE]
 //====
-//If any cluster default networked pods exist before the user-defined network is created, any further pods created in this namespace will return an error message: `What_is_this`.
+//If any cluster default networked pods exist before the user-defined network is created, any further pods created in this namespace will return an error message: `What_is_this`?
 //====
 
 .Procedure
 
+. Optional: For a `UserDefinedNetwork` CR that uses a primary network, create a namespace with the `k8s.ovn.org/primary-user-defined-network` label by entering the following command:
++
+[source,yaml]
+----
+$ cat << EOF | oc apply -f -
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: <udn_namespace_name>      
+  labels:
+    k8s.ovn.org/primary-user-defined-network: ""
+EOF
+----
+
 . Create a request for either a `Layer2` or `Layer3` topology type user-defined network:
 
 .. Create a YAML file, such as `my-layer-two-udn.yaml`, to define your request for a `Layer2` topology as in the following example:
@@ -38,7 +52,7 @@ spec:
 <1> Name of your `UserDefinedNetwork` resource. This should not be `default` or duplicate any global namespaces created by the Cluster Network Operator (CNO).
 <2> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer2` topology type creates one logical switch that is shared by all nodes.
 <3> This field specifies the topology configuration. It can be `layer2` or `layer3`.
-<4> Specifies `Primary` or `Secondary`. `Primary` is the only `role` specification supported in 4.17.
+<4> Specifies a `Primary` or `Secondary` role.
 <5> For `Layer2` topology types the following specifies config details for the `subnet` field:
 +
 * The subnets field is optional.
@@ -65,27 +79,28 @@ spec:
         hostSubnet: 24
       - cidr: 2001:db8::/60
         hostSubnet: 64
+# ...
 ----
 <1> Name of your `UserDefinedNetwork` resource. This should not be `default` or duplicate any global namespaces created by the Cluster Network Operator (CNO).
 <2> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer3` topology type creates a layer 2 segment per node, each with a different subnet. Layer 3 routing is used to interconnect node subnets.
 <3> This field specifies the topology configuration. Valid values are `layer2` or `layer3`.
-<4> Specifies a `Primary` or `Secondary` role. `Primary` is the only `role` specification supported in 4.17 .
+<4> Specifies a `Primary` or `Secondary` role.
 <5> For `Layer3` topology types the following specifies config details for the `subnet` field:
 +
 * The `subnets` field is mandatory.
 * The type for the `subnets` field is `cidr` and `hostSubnet`:
-** `cidr` is the cluster subnet and accepts a string value.
-** `hostSubnet` specifies the nodes subnet prefix that the cluster subnet is split to.
+** `cidr` is equivalent to the `clusterNetwork` configuration settings of a cluster. The IP addresses in the CIDR are distributed to pods in the user defined network. This parameter accepts a string value.
+** `hostSubnet` defines the per-node subnet prefix.
 ** For IPv6, only a `/64` length is supported for `hostSubnet`.
 +
 . Apply your request by running the following command:
 +
 [source,terminal]
 ----
-$ oc apply -f <my_layer_two_udn.yaml>
+$ oc apply -f <my_layer_two_udn>.yaml
 ----
 +
-Where `<my_layer_two_udn.yaml>` is the name of your `Layer2` or `Layer3` configuration file.
+Where `<my_layer_two_udn>.yaml` is the name of your `Layer2` or `Layer3` configuration file.
 
 . Verify that your request is successful by running the following command:
 +
@@ -123,5 +138,5 @@ status:
     message: NetworkAttachmentDefinition has been created
     reason: NetworkAttachmentDefinitionReady
     status: "True"
-    type: NetworkReady
+    type: NetworkCreated
 ----
\ No newline at end of file
diff --git a/modules/nw-udn-examples.adoc b/modules/nw-udn-examples.adoc
index 3c6bebff33d2..5e9409ed69de 100644
--- a/modules/nw-udn-examples.adoc
+++ b/modules/nw-udn-examples.adoc
@@ -1,6 +1,6 @@
 //module included in the following assembly:
 //
-// *networking/multiple_networks/understanding-user-defined-networks.adoc
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="nw-udn-examples_{context}"]
diff --git a/modules/nw-udn-limitations.adoc b/modules/nw-udn-limitations.adoc
index ee8ff2fcc9be..2b77982653d4 100644
--- a/modules/nw-udn-limitations.adoc
+++ b/modules/nw-udn-limitations.adoc
@@ -1,12 +1,12 @@
 //module included in the following assembly:
 //
-// *networkking/multiple_networks/understanding-user-defined-networks.adoc
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="limitations-for-udn_{context}"]
-= Limitations for UserDefinedNetwork custom resource
+= Limitations of a user-defined network
 
-While user-defined networks (UDN) offer highly customizable network configuration options, there are limitations that cluster administrators and developers should be aware of when implementing and managing these networks. Consider the following limitations before implementing a user-defined network.
+While user-defined networks (UDN) offer highly customizable network configuration options, there are limitations that cluster administrators and developers should be aware of when implementing and managing these networks. Consider the following limitations before implementing a UDN.
 
 //Check on the removal of the DNS limitation for 4.18 or 4.17.z.
 * *DNS limitations*:
diff --git a/modules/nw-udn-support-matrix-primary-secondary.adoc b/modules/nw-udn-support-matrix-primary-secondary.adoc
new file mode 100644
index 000000000000..5cf74499ed40
--- /dev/null
+++ b/modules/nw-udn-support-matrix-primary-secondary.adoc
@@ -0,0 +1,148 @@
+//module included in the following assembly:
+//
+// *networkking/multiple_networks/understanding-user-defined-networks.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="support-matrix-for-udn-nad_{context}"]
+= UserDefinedNetwork and NetworkAttachmentDefinition support matrix
+
+The `UserDefinedNetwork` and `NetworkAttachmentDefinition` custom resources (CRs) provide cluster administrators and users the ability to create customizable network configurations and define their own network topologies, ensure network isolation, manage IP addressing for workloads, and configure advanced network features. A third CR, `ClusterUserDefinedNetwork`, is also available, which allows administrators the ability to create and define additional networks spanning multiple namespaces at the cluster level. 
+
+User-defined networks and network attachment definitions can serve as both the primary and secondary network interface, and each support `layer2` and `layer3` topologies; a third network topology, Localnet, is also supported with network attachment definitions with secondary networks. 
+
+[NOTE]
+====
+As of {product-title} 4.18, the Localnet topology is unavailable for use with the `UserDefinedNetwork` and `ClusterUserDefinedNetwork` CRs. It is only available for `NetworkAttachmentDefinition` CRs that leverage secondary networks.
+====
+
+The following section highlights the supported features of the `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs when they are used as either the primary or secondary network. A separate table for the `ClusterUserDefinedNetwork` CR is also included. 
+ 
+.Primary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs
+[cols="1a,1a,1a, options="header"]
+|===
+^| Network feature ^| Layer2 topology ^|Layer3 topology
+
+^| east-west traffic
+^| &#10003;
+^| &#10003;
+
+^| north-south traffic
+^| &#10003;
+^| &#10003;
+
+^| Persistent IPs
+^| &#10003;
+^| X
+
+^| Services
+^| &#10003;
+^| &#10003;
+
+^| `EgressIP` resource
+^| &#10003;
+^| &#10003;
+
+^| Multicast ^[1]^
+^| X
+^| &#10003;
+
+^| `NetworkPolicy` resource ^[2]^
+^| &#10003;
+^| &#10003;
+
+^| `MultinetworkPolicy` resource 
+^| X
+^| X
+
+|===
+1. Multicast must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information about multicast, see "Enabling multicast for a project".
+2. When creating a `UserDefinedNetwork` CR with a primary network type, network policies must be created _after_ the `UserDefinedNetwork` CR.
+
+.Secondary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs
+[cols="1a,1a,1a,1a, options="header"]
+|===
+^| Network feature ^| Layer2 topology ^|Layer3 topology ^|Localnet topology ^[1]^
+
+^| east-west traffic
+^| &#10003;
+^| &#10003;
+^| &#10003; (`NetworkAttachmentDefinition` CR only)
+
+^| north-south traffic
+^| X
+^| X
+^| &#10003;
+
+^| Persistent IPs
+^| &#10003;
+^| X
+^| &#10003; (`NetworkAttachmentDefinition` CR only)
+
+^| Services
+^| X
+^| X
+^| X
+
+^| `EgressIP` resource
+^| X
+^| X
+^| X
+
+^| Multicast
+^| X
+^| X
+^| X
+
+^| `NetworkPolicy` resource
+^| X
+^| X
+^| X
+
+^| `MultinetworkPolicy` resource
+^| &#10003;
+^| &#10003;
+^| &#10003; (`NetworkAttachmentDefinition` CR only)
+
+|===
+1. The Localnet topology is unavailable for use with the `UserDefinedNetwork` CR. It is only supported on secondary networks for `NetworkAttachmentDefinition` CRs.
+
+.Support matrix for `ClusterUserDefinedNetwork` CRs
+[cols="1a,1a,1a, options="header"]
+|===
+^| Network feature ^| Layer2 topology ^|Layer3 topology
+
+^| east-west traffic
+^| &#10003;
+^| &#10003;
+
+^| north-south traffic
+^| &#10003;
+^| &#10003;
+
+^| Persistent IPs
+^| &#10003;
+^| X
+
+^| Services
+^| &#10003;
+^| &#10003;
+
+^| `EgressIP` resource
+^| &#10003;
+^| &#10003;
+
+^| Multicast ^[1]^
+^| X
+^| &#10003;
+
+^| `MultinetworkPolicy` resource
+^| X
+^| X
+
+^| `NetworkPolicy` resource ^[2]^
+^| &#10003;
+^| &#10003;
+
+|===
+1. Multicast must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information, see "About multicast".
+2. When creating a `ClusterUserDefinedNetwork` CR with a primary network type, network policies must be created _after_ the `UserDefinedNetwork` CR.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-choosing-service-types.adoc b/modules/nw-understanding-networking-choosing-service-types.adoc
new file mode 100644
index 000000000000..cc26f952937d
--- /dev/null
+++ b/modules/nw-understanding-networking-choosing-service-types.adoc
@@ -0,0 +1,34 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-choosing-service-types_{context}"]
+= Choosing between service types and API resources
+
+Service types and API resources offer different benefits for exposing applications and securing network connections. By leveraging the appropriate service type or API resource, you can effectively manage how your applications are exposed and ensure secure, reliable access for both internal and external clients.
+
+{product-title} supports the following service types and API resources:
+
+* Service Types
+
+** `ClusterIP` is intended for internal-only exposure. It is easy to set up and provides a stable internal IP address for accessing services within the cluster. `ClusterIP` is suitable for communication between services within the cluster.
+
+** `NodePort` allows external access by exposing the service on each node's IP at a static port. It is straightforward to set up and useful for development and testing. `NodePort` is good for simple external access without the need for a load balancer from the cloud provider.
+
+** `LoadBalancer` automatically provisions an external load balancer to distribute traffic across multiple nodes.
+It is ideal for production environments where reliable, high-availability access is needed.
+
+** `ExternalName` maps a service to an external DNS name to allow services outside the cluster to be accessed using the service's DNS name. It is good for integrating external services or legacy systems with the cluster.
+
+** Headless service is a DNS name that returns the list of pod IPs without providing a stable `ClusterIP`. This is ideal for stateful applications or scenarios where direct access to individual pod IPs is needed.
+
+* API Resources
+
+** `Ingress` provides control over routing HTTP and HTTPS traffic, including support for load balancing, SSL/TLS termination, and name-based virtual hosting. It is more flexible than services alone and supports multiple domains and paths. `Ingress` is ideal when complex routing is required.
+
+** `Route` is similar to `Ingress` but provides additional features, including TLS re-encryption and passthrough. It simplifies the process of exposing services externally. `Route` is best for when you need advanced features, such as integrated certificate management.
+
+If you need a simple way to expose a service to external traffic, `Route` or `Ingress` might be the best choice. These resources can be managed by a namespace admin or developer. The easiest approach is to create a route, check its external DNS name, and configure your DNS to have a CNAME that points to the external DNS name. 
+
+For HTTP/HTTPS/TLS, `Route` or `Ingress` should suffice. Anything else is more complex and requires a cluster admin to ensure ports are accessible or MetalLB is configured. `LoadBalancer` services are also an option in cloud environments or appropriately configured bare-metal environments.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-common-practices.adoc b/modules/nw-understanding-networking-common-practices.adoc
new file mode 100644
index 000000000000..de0ce2ed8a6c
--- /dev/null
+++ b/modules/nw-understanding-networking-common-practices.adoc
@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-common-practices_{context}"]
+= Common practices for networking services
+
+In {product-title}, services create a single IP address for clients to use, even if multiple pods are providing that service. This abstraction enables seamless scaling, fault tolerance, and rolling upgrades without affecting clients.
+
+Network security policies manage traffic within the cluster. Network controls empower namespace administrators to define ingress and egress rules for their pods. By using network administration policies, cluster administrators can establish namespace policies, override namespace policies, or set default policies when none are defined.
+
+Egress firewall configurations control outbound traffic from pods. These configuration settings ensure that only authorized communication occurs. The ingress node firewall protects nodes by controlling incoming traffic. Additionally, the Universal Data Network manages data traffic across the cluster.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-concepts-components.adoc b/modules/nw-understanding-networking-concepts-components.adoc
new file mode 100644
index 000000000000..e23c509e363a
--- /dev/null
+++ b/modules/nw-understanding-networking-concepts-components.adoc
@@ -0,0 +1,27 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-concepts-components_{context}"]
+= Networking concepts and components
+
+Networking in {product-title} uses several key components and concepts.
+
+* Pods and services are the smallest deployable units in Kubernetes, and services provide stable IP addresses and DNS names for sets of pods. Each pod in a cluster is assigned a unique IP address. Pods use IP addresses to communicate directly with other pods, regardless of which node they are on. The pod IP addresses will change when pods are destroyed and created. Services are also assigned unique IP addresses. A service is associated with the pods that can provide the service. When accessed, the service IP address provides a stable way to access pods by sending traffic to one of the pods that backs the service.
+
+* Route and Ingress APIs define rules that route HTTP, HTTPS, and TLS traffic to services within the cluster. {product-title} provides both Route and Ingress APIs as part of the default installation, but you can add third-party Ingress Controllers to the cluster.
+
+* The Container Network Interface (CNI) plugin manages the pod network to enable pod-to-pod communication.
+
+* The Cluster Network Operator (CNO)  CNO manages the networking plugin components of a cluster. Using the CNO, you can set the network configuration, such as the pod network CIDR and service network CIDR.
+
+* DNS operators manage DNS services within the cluster to ensure that services are reachable by their DNS names.
+
+* Network controls define how pods are allowed to communicate with each other and with other network endpoints. These policies help secure the cluster by controlling traffic flow and enforcing rules for pod communication.
+
+* Load balancing distributes network traffic across multiple servers to ensure reliability and performance.
+
+* Service discovery is a mechanism for services to find and communicate with each other within the cluster.
+
+* The Ingress Operator uses {product-title} Route to manage the router and enable external access to cluster services. 
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-controls.adoc b/modules/nw-understanding-networking-controls.adoc
new file mode 100644
index 000000000000..547a7211bb8b
--- /dev/null
+++ b/modules/nw-understanding-networking-controls.adoc
@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-controls_{context}"]
+= Network controls
+
+Network controls define rules for how pods are allowed to communicate with each other and with other network endpoints. Network controls are implemented at the network level to ensure that only allowed traffic can flow between pods. This helps secure the cluster by restricting traffic flow and preventing unauthorized access.
+
+* Admin network policies (ANP): ANPs are cluster-scoped custom resource definitions (CRDs). As a cluster administrator, you can use an ANP to define network policies at a cluster level. You cannot override these policies by using regular network policy objects. These policies enforce strict network security rules across the entire cluster. ANPs can specify ingress and egress rules to allow administrators to control the traffic that enters and leaves the cluster.
+
+* Egress firewall: The egress firewall restricts egress traffic leaving the cluster. With this firewall, administrators can limit the external hosts that pods can access from within the cluster. You can configure egress firewall policies to allow or deny traffic to specific IP ranges, DNS names, or external services. This helps prevent unauthorized access to external resources and ensures that only allowed traffic can leave the cluster.
+
+* Ingress node firewall: The ingress node firewall controls ingress traffic to the nodes in a cluster. With this firewall, administrators define rules that restrict which external hosts can initiate connections to the nodes. This helps protect the nodes from unauthorized access and ensures that only trusted traffic can reach the cluster.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-dns-example.adoc b/modules/nw-understanding-networking-dns-example.adoc
new file mode 100644
index 000000000000..b2a2c78452f3
--- /dev/null
+++ b/modules/nw-understanding-networking-dns-example.adoc
@@ -0,0 +1,106 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-understanding-networking-dns-example_{context}"]
+= Example: DNS use case
+
+For this example, a front-end application is running in one set of pods and a back-end service is running in another set of pods. The front-end application needs to communicate with the back-end service. You create a service for the back-end pods that gives it a stable IP address and DNS name. The front-end pods use this DNS name to access the back-end service regardless of changes to individual pod IP addresses.
+
+By creating a service for the back-end pods, you provide a stable IP and DNS name, `backend-service.default.svc.cluster.local`, that the front-end pods can use to communicate with the back-end service. This setup would ensure that even if individual pod IP addresses change, the communication remains consistent and reliable. 
+
+The following steps demonstrate an example of how to configure front-end pods to communicate with a back-end service using DNS.
+
+. Create the back-end service. 
+
+.. Deploy the back-end pods.
++
+[source, yaml]
+----
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: backend-deployment
+  labels:
+    app: backend
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: backend
+  template:
+    metadata:
+      labels:
+        app: backend
+    spec:
+      containers:
+        - name: backend-container
+          image: your-backend-image
+          ports:
+            - containerPort: 8080
+----
+
+.. Define a service to expose the back-end pods.
++
+[source, yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  name: backend-service
+spec:
+  selector:
+    app: backend
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 8080
+----
+
+. Create the front-end pods.
+
+.. Define the front-end pods.
++
+[source, yaml]
+----
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: frontend-deployment
+  labels:
+    app: frontend
+  spec:
+    replicas: 3
+    selector:
+    matchLabels:
+      app: frontend
+   template:
+   metadata:
+     labels:
+       app: frontend
+   spec:
+     containers:
+       - name: frontend-container
+         image: your-frontend-image
+         ports:
+           - containerPort: 80
+----
+
+.. Apply the pod definition to your cluster.
++
+[source,terminal]
+----
+$ oc apply -f frontend-deployment.yaml
+----
+
+. Configure the front-end to communicate with the back-end. 
++
+In your front-end application code, use the DNS name of the back-end service to send requests. For example, if your front-end application needs to fetch data from the back-end pod, your application might include the following code:
++
+[source, JavaScript]
+----
+fetch('http://backend-service.default.svc.cluster.local/api/data')
+  .then(response => response.json())
+  .then(data => console.log(data));
+----
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-dns-terms.adoc b/modules/nw-understanding-networking-dns-terms.adoc
new file mode 100644
index 000000000000..4611f512ed15
--- /dev/null
+++ b/modules/nw-understanding-networking-dns-terms.adoc
@@ -0,0 +1,19 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-dns-terms_{context}"]
+= Key DNS terms
+
+* CoreDNS: CoreDNS is the DNS server and provides name resolution for services and pods.
+
+* DNS names: Services are assigned DNS names based on their namespace and name. For example, a service named `my-service` in the `default` namespace would have the DNS name `my-service.default.svc.cluster.local`.
+
+* Domain names: Domain names are the human-friendly names used to access websites and services, such as `example.com`.
+
+* IP addresses: IP addresses are numerical labels assigned to each device connected to a computer network that uses IP for communication. An example of an IPv4 address is `192.0.2.1`. An example of an IPv6 address is `2001:0db8:85a3:0000:0000:8a2e:0370:7334`.
+
+* DNS servers: DNS servers are specialized servers that store DNS records. These records map domain names to IP addresses. When you type a domain name into your browser, your computer contacts a DNS server to find the corresponding IP address.
+
+* Resolution process: A DNS query is sent to a DNS resolver. The DNS resolver then contacts a series of DNS servers to find the IP address associated with the domain name. The resolver will try using the name with a series of domains, such as `<namespace>.svc.cluster.local`, `svc.cluster.local`, and `cluster.local`. This process stops at the first match. The IP address is returned to your browser and then connects to the web server using the IP address.
diff --git a/modules/nw-understanding-networking-dns.adoc b/modules/nw-understanding-networking-dns.adoc
new file mode 100644
index 000000000000..aa062fa907d2
--- /dev/null
+++ b/modules/nw-understanding-networking-dns.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-dns_{context}"]
+= The Domain Name System (DNS)
+
+The Domain Name System (DNS) is a hierarchical and decentralized naming system used to translate human-friendly domain names, such as www.example.com, into IP addresses that identify computers on a network. DNS plays a crucial role in service discovery and name resolution.
+
+{product-title} provides a built-in DNS to ensure that services can be reached by their DNS names. This helps maintain stable communication even if the underlying IP addresses change. When you start a pod, environment variables for service names, IP addresses, and ports are created automatically to enable the pod to communicate with other services.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-exposing-applications.adoc b/modules/nw-understanding-networking-exposing-applications.adoc
new file mode 100644
index 000000000000..211dbc0eb5c9
--- /dev/null
+++ b/modules/nw-understanding-networking-exposing-applications.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-exposing-applications_{context}"]
+= Exposing applications
+
+ClusterIP exposes services on an internal IP within the cluster to make the cluster accessible only to other services within the cluster. The NodePort service type exposes the service on a static port on each node's IP. This service type allows external traffic to access the service. Load balancers are typically used in cloud or bare-metal environments that use MetalLB. This service type provisions an external load balancer that routes external traffic to the service. On bare-metal environments, MetalLB uses VIPs and ARP announcements or BGP announcements.
+
+Ingress is an API object that manages external access to services, such as load balancing, SSL/TLS termination, and name-based virtual hosting. An Ingress Controller, such as NGINX or HAProxy, implements the Ingress API and handles traffic routing based on user-defined rules.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-features.adoc b/modules/nw-understanding-networking-features.adoc
new file mode 100644
index 000000000000..1804efe0ad91
--- /dev/null
+++ b/modules/nw-understanding-networking-features.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-features_{context}"]
+= Networking features
+
+{product-title} offers several networking features and enhancements. These features and enhancements are listed as follows: 
+
+* Ingress Operator and Route API: {product-title} includes an Ingress Operator that implements the Ingress Controller API. This component enables external access to cluster services by deploying and managing HAProxy-based Ingress Controllers that support advanced routing configurations and load balancing. {product-title} uses the Route API to translate upstream Ingress objects to route objects. Routes are specific to networking in {product-title}, but you can also use third-party Ingress Controllers.
+
+* Enhanced security: {product-title} provides advanced network security features, such as the egress firewall and and the ingress node firewall.
++
+** Egress firewall: The egress firewall controls and restricts outbound traffic from pods within the cluster. You can set rules to limit which external hosts or IP ranges with which pods can communicate.
+** Ingress node firewall: The ingress node firewall is managed by the Ingress Firewall Operator and provides firewall rules at the node level. You can protect your nodes from threats by configuring this firewall on specific nodes within the cluster to filter incoming traffic before it reaches these nodes.
++
+[NOTE]
+====
+{product-title} also implements services, such as Network Policy, Admin Network Policy, and Security Context Constraints (SCC) to secure communication between pods and enforce access controls.
+====
+
+* Role-based access control (RBAC): {product-title} extends Kubernetes RBAC to provide more granular control over who can access and manage network resources. RBAC helps maintain security and compliance within the cluster.
+
+* Multi-tenancy support: {product-title} offers multi-tenancy support to enable multiple users and teams to share the same cluster while keeping their resources isolated and secure.
+
+* Hybrid and multi-cloud capabilities: {product-title} is designed to work seamlessly across on-premise, cloud, and multi-cloud environments. This flexibility allows organizations to deploy and manage containerized applications across different infrastructures.
+
+* Observability and monitoring: {product-title} provides integrated observability and monitoring tools that help manage and troubleshoot network issues. These tools include role-based access to network metrics and logs.
+
+* User-defined networks (UDN): UDNs allow administrators to customize network configurations. UDNs provide enhanced network isolation and IP address management.
+
+* Egress IP: Egress IP allows you to assign a fixed source IP address for all egress traffic originating from pods within a namespace. Egress IP can improve security and access control by ensuring consistent source IP addresses for external services. For example, if a pod needs to access an external database that only allows traffic from specific IP adresses, you can configure an egress IP for that pod to meet the access requirements.
+
+* Egress router: An egress router is a pod that acts as a bridge between the cluster and external systems. Egress routers allow traffic from pods to be routed through a specific IP address that is not used for any other purpose. With egress routers, you can enforce access controls or route traffic through a specific gateway.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-how-pods-communicate.adoc b/modules/nw-understanding-networking-how-pods-communicate.adoc
new file mode 100644
index 000000000000..f53f1923be01
--- /dev/null
+++ b/modules/nw-understanding-networking-how-pods-communicate.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-how-pods-communicate_{context}"]
+= How pods communicate
+
+Pods use IP addresses to communicate and a Dynamic Name System (DNS) to discover IP addresses for pods or services. Clusters use various policy types that control what communication is allowed. Pods communicate in two ways: pod-to-pod and service-to-pod.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-ingress.adoc b/modules/nw-understanding-networking-ingress.adoc
new file mode 100644
index 000000000000..e063492f2747
--- /dev/null
+++ b/modules/nw-understanding-networking-ingress.adoc
@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-ingress_{context}"]
+= Ingress
+
+Ingress is a resource that provides advanced routing capabilities, including load balancing, SSL/TLS termination, and name-based virtual hosting. Here are some key points about Ingress:
+
+* HTTP/HTTPS routing: You can use Ingress to define rules for routing HTTP and HTTPS traffic to services within the cluster. 
+* Load balancing: Ingress Controllers, such as NGINX or HAProxy, manage traffic routing and load balancing based on user-defined defined rules. 
+* SSL/TLS termination: SSL/TLS termination is the process of decrypting incoming SSL/TLS traffic before passing it to the backend services. 
+* Multiple domains and paths: Ingress supports routing traffic for multiple domains and paths. 
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-networking-in-OpenShift.adoc b/modules/nw-understanding-networking-networking-in-OpenShift.adoc
new file mode 100644
index 000000000000..b1ce91277422
--- /dev/null
+++ b/modules/nw-understanding-networking-networking-in-OpenShift.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-networking-in-OpenShift_{context}"]
+= Networking in {product-title}
+
+{product-title} ensures seamless communication between various components within the cluster and between external clients and the cluster. Networking relies on the following core concepts and components:
+
+* Pod-to-pod communication
+* Services
+* DNS
+* Ingress 
+* Network controls
+* Load balancing
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-nodes-clients-clusters.adoc b/modules/nw-understanding-networking-nodes-clients-clusters.adoc
new file mode 100644
index 000000000000..2265afb6b9e4
--- /dev/null
+++ b/modules/nw-understanding-networking-nodes-clients-clusters.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-nodes-clients-clusters_{context}"]
+= Networking with nodes, clients, and clusters
+
+A node is a machine in the cluster that can run either control-plane components, workload components, or both. A node is either a physical server or a virtual machine. A cluster is a collection of nodes that run containerized applications. Clients are the tools and users that interact with the cluster.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-pod-to-pod-example.adoc b/modules/nw-understanding-networking-pod-to-pod-example.adoc
new file mode 100644
index 000000000000..c6d410a904e2
--- /dev/null
+++ b/modules/nw-understanding-networking-pod-to-pod-example.adoc
@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-pod-to-pod-example_{context}"]
+= Example: Controlling pod-to-pod communication
+
+In a microservices-based application with multiple pods, a frontend pod needs to communicate with the a backend pod to retrieve data. By using pod-to-pod communication, either directly or through services, these pods can efficiently exchange information.
+
+To control and secure pod-to-pod communication, you can define network controls. These controls enforce security and compliance requirements by specifying how pods interact with each other based on labels and selectors.
+
+[source, yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-some-pods
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: app
+  ingress:
+    - from:
+        - podSelector:
+            matchLabels:
+              role: backend
+      ports:
+        - protocol: TCP
+          port: 80
+----
diff --git a/modules/nw-understanding-networking-pod-to-pod.adoc b/modules/nw-understanding-networking-pod-to-pod.adoc
new file mode 100644
index 000000000000..a4bcffecbeb6
--- /dev/null
+++ b/modules/nw-understanding-networking-pod-to-pod.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-pod-to-pod_{context}"]
+= Pod-to-pod communication
+
+Pod-to-pod communication is the ability of pods to communicate with each other within the cluster. This is crucial for the functioning of microservices and distributed applications. 
+
+Each pod in a cluster is assigned a unique IP address that they use to communicate directly with other pods. Pod-to-pod communication is useful for intra-cluster communication where pods need to exchange data or perform tasks collaboratively. For example, Pod A can send requests directly to Pod B using Pod B's IP address. Pods can communicate over a flat network without Network Address Translation (NAT). This allows for seamless communication between pods across different nodes.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-routes-ingress-example.adoc b/modules/nw-understanding-networking-routes-ingress-example.adoc
new file mode 100644
index 000000000000..816e832a56ac
--- /dev/null
+++ b/modules/nw-understanding-networking-routes-ingress-example.adoc
@@ -0,0 +1,137 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-understanding-networking-routes-ingress-example_{context}"]
+= Example: Configuring routes and ingress to expose a web application
+
+A web application is running on your {product-title} cluster. You want to make the application accessible to external users. The application should be accessible through a specific domain name, and the traffic should be securely encrypted using TLS. The following example shows how to configure both routes and ingress to expose your web application to external traffic securely.
+
+[id="nw-understanding-networking-routes-ingress-example-routes_{context}"]
+== Configuring Routes
+
+. Create a new project.
++
+[source, terminal]
+----
+$ oc new-project webapp-project
+----
+
+. Deploy the web application.
++
+[source, terminal]
+----
+$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp
+----
+
+. Expose the service with a Route.
++
+[source, terminal]
+----
+$ oc expose svc/webapp --hostname=webapp.example.com
+----
+
+. Secure the Route with TLS.
+
+.. Create a TLS secret with your certificate and key.
++
+[source, terminal]
+----
+$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key
+----
+
+.. Update the route to use the TLS secret.
++
+[source, terminal]
+----
+$ oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}'
+----
+
+[id="nw-understanding-networking-routes-ingress-example-ingress_{context}"]
+== Configuring ingress
+
+. Create an ingress resource.
++
+Ensure your ingress Controller is installed and running in the cluster.
+
+. Create a service for the web application. If not already created, expose the application as a service.
++
+[source, yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  name: webapp-service
+  namespace: webapp-project
+spec:
+  selector:
+    app: webapp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 8080
+----
+
+. Create the ingress resource.
++
+[source, yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: webapp-ingress
+  namespace: webapp-project
+  annotations:
+    kubernetes.io/ingress.class: "nginx"
+spec:
+  rules:
+    - host: webapp.example.com
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: webapp-service
+                port:
+                  number: 80
+----
+
+. Secure the ingress with TLS.
+
+.. Create a TLS secret with your certificate and key.
++
+[source, terminal]
+----
+$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project
+----
+
+.. Update the ingress resource to use the TLS secret.
++
+[source, yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: webapp-ingress
+  namespace: webapp-project
+spec:
+  tls: <1>
+    - hosts:
+        - webapp.example.com
+      secretName: webapp-tls <2>
+  rules:
+    - host: webapp.example.com
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: webapp-service
+                port:
+                  number: 80
+----
+<1> The `TLS` section specifies TLS settings.
+<2> The `secretName` field is the name of Kubernetes secret that contains the TLS certificate and key.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-routes-ingress.adoc b/modules/nw-understanding-networking-routes-ingress.adoc
new file mode 100644
index 000000000000..0bb89800d5bc
--- /dev/null
+++ b/modules/nw-understanding-networking-routes-ingress.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-routes-ingress_{context}"]
+= Routes and ingress
+
+Routes and ingress are both used to expose applications to external traffic. However, they serve slightly different purposes and have different capabilities.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-routes-vs-ingress.adoc b/modules/nw-understanding-networking-routes-vs-ingress.adoc
new file mode 100644
index 000000000000..f873e4f203e0
--- /dev/null
+++ b/modules/nw-understanding-networking-routes-vs-ingress.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-routes-vs-ingress_{context}"]
+= Comparing Routes and ingress
+
+Routes provide more flexibility and advanced features compared to ingress. This makes routes suitable for complex routing scenarios. Routes are simpler to set up and use, especially for basic external access needs. Ingress is often used for simpler, straightforward external access. Routes are used for more complex scenarios that require advanced routing and SSL/TLS termination. 
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-routes.adoc b/modules/nw-understanding-networking-routes.adoc
new file mode 100644
index 000000000000..0e5b0299a944
--- /dev/null
+++ b/modules/nw-understanding-networking-routes.adoc
@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-routes_{context}"]
+= Routes
+
+Routes are specific to {product-title} resources that expose a service at a host name so that external clients can reach the service by name. 
+
+Routes map a host name to a service. Route name mapping allows external clients to access the service using the host name. 
+Routes provide load balancing for the traffic directed to the service. The host name used in a route is resolved to the IP address of the router. Routes then forward the traffic to the appropriate service. Routes can also be secured using SSL/TLS to encrypt traffic between the client and the service. 
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-securing-connections.adoc b/modules/nw-understanding-networking-securing-connections.adoc
new file mode 100644
index 000000000000..0aec88276ecb
--- /dev/null
+++ b/modules/nw-understanding-networking-securing-connections.adoc
@@ -0,0 +1,17 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-securing-connections_{context}"]
+= Securing connections
+
+Ingress Controllers manage SSL/TLS termination to decrypt incoming SSL/TLS traffic before passing it to the backend services. SSL/TLS termination offloads the encryption/decryption process from the application pods. You can use TLS certificates to encrypt traffic between clients and your services. You can manage certificates with tools, such as `cert-manager`, to automate certificate distribution and renewal.
+
+Routes pass TLS traffic to a pod if it has the SNI field. This process allows services that run TCP to be exposed using TLS and not only HTTP/HTTPS. A site administrator can manage the certificates centrally and allow application developers to read private keys even without permission. 
+
+The Route API enables encryption of router-to-pod traffic with cluster-managed certificates. This ensures external certificates are centrally managed while the internal leg remains encrypted. Application developers receive unique private keys for their applications. These keys can be mounted as a secret in the pod.
+
+Network controls define rules for how pods can communicate with each other and other network endpoints. This enhances security by controlling traffic flow within the cluster. These controls are implemented at the network plugin level to ensure that only allowed traffic flows between pods.
+
+Role-based access control (RBAC) manages permissions and control who can access resources within the cluster. Service accounts provide identity for pods that access the  API. RBAC allows granular control over what each pod can do.
diff --git a/modules/nw-understanding-networking-security-example.adoc b/modules/nw-understanding-networking-security-example.adoc
new file mode 100644
index 000000000000..ef80c695aae4
--- /dev/null
+++ b/modules/nw-understanding-networking-security-example.adoc
@@ -0,0 +1,78 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-understanding-networking-security-example_{context}"]
+= Example: Exposing applications and securing connections
+
+In this example, a web application running in your cluster needs to be accessed by external users.
+
+. Create a service and expose the application as a service using a service type that suits your needs.
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-web-app
+spec:
+  type: LoadBalancer
+  selector:
+    app: my-web-app
+  ports:
+  - port: 80
+    targetPort: 8080
+----
+
+. Define an `Ingress` resource to manage HTTP/HTTPS traffic and route it to your service.
++
+[source,yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: my-web-app-ingress
+  annotations:
+    kubernetes.io/ingress.class: "nginx"
+spec:
+  rules:
+  - host: mywebapp.example.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: my-web-app
+            port:
+              number: 80
+----
+
+. Configure TLS for your ingress to ensure secured, encrypted connections.
++
+[source,yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: my-web-app-ingress
+  annotations:
+    kubernetes.io/ingress.class: "nginx"
+spec:
+  tls:
+  - hosts:
+    - mywebapp.example.com
+    secretName: my-tls-secret
+  rules:
+  - host: mywebapp.example.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: my-web-app
+            port:
+              number: 80
+----
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-security.adoc b/modules/nw-understanding-networking-security.adoc
new file mode 100644
index 000000000000..874e3d02785e
--- /dev/null
+++ b/modules/nw-understanding-networking-security.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-security_{context}"]
+= Security and traffic management
+
+Administrators can expose applications to external traffic and secure network connections using service types, such as `ClusterIP`, `NodePort`, and `LoadBalaner` and API resources such as `Ingress` and `Route`. The Ingress Operator and Cluster Network Operator (CNO) help configure and manage these services and resources. The Ingress Operator deploys and manages one or more Ingress Controllers. These controllers route external HTTP and HTTPS traffic to services within the cluster. A CNO deploys and manages the cluster network components, including pod networks, service networks, and DNS.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-service-to-pod-example.adoc b/modules/nw-understanding-networking-service-to-pod-example.adoc
new file mode 100644
index 000000000000..af57d39699d9
--- /dev/null
+++ b/modules/nw-understanding-networking-service-to-pod-example.adoc
@@ -0,0 +1,52 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-understanding-networking-service-to-pod-example_{context}"]
+= Example: Controlling service-to-pod communication
+
+A cluster is running a microservices-based application with two components: a front-end and a backend. The front-end needs to communicate with the backend to fetch data.
+
+.Procedure
+
+. Create a backend service.
++
+[source, yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  name: backend
+spec:
+  selector:
+    app: backend
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 8080
+----
+
+. Configure backend pods.
++
+[source, yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: backend-pod
+  labels:
+    app: backend
+spec:
+  containers:
+    - name: backend-container
+      image: my-backend-image
+      ports:
+        - containerPort: 8080
+----
+
+. Establish front-end communication.
++
+The front-end pods can now use the DNS name `backend.default.svc.cluster.local` to communicate with the backend service. The service ensures that the traffic is routed to one of the backend pods. 
+
+Service-to-pod communication abstracts the complexity of managing pod IPs and ensures reliable and efficient communication within the cluster. 
diff --git a/modules/nw-understanding-networking-service-to-pod.adoc b/modules/nw-understanding-networking-service-to-pod.adoc
new file mode 100644
index 000000000000..c1c770a1ef98
--- /dev/null
+++ b/modules/nw-understanding-networking-service-to-pod.adoc
@@ -0,0 +1,56 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-service-to-pod_{context}"]
+= Service-to-pod communication
+
+Service-to-pod communication ensures that services can reliably route traffic to the appropriate pods. Services are objects that define a logical set of pods and provide a stable endpoint, such as IP addresses and DNS names. Pod IP addresses can change. Services abstract pod IP addresses to provide a consistent way to access the application components even as IP addresses change.
+
+Key concepts of service-to-pod communication include:
+
+* Endpoints: Endpoints define the IP addresses and ports of the pods that are associated with a service.
+
+* Selectors: Selectors use labels, such as key-value pairs, to define the criteria for selecting a set of objects that a service should target.
+
+* Services: Services provide a stable IP address and DNS name for a set of pods. This abstraction allows other components to communicate with the service rather than individual pods.
+
+* Service discovery: DNS makes services discoverable. When a service is created, it is assigned a DNS name. Other pods discover this DNS name and use it to communicate with the service.
+
+* Service Types: Service types control how services are exposed within or outside the cluster.
+
+** ClusterIP exposes the service on an internal cluster IP. It is the default service type and makes the service only reachable from within the cluster.
+
+** NodePort allows external traffic to access the service by exposing the service on each node's IP at a static port.
+
+** LoadBalancer uses a cloud provider's load balancer to expose the service externally.
+
+Services use selectors to identify the pods that should receive the traffic. The selectors match labels on the pods to determine which pods are part of the service. Example: A service with the selector `app: myapp` will route traffic to all pods with the label `app: myapp`.
+
+Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-name} maintains these endpoints and ensures that the service routes traffic to the correct pods.
+
+The communication flow refers to the sequence of steps and interactions that occur when a service in Kubernetes routes traffic to the appropriate pods. The typical communication flow for service-to-pod communication is as follows:
+
+* Service creation: When you create a service, you define the service type, the port on which the service listens, and the selector labels.
++
+[source, yaml]
+----
+  apiVersion: v1
+  kind: Service
+  metadata:
+    name: my-service
+  spec:
+    selector:
+      app: myapp
+    ports:
+      - protocol: TCP
+        port: 80
+        targetPort: 8080
+----
+
+* DNS resolution: Each pod has a DNS name that other pods can use to communicate with the service. For example, if the service is named `my-service` in the `my-app` namespace, its DNS name is `my-service.my-app.svc.cluster.local`.
+
+* Traffic routing: When a pod sends a request to the service’s DNS name, {product-title} resolves the name to the service’s ClusterIP. The service then uses the endpoints to route the traffic to one of the pods that match its selector.
+
+* Load balancing: Services also provide basic load balancing. They distribute incoming traffic across all the pods that match the selector. This ensures that no single pod is overwhelmed with too much traffic.
diff --git a/modules/nw-understanding-networking-what-is-a-client.adoc b/modules/nw-understanding-networking-what-is-a-client.adoc
new file mode 100644
index 000000000000..99789245a3f7
--- /dev/null
+++ b/modules/nw-understanding-networking-what-is-a-client.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-what-is-a-client_{context}"]
+= Understanding external clients
+
+An external client is any entity outside the cluster that interacts with the services and applications running within the cluster. External can include end users, external services, and external devices. End users are people who access a web application hosted in the cluster through their browsers or mobile devices. External services are other software systems or applications that interact with the services in the cluster, often through APIs. External devices are any hardware outside the cluster network that needs to communicate with the cluster services, such as the Internet of Things (IoT) devices.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-what-is-a-cluster.adoc b/modules/nw-understanding-networking-what-is-a-cluster.adoc
new file mode 100644
index 000000000000..3da3dd10545a
--- /dev/null
+++ b/modules/nw-understanding-networking-what-is-a-cluster.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-what-is-a-cluster_{context}"]
+= Understanding clusters
+
+A cluster is a collection of nodes that work together to run containerized applications. These nodes include control plane nodes and compute nodes.
\ No newline at end of file
diff --git a/modules/nw-understanding-networking-what-is-a-node.adoc b/modules/nw-understanding-networking-what-is-a-node.adoc
new file mode 100644
index 000000000000..6aeefd91cd25
--- /dev/null
+++ b/modules/nw-understanding-networking-what-is-a-node.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="nw-understanding-networking-what-is-a-node_{context}"]
+= What is a node?
+
+Nodes are the physical or virtual machines that run containerized applications. Nodes host the pods and provide resources, such as memory and storage for running the applications. Nodes enable communication between pods. Each pod is assigned an IP address. Pods within the same node can communicate with each other using these IP addresses. Nodes facilitate service discovery by allowing pods to discover and communicate with services within the cluster. Nodes help distribute network traffic among pods to ensure efficient load balancing and high availability of applications. Nodes provide a bridge between the internal cluster network and external networks to allowing external clients to access services running on the cluster. 
\ No newline at end of file
diff --git a/modules/nw-verify-proxy-configuration.adoc b/modules/nw-verify-proxy-configuration.adoc
new file mode 100644
index 000000000000..2de696734c87
--- /dev/null
+++ b/modules/nw-verify-proxy-configuration.adoc
@@ -0,0 +1,62 @@
+// Module included in the following assemblies:
+//
+// * networking/configuring-a-custom-pki.adoc
+// * networking/enable-cluster-wide-proxy.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-verify-proxy-configuration_{context}"]
+= Verifying the cluster-wide proxy configuration
+
+After the cluster-wide proxy configuration is deployed, you can verify that it is working as expected. Follow these steps to check the logs and validate the implementation.
+
+.Prerequisites
+
+* You have cluster administrator permissions.
+* You have the {product-title} `oc` CLI tool installed.
+
+.Procedure
+
+. Check the proxy configuration status using the `oc` command:
++
+[source,terminal]
+----
+$ oc get proxy/cluster -o yaml
+----
+
+. Verify the proxy fields in the output to ensure they match your configuration. Specifically, check the `spec.httpProxy`, `spec.httpsProxy`, `spec.noProxy`, and `spec.trustedCA` fields.
+
+. Inspect the status of the `Proxy` object:
++
+[source,terminal]
+----
+$ oc get proxy/cluster -o jsonpath='{.status}'
+----
++
+.Example output
+[source,terminal]
+----
+{
+status:
+    httpProxy: http://user:xxx@xxxx:3128
+    httpsProxy: http://user:xxx@xxxx:3128
+    noProxy: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,169.254.169.254,172.30.0.0/16,localhost,test.no-proxy.com
+}
+----
+
+. Check the logs of the Machine Config Operator (MCO) to ensure that the configuration changes were applied successfully:
++
+[source,terminal]
+----
+$ oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)
+----
+
+. Look for messages that indicate the proxy settings were applied and the nodes were rebooted if necessary.
+
+. Verify that system components are using the proxy by checking the logs of a component that makes external requests, such as the Cluster Version Operator (CVO):
++
+[source,terminal]
+----
+$ oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)
+----
+
+. Look for log entries that show that external requests have been routed through the proxy.
\ No newline at end of file
diff --git a/modules/oadp-1-4-2-release-notes.adoc b/modules/oadp-1-4-2-release-notes.adoc
new file mode 100644
index 000000000000..086797f3bdbd
--- /dev/null
+++ b/modules/oadp-1-4-2-release-notes.adoc
@@ -0,0 +1,67 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/oadp-1-4-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="oadp-1-4-2-release-notes_{context}"]
+= {oadp-short} 1.4.2 release notes
+
+The {oadp-first} 1.4.2 release notes lists new features, resolved issues and bugs, and known issues.
+
+[id="new-features-1-4-2_{context}"]
+== New features
+
+.Backing up different volumes in the same namespace by using the VolumePolicy feature is now possible
+
+With this release, Velero provides resource policies to back up different volumes in the same namespace by using the `VolumePolicy` feature. The supported `VolumePolicy` feature to back up different volumes includes `skip`, `snapshot`, and `fs-backup` actions.
+link:https://issues.redhat.com/browse/OADP-1071[OADP-1071]
+
+.File system backup and data mover can now use short-term credentials
+
+File system backup and data mover can now use short-term credentials such as {aws-short} {sts-first} and {gcp-short} WIF. With this support, backup is successfully completed without any `PartiallyFailed` status.
+link:https://issues.redhat.com/browse/OADP-5095[OADP-5095]
+
+[id="resolved-issues-1-4-2_{context}"]
+== Resolved issues
+
+.DPA now reports errors if VSL contains an incorrect provider value 
+
+Previously, if the provider of a Volume Snapshot Location (VSL) spec was incorrect, the Data Protection Application (DPA) reconciled successfully. With this update, DPA reports errors and requests for a valid provider value.
+link:https://issues.redhat.com/browse/OADP-5044[OADP-5044]
+
+.Data Mover restore is successful irrespective of using different OADP namespaces for backup and restore
+
+Previously, when backup operation was executed by using {oadp-short} installed in one namespace but was restored by using {oadp-short} installed in a different namespace, the Data Mover restore failed. With this update, Data Mover restore is now successful.
+link:https://issues.redhat.com/browse/OADP-5460[OADP-5460]
+
+.SSE-C backup works with the calculated MD5 of the secret key
+
+Previously, backup failed with the following error:
+[source,terminal]
+----
+Requests specifying Server Side Encryption with Customer provided keys must provide the client calculated MD5 of the secret key.
+----
+With this update, missing Server-Side Encryption with Customer-Provided Keys (SSE-C) base64 and MD5 hash are now fixed. As a result, SSE-C backup works with the calculated MD5 of the secret key. In addition, incorrect `errorhandling` for the `customerKey` size is also fixed.
+link:https://issues.redhat.com/browse/OADP-5388[OADP-5388]
+
+For a complete list of all issues resolved in this release, see the list of link:https://issues.redhat.com/issues/?filter=12452476[OADP 1.4.2 resolved issues] in Jira.
+
+
+[id="known-issues-1-4-2_{context}"]
+== Known issues
+
+.The nodeSelector spec is not supported for the Data Mover restore action
+
+When a Data Protection Application (DPA) is created with the `nodeSelector` field set in the `nodeAgent` parameter, Data Mover restore partially fails instead of completing the restore operation. 
+link:https://issues.redhat.com/browse/OADP-5260[OADP-5260]
+
+.The S3 storage does not use proxy environment when TLS skip verify is specified
+
+In the image registry backup, the S3 storage does not use the proxy environment when the `insecureSkipTLSVerify` parameter is set to `true`.
+link:https://issues.redhat.com/browse/OADP-3143[OADP-3143]
+
+.Kopia does not delete artifacts after backup expiration
+
+Even after you delete a backup, Kopia does not delete the volume artifacts from the `${bucket_name}/kopia/${namespace}` on the S3 location after backup expired. For more information, see "About Kopia repository maintenance".
+link:https://issues.redhat.com/browse/OADP-5131[OADP-5131]
\ No newline at end of file
diff --git a/modules/oadp-1-4-3-release-notes.adoc b/modules/oadp-1-4-3-release-notes.adoc
new file mode 100644
index 000000000000..cdf4677725b9
--- /dev/null
+++ b/modules/oadp-1-4-3-release-notes.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/oadp-1-4-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="oadp-1-4-3-release-notes_{context}"]
+= {oadp-short} 1.4.3 release notes
+
+The {oadp-first} 1.4.3 release notes lists the following new feature. 
+
+[id="new-features-1-4-3_{context}"]
+== New features
+
+.Notable changes in the `kubevirt` velero plugin in version 0.7.1
+
+With this release, the `kubevirt` velero plugin has been updated to version 0.7.1. Notable improvements include the following bug fix and new features:
+
+* Virtual machine instances (VMIs) are no longer ignored from backup when the owner VM is excluded.
+* Object graphs now include all extra objects during backup and restore operations.
+* Optionally generated labels are now added to new firmware Universally Unique Identifiers (UUIDs) during restore operations.
+* Switching VM run strategies during restore operations is now possible.
+* Clearing a MAC address by label is now supported.
+* The restore-specific checks during the backup operation are now skipped.
+* The `VirtualMachineClusterInstancetype` and `VirtualMachineClusterPreference` custom resource definitions (CRDs) are now supported.
+//link:https://issues.redhat.com/browse/OADP-5551[OADP-5551]
\ No newline at end of file
diff --git a/modules/oadp-1-4-4-release-notes.adoc b/modules/oadp-1-4-4-release-notes.adoc
new file mode 100644
index 000000000000..37a5ce11e404
--- /dev/null
+++ b/modules/oadp-1-4-4-release-notes.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/oadp-1-4-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="oadp-1-4-4-release-notes_{context}"]
+= {oadp-short} 1.4.4 release notes
+
+{oadp-first} 1.4.4 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of {oadp-short} 1.4.3.
+
+[id="known-issues-1-4-4_{context}"]
+== Known issues
+
+.Issue with restoring stateful applications 
+When you restore a stateful application that uses the `azurefile-csi` storage class, the restore operation remains in the `Finalizing` phase. link:https://issues.redhat.com/browse/OADP-5508[(OADP-5508)]
\ No newline at end of file
diff --git a/modules/oadp-configuring-dpa-multiple-bsl.adoc b/modules/oadp-configuring-dpa-multiple-bsl.adoc
index 180632a48de8..6e12e8454d69 100644
--- a/modules/oadp-configuring-dpa-multiple-bsl.adoc
+++ b/modules/oadp-configuring-dpa-multiple-bsl.adoc
@@ -7,7 +7,14 @@
 [id="oadp-configuring-dpa-multiple-bsl_{context}"]
 = Configuring the DPA with more than one BSL
 
-You can configure the DPA with more than one BSL and specify the credentials provided by the cloud provider.  
+You can configure the `DataProtectionApplication` (DPA) custom resource (CR) with more than one `BackupStorageLocation` (BSL) CR and specify the credentials provided by the cloud provider.
+
+For example, where you have configured the following two BSLs:
+
+* Configured one BSL in the DPA and set it as the default BSL.
+* Created another BSL independently by using the `BackupStorageLocation` CR.
+
+As you have already set the BSL created through the DPA as the default, you cannot set the independently created BSL again as the default. This means, at any given time, you can set only one BSL as the default BSL.
 
 .Prerequisites
 
@@ -16,7 +23,7 @@ You can configure the DPA with more than one BSL and specify the credentials pro
 
 .Procedure
 
-. Configure the DPA with more than one BSL. See the following example.
+. Configure the `DataProtectionApplication` CR with more than one `BackupStorageLocation` CR. See the following example:
 +
 .Example DPA
 [source,yaml]
diff --git a/modules/oadp-configuring-imagepullpolicy.adoc b/modules/oadp-configuring-imagepullpolicy.adoc
new file mode 100644
index 000000000000..24a5e1f34a09
--- /dev/null
+++ b/modules/oadp-configuring-imagepullpolicy.adoc
@@ -0,0 +1,65 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.adoc
+
+
+:_mod-docs-content-type: PROCEDURE
+[id="oadp-configuring-imagepullpolicy_{context}"]
+= Overriding the imagePullPolicy setting in the DPA 
+
+In {oadp-short} 1.4.0 or earlier, the Operator sets the `imagePullPolicy` field of the Velero and node agent pods to `Always` for all images.
+
+In {oadp-short} 1.4.1 or later, the Operator first checks if each image has the `sha256` or `sha512` digest and sets the `imagePullPolicy` field accordingly:
+
+* If the image has the digest, the Operator sets `imagePullPolicy` to `IfNotPresent`.
+* If the image does not have the digest, the Operator sets `imagePullPolicy` to `Always`.
+
+You can also override the `imagePullPolicy` field by using the `spec.imagePullPolicy` field in the Data Protection Application (DPA).
+
+.Prerequisites
+
+* You have installed the {oadp-short} Operator.
+
+.Procedure
+
+* Configure the `spec.imagePullPolicy` field in the DPA as shown in the following example:
++
+.Example Data Protection Application
+[source,yaml]
+----
+apiVersion: oadp.openshift.io/v1alpha1
+kind: DataProtectionApplication
+metadata:
+  name: test-dpa
+  namespace: openshift-adp
+spec:
+  backupLocations:
+    - name: default
+      velero:
+        config:          
+          insecureSkipTLSVerify: "true"
+          profile: "default"
+          region: <bucket_region> 
+          s3ForcePathStyle: "true"
+          s3Url: <bucket_url>
+        credential:
+          key: cloud
+          name: cloud-credentials
+        default: true
+        objectStorage:
+          bucket: <bucket_name> 
+          prefix: velero
+        provider: aws
+  configuration:
+    nodeAgent:
+      enable: true
+      uploaderType: kopia
+    velero:
+      defaultPlugins:
+        - openshift
+        - aws
+        - kubevirt
+        - csi
+  imagePullPolicy: Never # <1> 
+----
+<1> Specify the value for `imagePullPolicy`. In this example, the `imagePullPolicy` field is set to `Never`.
\ No newline at end of file
diff --git a/modules/oadp-creating-restore-cr.adoc b/modules/oadp-creating-restore-cr.adoc
index 52f394b1048d..03520505aef4 100644
--- a/modules/oadp-creating-restore-cr.adoc
+++ b/modules/oadp-creating-restore-cr.adoc
@@ -8,6 +8,11 @@
 
 You restore a `Backup` custom resource (CR) by creating a `Restore` CR.
 
+[NOTE]
+====
+When you restore a stateful application that uses the `azurefile-csi` storage class, the restore operation remains in the `Finalizing` phase. 
+====
+
 .Prerequisites
 
 * You must install the OpenShift API for Data Protection (OADP) Operator.
@@ -119,4 +124,4 @@ EOF
     fi
 done
 ----
-====
+====
\ No newline at end of file
diff --git a/modules/oadp-debugging-oc-cli.adoc b/modules/oadp-debugging-oc-cli.adoc
index e4d15c9d93b6..3c470d2ad1d0 100644
--- a/modules/oadp-debugging-oc-cli.adoc
+++ b/modules/oadp-debugging-oc-cli.adoc
@@ -63,4 +63,4 @@ The following `logLevel` values are available:
 * `fatal`
 * `panic`
 
-It is recommended to use `debug` for most logs.
+It is recommended to use the `info` `logLevel` value for most logs.
diff --git a/modules/oadp-gcp-wif-cloud-authentication.adoc b/modules/oadp-gcp-wif-cloud-authentication.adoc
index 5b80e7f44df7..dcb747e496bc 100644
--- a/modules/oadp-gcp-wif-cloud-authentication.adoc
+++ b/modules/oadp-gcp-wif-cloud-authentication.adoc
@@ -25,7 +25,7 @@ If you do not use Google workload identity federation cloud authentication, cont
 
 .Prerequisites
 
-* You have installed a cluster in manual mode with link:https://docs.openshift.com/container-platform/4.17/installing/installing_gcp/installing-gcp-customizations.html#installing-gcp-with-short-term-creds_installing-gcp-customizations[GCP Workload Identity configured].
+* You have installed a cluster in manual mode with link:https://docs.openshift.com/container-platform/4.18/installing/installing_gcp/installing-gcp-customizations.html#installing-gcp-with-short-term-creds_installing-gcp-customizations[GCP Workload Identity configured].
 * You have access to the Cloud Credential Operator utility (`ccoctl`) and to the associated workload identity pool.
 
 .Procedure
diff --git a/modules/oadp-ibm-power-test-support.adoc b/modules/oadp-ibm-power-test-support.adoc
index f7197f8bfa55..319b26f08423 100644
--- a/modules/oadp-ibm-power-test-support.adoc
+++ b/modules/oadp-ibm-power-test-support.adoc
@@ -6,7 +6,5 @@
 [id="oadp-ibm-power-test-matrix_{context}"]
 = OADP support for target backup locations using {ibm-power-title}
 
-* {ibm-power-name} running with {product-title} 4.11 and 4.12, and {oadp-first} 1.1.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.11 and 4.12, and {oadp-short} 1.1.7 against all S3 backup location targets, which are not AWS, as well.
-* {ibm-power-name} running with {product-title} 4.12, 4.13, 4.14, and 4.15, and {oadp-short} 1.2.3 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.12, 4.13. 4.14, and 4.15, and {oadp-short} 1.2.3 against all S3 backup location targets, which are not AWS, as well.
 * {ibm-power-name} running with {product-title} 4.12, 4.13, 4.14, and 4.15, and {oadp-short} {oadp-version-1-3} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.13, 4.14, and 4.15, and {oadp-short} {oadp-version-1-3} against all S3 backup location targets, which are not AWS, as well.
-* {ibm-power-name} running with {product-title} 4.14, 4.15, and 4.16, and {oadp-short} {oadp-version-1-4} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.14, 4.15, and 4.16, and {oadp-short} {oadp-version-1-4} against all S3 backup location targets, which are not AWS, as well.
+* {ibm-power-name} running with {product-title} 4.14, 4.15, 4.16, and 4.17, and {oadp-short} {oadp-version-1-4} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.14, 4.15, 4.16, and 4.17, and {oadp-short} {oadp-version-1-4} against all S3 backup location targets, which are not AWS, as well.
diff --git a/modules/oadp-ibm-z-test-support.adoc b/modules/oadp-ibm-z-test-support.adoc
index 1ab726c3926c..9fa240bacae4 100644
--- a/modules/oadp-ibm-z-test-support.adoc
+++ b/modules/oadp-ibm-z-test-support.adoc
@@ -6,7 +6,5 @@
 [id="oadp-ibm-z-test-support_{context}"]
 = OADP testing and support for target backup locations using {ibm-z-title}
 
-* {ibm-z-name} running with {product-title} 4.11 and 4.12, and {oadp-first} 1.1.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.11 and 4.12, and {oadp-short} 1.1.7 against all S3 backup location targets, which are not AWS, as well.
-* {ibm-z-name} running with {product-title} 4.12, 4.13, 4.14, and 4.15, and {oadp-short} 1.2.3 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.12, 4.13, 4.14 and 4.15, and {oadp-short} 1.2.3 against all S3 backup location targets, which are not AWS, as well.
 * {ibm-z-name} running with {product-title} 4.12, 4.13, 4.14, and 4.15, and {oadp-version-1-3} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.13 4.14, and 4.15, and {oadp-version-1-3} against all S3 backup location targets, which are not AWS, as well.
-* {ibm-z-name} running with {product-title} 4.14, 4.15, and 4.16, and {oadp-version-1-4} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.14, 4.15, and 4.16, and {oadp-version-1-4} against all S3 backup location targets, which are not AWS, as well.
+* {ibm-z-name} running with {product-title} 4.14, 4.15, 4.16, and 4.17, and {oadp-version-1-4} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.14, 4.15, 4.16, and 4.17, and {oadp-version-1-4} against all S3 backup location targets, which are not AWS, as well.
diff --git a/modules/oadp-kopia-algorithms-benchmarking.adoc b/modules/oadp-kopia-algorithms-benchmarking.adoc
index 8e0e813db603..3cddfcd4202e 100644
--- a/modules/oadp-kopia-algorithms-benchmarking.adoc
+++ b/modules/oadp-kopia-algorithms-benchmarking.adoc
@@ -14,9 +14,11 @@ You can run Kopia commands to benchmark the hashing, encryption, and splitter al
 * You have an application with persistent volumes running in a separate namespace.
 * You have run a backup of the application with Container Storage Interface (CSI) snapshots.
 
+include::snippets/kopia-repo-config.adoc[]
+
 .Procedure
 
-. Configure a pod as shown in the following example. Make sure you are using the `oadp-mustgather` image for {oadp-short} version 1.3 and later.
+. Configure the `must-gather` pod as shown in the following example. Make sure you are using the `oadp-mustgather` image for {oadp-short} version 1.3 and later.
 +
 .Example pod configuration
 +
diff --git a/modules/oadp-kopia-configuring-algorithms.adoc b/modules/oadp-kopia-configuring-algorithms.adoc
index 6b254b547ba9..ba8961851ba1 100644
--- a/modules/oadp-kopia-configuring-algorithms.adoc
+++ b/modules/oadp-kopia-configuring-algorithms.adoc
@@ -17,6 +17,8 @@ You can use an {oadp-first} option to override the default Kopia algorithms for
 * You have installed the {oadp-short} Operator.
 * You have created the secret by using the credentials provided by the cloud provider.
 
+include::snippets/kopia-repo-config.adoc[]
+
 .Procedure
 
 * Configure the DPA with the environment variables for hashing, encryption, and splitter as shown in the following example.
diff --git a/modules/oadp-ssec-encrypted-backups-velero.adoc b/modules/oadp-ssec-encrypted-backups-velero.adoc
index da21835f5492..3802c2afe4cb 100644
--- a/modules/oadp-ssec-encrypted-backups-velero.adoc
+++ b/modules/oadp-ssec-encrypted-backups-velero.adoc
@@ -6,7 +6,7 @@
 [id="oadp-ssec-encrypted-backups-velero_{context}"]
 = Downloading a file with an SSE-C encryption key for files backed up by Velero
 
-When you are verifying an SSE-C encryption key, you can also download the file with the additional encryption key for files that were backed up with Velcro.
+When you are verifying an SSE-C encryption key, you can also download the file with the additional encryption key for files that were backed up with Velero.
 
 .Procedure
 
@@ -21,4 +21,4 @@ $ aws s3api get-object \
   --sse-customer-algorithm AES256 \
   --debug \
   velero_download.tar.gz
-----
\ No newline at end of file
+----
diff --git a/modules/oadp-ssec-encrypted-backups.adoc b/modules/oadp-ssec-encrypted-backups.adoc
index 59050f3a74f7..74eda04aea51 100644
--- a/modules/oadp-ssec-encrypted-backups.adoc
+++ b/modules/oadp-ssec-encrypted-backups.adoc
@@ -57,26 +57,12 @@ The following procedure contains an example of a `spec:backupLocations` block th
 $ dd if=/dev/urandom bs=1 count=32 > sse.key
 ----
 
-.. Encode the `sse.key` by using Base64 and save the result as a file named `sse_encoded.key` by running the following command:
-+
-[source,terminal]
-----
-$ cat sse.key | base64 > sse_encoded.key
-----
-
-.. Link the file named `sse_encoded.key` to a new file named `customer-key` by running the following command:
-+
-[source,terminal]
-----
-$ ln -s sse_encoded.key customer-key
-----
-
 . Create an {product-title} secret:
 ** If you are initially installing and configuring {oadp-short}, create the AWS credential and encryption key secret at the same time by running the following command:
 +
 [source,terminal]
 ----
-$ oc create secret generic cloud-credentials --namespace openshift-adp --from-file cloud=<path>/openshift_aws_credentials,customer-key=<path>/sse_encoded.key
+$ oc create secret generic cloud-credentials --namespace openshift-adp --from-file cloud=<path>/openshift_aws_credentials,customer-key=<path>/sse.key
 ----
 ** If you are updating an existing installation, edit the values of the `cloud-credential` `secret` block of the `DataProtectionApplication` CR manifest, as in the following example:
 +
diff --git a/modules/oadp-support-backup-data-immutability.adoc b/modules/oadp-support-backup-data-immutability.adoc
new file mode 100644
index 000000000000..1d7eef7a54be
--- /dev/null
+++ b/modules/oadp-support-backup-data-immutability.adoc
@@ -0,0 +1,29 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/installing/about-installing-oadp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="oadp-support-backup-data-immutability_{context}"]
+= OADP does not support backup data immutability
+
+Starting with {oadp-short} 1.3, backups might not function as expected when the target object storage has an immutability option configured. These immutability options are referred to by different names, for example:
+
+* S3 object lock
+* Object retention
+* Bucket versioning
+* Write Once Read Many (WORM) buckets
+
+The primary reason for the absence of support is that {oadp-short} initially saves the state of a backup as _finalizing_ and then scrutinizes whether any asynchronous operations are in progress. 
+
+With versions before {oadp-short} 1.3, object storage with an immutability configuration was also not supported. You might see some problems even though backups are working. For example, version objects are not deleted when a backup is deleted.
+
+[NOTE]
+====
+Depending on the specific provider and configuration, backups might work in some cases.
+====
+
+* AWS S3 service supports backups because an S3 object lock only applies to versioned buckets. You can still update the object data for the new version. However, when backups are deleted, old versions of the objects are not deleted.
+
+* Azure Storage Blob supports both versioned-level immutability and container-level immutability. In a versioned-level situation, data immutability can still work in {oadp-short}, but not at the container level.
+
+* GCP Cloud storage policy only supports bucket-level immutability. Therefore, it is not feasible to implement it in the GCP environment.
diff --git a/modules/oc-mirror-IDMS-ITMS-about.adoc b/modules/oc-mirror-IDMS-ITMS-about.adoc
index d9ce4deec091..291051a5ea25 100644
--- a/modules/oc-mirror-IDMS-ITMS-about.adoc
+++ b/modules/oc-mirror-IDMS-ITMS-about.adoc
@@ -4,13 +4,18 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="oc-mirror-custom-resources-v2_{context}"]
-= About custom resources generated by v2
+= About custom resources generated by oc-mirror plugin v2
 
 // Should sentence below say "to which a digest or tag refers"?
 
-With oc-mirror plugin v2, `ImageDigestMirrorSet` (IDMS) resources are generated by default if at least one image of the image set is mirrored by digest.
-`ImageTagMirrorSet` (ITMS) resources are generated if at least one image from the image set is mirrored by tag.
+The oc-mirror plugin v2 automatically generates the following custom resources:
 
-Operator Lifecycle Manager (OLM) uses the `CatalogSource` resource to retrieve information about the available Operators in the mirror registry.
+`ImageDigestMirrorSet` (IDMS):: Handles registry mirror rules when using image digest pull specifications. Generated if at least one image of the image set is mirrored by digest.
 
-The OpenShift Update Service uses the `UpdateService` resource to provide update graph data to the disconnected environment.
\ No newline at end of file
+`ImageTagMirrorSet` (ITMS):: Handles registry mirror rules when using image tag pull specifications. Generated if at least one image from the image set is mirrored by tag.
+
+`CatalogSource`:: Retrieves information about the available Operators in the mirror registry. Used by {olmv0-first}.
+
+`ClusterCatalog`:: Retrieves information about the available cluster extensions (which includes Operators) in the mirror registry. Used by {olmv1}.
+
+`UpdateService`:: Provides update graph data to the disconnected environment. Used by the OpenShift Update Service.
\ No newline at end of file
diff --git a/modules/oc-mirror-building-image-set-config-v2.adoc b/modules/oc-mirror-building-image-set-config-v2.adoc
index 968b5c84f698..aa9fed35dfb9 100644
--- a/modules/oc-mirror-building-image-set-config-v2.adoc
+++ b/modules/oc-mirror-building-image-set-config-v2.adoc
@@ -26,12 +26,12 @@ apiVersion: mirror.openshift.io/v2alpha1
 mirror:
   platform:
     channels:
-    - name: stable-4.17 <1>
-      minVersion: 4.17.2
-      maxVersion: 4.17.2
+    - name: stable-4.18 <1>
+      minVersion: 4.18.2
+      maxVersion: 4.18.2
     graph: true <2>
   operators:
-    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17 <3>
+    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18 <3>
       packages: <4>
        - name: aws-load-balancer-operator
        - name: 3scale-operator
diff --git a/modules/oc-mirror-command-reference-v2-delete.adoc b/modules/oc-mirror-command-reference-v2-delete.adoc
new file mode 100644
index 000000000000..f19bc66f560d
--- /dev/null
+++ b/modules/oc-mirror-command-reference-v2-delete.adoc
@@ -0,0 +1,72 @@
+// Module included in the following assemblies:
+//
+// * installing/disconnected_install/installing-mirroring-disconnected-v2.adoc
+
+
+:_mod-docs-content-type: REFERENCE
+[id="oc-mirror-command-reference-delete-v2_{context}"]
+= Command reference for deleting images
+
+The following tables describe the `oc mirror` subcommands and flags for deleting images:
+
+.Subcommands and flags for the deleting images
+[cols="1,2",options="header"]
+|===
+|Subcommand
+|Description
+
+|`--authfile <string>`
+|Path of the authentication file. The default value is `${XDG_RUNTIME_DIR}/containers/auth.json`.
+
+|`--cache-dir <string>` 
+|oc-mirror cache directory location. The default is `$HOME`.
+
+|`-c <string>`, `--config <string>` 
+|Path to the delete imageset configuration file.
+
+|`--delete-id <string>` 
+|Used to differentiate between versions for files created by the delete functionality.
+
+|`--delete-v1-images` 
+|Used during the migration, along with `--generate`, in order to target images previously mirrored with oc-mirror plugin v1.
+
+|`--delete-yaml-file <string>` 
+|If set, uses the generated or updated yaml file to delete contents.
+
+|`--dest-tls-verify` 
+|Require HTTPS and verify certificates when talking to the container registry or daemon. TThe default value is `true`.
+
+|`--force-cache-delete` 
+|Used to force delete the local cache manifests and blobs.
+
+|`--generate` 
+|Used to generate the delete yaml for the list of manifests and blobs, used when deleting from local cache and remote registry.
+
+|`-h`, `--help` 
+|Displays help.
+
+|`--log-level <string>` 
+|Log level one of `info`, `debug`, `trace`, and `error`. The default value is `info`.
+
+|`--parallel-images <unit>` 
+|Indicates the number of images deleted in parallel. The default value is `8`.
+
+|`--parallel-layers <unit>`          
+|Indicates the number of image layers mirrored in parallel. The default value is `10`.
+
+|`-p <unit>`, `--port <unit>` 
+|HTTP port used by oc-mirror's local storage instance. The default value is `55000`.
+
+|`--retry-delay` 
+|Duration delay between 2 retries. The default value is `1s`.
+
+|`--retry-times <int>` 
+|The number of times to retry. The default value is `2`.
+
+|`--src-tls-verify` 
+|Require HTTPS and verify certificates when talking to the container registry or daemon. The default value is `true`.
+
+|`--workspace <string>` 
+|oc-mirror workspace where resources and internal artifacts are generated.
+
+|===
\ No newline at end of file
diff --git a/modules/oc-mirror-command-reference-v2.adoc b/modules/oc-mirror-command-reference-v2.adoc
index 4e61719373ac..83e23e403fda 100644
--- a/modules/oc-mirror-command-reference-v2.adoc
+++ b/modules/oc-mirror-command-reference-v2.adoc
@@ -38,11 +38,14 @@ The following tables describe the `oc mirror` subcommands and flags for oc-mirro
 |`-c`, `--config` `<string>`
 |Specifies the path to an image set configuration file.
 
+|`--cache-dir <string>` 
+|oc-mirror cache directory location. The default value is `$HOME`.
+
 |`--dest-tls-verify`
-|Requires HTTPS and verifies certificates when accessing the container registry or daemon.
+|Requires HTTPS and verifies certificates when accessing the container registry or daemon. The default value is `true`.
 
 |`--dry-run`
-|Prints actions without mirroring images
+|Prints actions without mirroring images.
 
 |`--from <string>`
 |Specifies the path to an image set archive that was generated by executing oc-mirror plugin v2 to load a target registry.
@@ -50,17 +53,26 @@ The following tables describe the `oc mirror` subcommands and flags for oc-mirro
 |`-h`, `--help`
 |Displays help
 
-|`--loglevel` 
-|Displays string log levels. Supported values include info, debug, trace, error. The default is `info`.
+|`--image-timeout duration` 
+|Timeout for mirroring an image. The default is 10m0s. Valid time units are `ns`, `us` or `µs`, `ms`, `s`, `m`, and `h`.
+
+|`--log-level <string>`
+|Displays string log levels. Supported values include info, debug, trace, error. The default value is `info`.
 
 |`-p`, `--port` 
-|Determines the HTTP port used by oc-mirror plugin v2 local storage instance. The default is `55000`.
+|Determines the HTTP port used by oc-mirror plugin v2 local storage instance. The default value is `55000`.
+
+|`--parallel-images <unit>` 
+|Specifies the number of images mirrored in parallel. The default value is `8`.
+
+|`--parallel-layers <unit>`           
+|Specifies the number of image layers mirrored in parallel. The default value is `10`.
 
 |`--max-nested-paths <int>`
-|Specifies the maximum number of nested paths for destination registries that limit nested paths. The default is `0`.
+|Specifies the maximum number of nested paths for destination registries that limit nested paths. The default value is `0`.
 
 |`--secure-policy` 
-|Default value is `false`. If you set a non-default value, the command enables signature verification, which is the secure policy for signature verification.
+|The default value is `false`. If you set a non-default value, the command enables signature verification, which is the secure policy for signature verification.
 
 |`--since` 
 |Includes all new content since a specified date (format: `yyyy-mm-dd`). When not provided, new content since previous mirroring is mirrored.
@@ -69,7 +81,7 @@ The following tables describe the `oc mirror` subcommands and flags for oc-mirro
 |Requires HTTPS and verifies certificates when accessing the container registry or daemon.
 
 |`--strict-archive` 
-|Default value is `false`. If you set a value, the command generates archives that are strictly less than the `archiveSize` that was set in the `imageSetConfig` custom resource (CR). Mirroring exist in error if a file being archived exceeds `archiveSize` (GB).
+|The default value is `false`. If you set a value, the command generates archives that are strictly less than the `archiveSize` that was set in the `imageSetConfig` custom resource (CR). Mirroring exist in error if a file being archived exceeds `archiveSize` (GB).
 
 |`-v`, `--version` 
 |Displays the version for oc-mirror plugin v2.
@@ -77,4 +89,13 @@ The following tables describe the `oc mirror` subcommands and flags for oc-mirro
 |`--workspace` 
 |Determines string oc-mirror plugin v2 workspace where resources and internal artifacts are generated.
 
+|`--retry-delay duration` 
+|Delay between 2 retries. The default value is `1s`.
+
+|`--retry-times <int>` 
+|The number of times to retry. The default value is `2`.
+
+|`--rootless-storage-path <string>` 
+|Overrides the default container rootless storage path (usually in `etc/containers/storage.conf`).
+
 |===
\ No newline at end of file
diff --git a/modules/oc-mirror-creating-image-set-config.adoc b/modules/oc-mirror-creating-image-set-config.adoc
index b0df4cfb0a29..8dbe75e8b5bf 100644
--- a/modules/oc-mirror-creating-image-set-config.adoc
+++ b/modules/oc-mirror-creating-image-set-config.adoc
@@ -26,7 +26,7 @@ Do not delete or modify the metadata that is generated by the oc-mirror plugin.
 +
 [source,terminal]
 ----
-$ oc mirror init <--registry <storage_backend> > imageset-config.yaml <1>
+$ oc mirror init --registry <storage_backend> > imageset-config.yaml <1>
 ----
 <1> Specifies the location of your storage backend, such as `example.com/mirror/oc-mirror-metadata`.
 
diff --git a/modules/oc-mirror-disk-to-mirror.adoc b/modules/oc-mirror-disk-to-mirror.adoc
index 7164bf5da7d5..526ec87fcd0d 100644
--- a/modules/oc-mirror-disk-to-mirror.adoc
+++ b/modules/oc-mirror-disk-to-mirror.adoc
@@ -12,7 +12,7 @@ You can use the oc-mirror plugin to mirror the contents of a generated image set
 .Prerequisites
 
 * You have installed the OpenShift CLI (`oc`) in the disconnected environment.
-* You have installed the `oc-mirror` CLI plugin in the disconnected environment.
+* You have installed the oc-mirror CLI plugin in the disconnected environment.
 * You have generated the image set file by using the `oc mirror` command.
 * You have transferred the image set file to the disconnected environment.
 // TODO: Confirm prereq about not needing a cluster, but need pull secret misc
diff --git a/modules/oc-mirror-dry-run-v2.adoc b/modules/oc-mirror-dry-run-v2.adoc
index c448e3ab65e5..71de8f7ca2c9 100644
--- a/modules/oc-mirror-dry-run-v2.adoc
+++ b/modules/oc-mirror-dry-run-v2.adoc
@@ -5,7 +5,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="oc-mirror-dry-run-v2_{context}"]
-= Performing dry run for oc-mirror plugin v2
+= Performing a dry run for oc-mirror plugin v2
 
 Verify your image set configuration by performing a dry run without mirroring any images. This ensures your setup is correct and prevents unintended changes.
 
@@ -15,19 +15,18 @@ Verify your image set configuration by performing a dry run without mirroring an
 +
 [source,terminal]
 ----
-$ oc mirror -c <image_set_config_yaml> --from file://<oc_mirror_workspace_path> docker://<mirror_registry_url> --dry-run --v2
+$ oc mirror -c <image_set_config_yaml> file://<oc_mirror_workspace_path> --dry-run --v2
 ----
-Where:
-- `<image_set_config_yaml>`: Use the image set configuration file that you just created.
-- `<oc_mirror_workspace_path>`: Insert the address of the workspace path.
-- `<mirror_registry_url>`: Insert the URL or address of the remote container registry from which images will be deleted.
++
+where:
+
+`<image_set_config_yaml>`:: Specifies the image set configuration file that you created.
+`<oc_mirror_workspace_path>`:: Insert the address of the workspace path.
+`<mirror_registry_url>`:: Insert the URL or address of the remote container registry from which images will be mirrored or deleted.
 +
 .Example output
 [source,terminal]
 ----
-$ oc mirror --config /tmp/isc_dryrun.yaml file://<oc_mirror_workspace_path> --dry-run --v2
-
-[INFO]   : :warning:  --v2 flag identified, flow redirected to the oc-mirror v2 version. This is Tech Preview, it is still under development and it is not production ready.
 [INFO]   : :wave: Hello, welcome to oc-mirror
 [INFO]   : :gear:  setting up the environment for you...
 [INFO]   : :twisted_rightwards_arrows: workflow mode: mirrorToDisk 
diff --git a/modules/oc-mirror-dry-run.adoc b/modules/oc-mirror-dry-run.adoc
index aa2c7fa4d3e3..65b2d368741f 100644
--- a/modules/oc-mirror-dry-run.adoc
+++ b/modules/oc-mirror-dry-run.adoc
@@ -14,7 +14,7 @@ You can use oc-mirror to perform a dry run, without actually mirroring any image
 
 * You have access to the internet to obtain the necessary container images.
 * You have installed the OpenShift CLI (`oc`).
-* You have installed the `oc-mirror` CLI plugin.
+* You have installed the oc-mirror CLI plugin.
 * You have created the image set configuration file.
 
 .Procedure
diff --git a/modules/oc-mirror-enclave-support-about.adoc b/modules/oc-mirror-enclave-support-about.adoc
index 448fd28bb3cc..f1eb7d12876a 100644
--- a/modules/oc-mirror-enclave-support-about.adoc
+++ b/modules/oc-mirror-enclave-support-about.adoc
@@ -8,9 +8,6 @@
 
 Enclave support restricts internal access to a specific part of a network. Unlike a demilitarized zone (DMZ) network, which allows inbound and outbound traffic access through firewall boundaries, enclaves do not cross firewall boundaries.
 
-:FeatureName: Enclave Support
-include::snippets/technology-preview.adoc[]
-
 The new enclave support functionality is for scenarios where mirroring is needed for multiple enclaves that are secured behind at least one intermediate disconnected network.
 
 Enclave support has the following benefits:
diff --git a/modules/oc-mirror-image-set-config-examples.adoc b/modules/oc-mirror-image-set-config-examples.adoc
index 8c840b1b272d..0cbcc9e9f283 100644
--- a/modules/oc-mirror-image-set-config-examples.adoc
+++ b/modules/oc-mirror-image-set-config-examples.adoc
@@ -283,7 +283,7 @@ mirror:
 [id="oc-mirror-image-set-examples-mce-images-catalog-ocp_{context}"]
 == Use case: Including the multi-arch {product-title} images and catalog for {mce-short}
 
-The following `ImageSetConfiguration` file includes {mce} and all {product-title} versions starting at a minimum version of `4.17.0` in the channel.  
+The following `ImageSetConfiguration` file includes {mce} and all {product-title} versions starting at a minimum version of `4.18.0` in the channel.  
 
 .Example `ImageSetConfiguration` file
 [source,yaml,subs=attributes+]
@@ -298,12 +298,12 @@ mirror:
     architectures:
       - "multi"
     channels:
-    - name: stable-4.17
-      minVersion: 4.17.0
-      maxVersion: 4.17.1
+    - name: stable-4.18
+      minVersion: 4.18.0
+      maxVersion: 4.18.1
       type: ocp
   operators:
-    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
+    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18
       packages:
         - name: multicluster-engine
 ----
\ No newline at end of file
diff --git a/modules/oc-mirror-imageset-config-parameters-v2.adoc b/modules/oc-mirror-imageset-config-parameters-v2.adoc
index da7f50ef8693..9b25de62ad75 100644
--- a/modules/oc-mirror-imageset-config-parameters-v2.adoc
+++ b/modules/oc-mirror-imageset-config-parameters-v2.adoc
@@ -77,6 +77,70 @@ Example: `registry.redhat.io/ubi8/ubi:latest`
 |Array of strings 
 Example: `docker.io/library/alpine`
 
+|`mirror.helm`
+|The helm configuration of the image set. The oc-mirror plugin does not support helm charts with manually modified `values.yaml` files.
+|Object
+
+|`mirror.helm.local`
+|The local helm charts to mirror.
+|Array of objects. For example:
+
+[source,yaml]
+----
+local:
+  - name: podinfo
+    path: /test/podinfo-5.0.0.tar.gz
+----
+
+|`mirror.helm.local.name`
+|The name of the local helm chart to mirror.
+|String. For example: `podinfo`.
+
+|`mirror.helm.local.path`
+|The path of the local helm chart to mirror.
+|String. For example: `/test/podinfo-5.0.0.tar.gz`.
+
+|`mirror.helm.repositories`
+|The remote helm repositories to mirror from.
+|Array of objects. For example:
+
+[source,yaml]
+----
+repositories:
+  - name: podinfo
+    url: https://example.github.io/podinfo
+    charts:
+      - name: podinfo
+        version: 5.0.0
+         imagePaths:
+         - "{.spec.template.spec.custom[*].image}"
+----
+
+|`mirror.helm.repositories.name`
+|The name of the helm repository to mirror from.
+|String. For example: `podinfo`.
+
+|`mirror.helm.repositories.url`
+|The URL of the helm repository to mirror from.
+|String. For example: [x-]`https://example.github.io/podinfo`.
+
+|`mirror.helm.repositories.charts`
+|The remote helm charts to mirror.
+|Array of objects.
+
+|`mirror.helm.repositories.charts.name`
+|The name of the helm chart to mirror.
+|String. For example: `podinfo`.
+
+|`mirror.helm.repositories.charts.imagePaths`
+|The custom path of a container image inside of the helm chart. 
++
+[NOTE] 
+====
+`oc-mirror` detects and mirrors container images from the helm chart by searching well-known paths. You can also specify custom paths using this field.
+====
+|Array of string. For example:  `"- {.spec.template.spec.custom[*].image}"`.
+
 |`mirror.operators`
 |The Operators configuration of the image set.
 |Array of objects 
@@ -149,26 +213,6 @@ Example: `5.2.3-31`
 |String 
 Example: `5.2.3-31`
 
-|`mirror.operators.packages.bundles`
-|Selected bundles configuration
-|Array of objects 
-
-Example:
-[source,yaml,subs="attributes+"]
-----
-operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
-    packages:
-    - name: 3scale-operator
-      bundles:
-      - name: 3scale-operator.v0.10.0-mas
-----
-
-|`mirror.operators.packages.bundles.name`
-|Name of the bundle selected for mirror (as it appears in the catalog).
-|String 
-Example : `3scale-operator.v0.10.0-mas`
-
 |`mirror.operators.targetCatalog`
 |An alternative name and optional namespace hierarchy to mirror the referenced catalog as
 |String 
@@ -374,28 +418,6 @@ Example: `5.2.3-31`
 |String 
 Example: `5.2.3-31`
 
-|`delete.operators.packages.bundles`
-|The selected bundles configuration
-|Array of objects
-
-You cannot choose both channels and bundles for the same operator.
-
-Example:  
-[source,yaml]
-----
-operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
-    packages:
-    - name: 3scale-operator
-      bundles:
-      - name: 3scale-operator.v0.10.0-mas
-----
-
-|`delete.operators.packages.bundles.name`
-|Name of the bundle selected to delete (as it is displayed in the catalog)
-|String 
-Example : `3scale-operator.v0.10.0-mas`
-
 |`delete.platform`
 |The platform configuration of the image set
 |Object
diff --git a/modules/oc-mirror-imageset-config-params.adoc b/modules/oc-mirror-imageset-config-params.adoc
index 4bf9c1505f19..c676981bd5a1 100644
--- a/modules/oc-mirror-imageset-config-params.adoc
+++ b/modules/oc-mirror-imageset-config-params.adoc
@@ -129,7 +129,7 @@ operators:
 
 |`mirror.operators.catalog`
 |The Operator catalog to include in the image set.
-|String. For example: `registry.redhat.io/redhat/redhat-operator-index:v4.17`.
+|String. For example: `registry.redhat.io/redhat/redhat-operator-index:v4.18`.
 
 |`mirror.operators.full`
 |When `true`, downloads the full catalog, Operator package, or Operator channel.
@@ -158,7 +158,7 @@ operators:
 
 |`mirror.operators.packages.channels.name`
 |The Operator channel name, unique within a package, to include in the image set.
-|String. For example: `fast` or `stable-v4.17`.
+|String. For example: `fast` or `stable-v4.18`.
 
 |`mirror.operators.packages.channels.maxVersion`
 |The highest version of the Operator mirror across all channels in which it exists. See the following note for further information.
@@ -238,7 +238,7 @@ channels:
 
 |`mirror.platform.channels.name`
 |The name of the release channel.
-|String. For example: `stable-4.17`
+|String. For example: `stable-4.18`
 
 |`mirror.platform.channels.minVersion`
 |The minimum version of the referenced platform to be mirrored.
@@ -246,7 +246,7 @@ channels:
 
 |`mirror.platform.channels.maxVersion`
 |The highest version of the referenced platform to be mirrored.
-|String. For example: `4.17.1`
+|String. For example: `4.18.1`
 
 |`mirror.platform.channels.shortestPath`
 |Toggles shortest path mirroring or full range mirroring.
diff --git a/modules/oc-mirror-migration-differences.adoc b/modules/oc-mirror-migration-differences.adoc
new file mode 100644
index 000000000000..44c203d6ed81
--- /dev/null
+++ b/modules/oc-mirror-migration-differences.adoc
@@ -0,0 +1,69 @@
+// Module included in the following assemblies:
+//
+// * disconnected/mirroring/oc-mirror-migration-v1-to-v2.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="oc-mirror-migration-differences_{context}"]
+= Changes from oc-mirror plugin v1 to v2
+
+Before migrating from oc-mirror plugin v1 to v2, see the following differences between oc-mirror plugin v1 and v2:
+
+* Explicit version selection: Users must explicitly specify `--v2` when using `oc-mirror`. If no version is specified, v1 is executed by default. This behavior is expected to change in future releases, where `--v2` will be the default.
+
+* Updated commands: Commands for mirroring workflows have changed to align with oc-mirror plugin v2's new workflow.
+
+** For mirror-to-disk, run the following command:
++
+[source,terminal]
+----
+$ oc-mirror --config isc.yaml file://<directory_name> --v2
+----
+
+** For disk-to-mirror, run the following command:
++
+[source,terminal]
+----
+$ oc-mirror --config isc.yaml --from file://<directory_name> docker://<remote_registry> --v2
+----
+
+** For mirror-to-mirror, run the following command:
++
+[source,terminal]
+----
+$ oc-mirror --config isc.yaml --workspace file://<directory_name> docker://<remote_registry> --v2
+----
++
+[NOTE]
+====
+`--workspace` is now required for mirror-to-mirror operation.
+====
+
+* API version update: The `ImageSetConfiguration` API version changes from `v1alpha2` (v1) to `v2alpha1` (v2). You must manually update the configuration files before migration.
+
+* Configuration changes: 
+- `storageConfig` must be removed in oc-mirror plugin v2. 
+- Incremental mirroring is now handled automatically through the working directory or local cache.
+
+* Changes in results directory: All custom resources to be applied to the disconnected cluster are generated in the `<workspace_path>/working-dir/cluster-resources` directory after the migration.
+- Outputs in oc-mirror plugin v2 are not stored in the same location as oc-mirror plugin v1.
+- You must check the `cluster-resources` folder under the working directory for the following resources:
+** `ImageDigestMirrorSet` (IDMS)
+** `ImageTagMirrorSet` (ITMS)
+** `CatalogSource`
+** `ClusterCatalog`
+** `UpdateService`
+
+* Workspace and directory naming: Follow the new oc-mirror v2 convention to prevent any potential data inconsistencies when transitioning between versions.
+- The oc-mirror plugin v1 `oc-mirror-workspace` directory is no longer needed.
+- Use a new directory for oc-mirror plugin v2 to avoid conflicts.
+
+* Replacing `ImageContentSourcePolicy` (ICSP) resources with IDMS/ITMS:
++
+[IMPORTANT]
+====
+Deleting all `ImageContentSourcePolicy` (ICSP) resources might remove configurations unrelated to oc-mirror.
+
+To avoid unintended deletions, identify ICSP resources generated by oc-mirror before removing them. If you are unsure, check with your cluster administrator. For more information, see "Mirroring images for a disconnected installation by using the oc-mirror plugin v2".
+====
+
+- In oc-mirror plugin v2, the ICSP resource is replaced by `ImageDigestMirrorSet` (IDMS) and `ImageTagMirrorSet` (ITMS) resources.
\ No newline at end of file
diff --git a/modules/oc-mirror-migration-process.adoc b/modules/oc-mirror-migration-process.adoc
new file mode 100644
index 000000000000..97dd30602c7e
--- /dev/null
+++ b/modules/oc-mirror-migration-process.adoc
@@ -0,0 +1,126 @@
+// Module included in the following assemblies:
+//
+// * disconnected/mirroring/oc-mirror-migration-v1-to-v2.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="oc-mirror-migration-process_{context}"]
+= Migrating to oc-mirror plugin v2
+
+To migrate from oc-mirror plugin v1 to v2, you must manually update the `ImageSetConfiguration` file, modify mirroring commands, and clean up v1 artifacts. Follow these steps to complete the migration.
+
+.Procedure
+
+. Modify the API version and remove deprecated fields in your `ImageSetConfiguration`.
++
+.Example `ImageSetConfiguration` file with oc-mirror plugin v1 configuration
+[source,yaml]
+----
+kind: ImageSetConfiguration
+apiVersion: mirror.openshift.io/v1alpha2
+mirror:
+  platform:
+    channels:
+      - name: stable-4.17
+    graph: true
+  helm:
+    repositories:
+      - name: sbo
+        url: https://redhat-developer.github.io/service-binding-operator-helm-chart/
+  additionalImages:
+    - name: registry.redhat.io/ubi8/ubi:latest
+    - name: quay.io/openshifttest/hello-openshift@sha256:example_hash
+  operators:
+    - catalog: oci:///test/redhat-operator-index
+      packages:
+        - name: aws-load-balancer-operator
+storageConfig:  # REMOVE this field in v2
+  local:
+    path: /var/lib/oc-mirror
+----
++
+.Example `ImageSetConfiguration` file with oc-mirror plugin v2 configuration
+[source,yaml]
+----
+kind: ImageSetConfiguration
+apiVersion: mirror.openshift.io/v2alpha1
+mirror:
+  platform:
+    channels:
+      - name: stable-4.17
+    graph: true
+  helm:
+    repositories:
+      - name: sbo
+        url: https://redhat-developer.github.io/service-binding-operator-helm-chart/
+  additionalImages:
+    - name: registry.redhat.io/ubi8/ubi:latest
+    - name: quay.io/openshifttest/hello-openshift@sha256:example_hash
+  operators:
+    - catalog: oci:///test/redhat-operator-index
+      packages:
+        - name: aws-load-balancer-operator
+----
+
+. Check the `cluster-resources` directory inside the working directory for IDMS, ITMS, `CatalogSource`, and `ClusterCatalog` resources by running the following command:
++
+[source,terminal]
+----
+$ ls <v2_workspace>/working-dir/cluster-resources/
+----
+
+. Once the migration is complete, verify that mirrored images and catalogs are available:
+- Ensure that no errors or warnings occurred during mirroring.
+- Ensure that no error file was generated (`working-dir/logs/mirroring_errors_YYYYMMdd_HHmmss.txt`).
+
+. Verify that mirrored images and catalogs are available using the following the commands:
++
+[source,terminal]
+----
+$ oc get catalogsource -n openshift-marketplace
+----
++
+[source,terminal]
+----
+$ oc get imagedigestmirrorset,imagetagmirrorset
+----
++
+For more information, refer to "Mirroring images for a disconnected installation using oc-mirror plugin v2".
+
+. Optional: Remove images mirrored using oc-mirror plugin v1:
+
+.. Mirror the images using oc-mirror plugin v1.
+
+.. Update the API version in the `ImageSetConfiguration` file from `v1alpha2` (v1) to `v2alpha1` (v2), then run the following command:
++
+[source,terminal]
+----
+$ oc-mirror -c isc.yaml file://some-dir --v2
+----
++
+[NOTE]
+====
+`storageConfig` is not a valid field in the `ImageSetConfiguration` and `DeleteImageSetConfiguration` files. Remove this field when updating to oc-mirror plugin v2.
+====
+
+.. Generate a delete manifest and delete v1 images by running the following command:
++
+[source,terminal]
+----
+$ oc-mirror delete --config=delete-isc.yaml --generate --delete-v1-images --workspace file://some-dir docker://registry.example:5000  --v2
+----
++
+[IMPORTANT]
+====
+oc-mirror plugin v2 does not automatically prune the destination registry, unlike oc-mirror plugin v1. To clean up images that are no longer needed, use the delete functionality in v2 with the `--delete-v1-images` command flag.
+
+Once all images mirrored with oc-mirror plugin v1 are removed, you no longer need to use this flag. If you need to delete images mirrored with oc-mirror plugin v2, do not set `--delete-v1-images`.
+====
++
+For more information about deleting images, see "Deletion of images from your disconnected environment".
+
+.. Delete images based on the generated manifest by running the following command:
++
+[source,terminal]
+----
+$ oc-mirror delete --delete-yaml-file some-dir/working-dir/delete/delete-images.yaml docker://registry.example:5000 --v2
+----
diff --git a/modules/oc-mirror-mirror-to-disk.adoc b/modules/oc-mirror-mirror-to-disk.adoc
index 831b0937c974..762c2c354dd2 100644
--- a/modules/oc-mirror-mirror-to-disk.adoc
+++ b/modules/oc-mirror-mirror-to-disk.adoc
@@ -27,7 +27,7 @@ Do not delete or modify the metadata that is generated by the oc-mirror plugin.
 
 * You have access to the internet to obtain the necessary container images.
 * You have installed the OpenShift CLI (`oc`).
-* You have installed the `oc-mirror` CLI plugin.
+* You have installed the oc-mirror CLI plugin.
 * You have created the image set configuration file.
 // TODO: Don't need a running cluster, but need some pull secrets. Sync w/ team on this
 
diff --git a/modules/oc-mirror-mirror-to-mirror.adoc b/modules/oc-mirror-mirror-to-mirror.adoc
index 72e8683a37f5..0dd49bc8a967 100644
--- a/modules/oc-mirror-mirror-to-mirror.adoc
+++ b/modules/oc-mirror-mirror-to-mirror.adoc
@@ -21,7 +21,7 @@ Do not delete or modify the metadata that is generated by the oc-mirror plugin.
 
 * You have access to the internet to get the necessary container images.
 * You have installed the OpenShift CLI (`oc`).
-* You have installed the `oc-mirror` CLI plugin.
+* You have installed the oc-mirror CLI plugin.
 * You have created the image set configuration file.
 
 .Procedure
diff --git a/modules/oc-mirror-oci-format.adoc b/modules/oc-mirror-oci-format.adoc
index a716103c9c28..b1fe0b208b34 100644
--- a/modules/oc-mirror-oci-format.adoc
+++ b/modules/oc-mirror-oci-format.adoc
@@ -29,7 +29,7 @@ If you used the Technology Preview OCI local catalogs feature for the oc-mirror
 
 * You have access to the internet to obtain the necessary container images.
 * You have installed the OpenShift CLI (`oc`).
-* You have installed the `oc-mirror` CLI plugin.
+* You have installed the oc-mirror CLI plugin.
 
 .Procedure
 
diff --git a/modules/oc-mirror-operator-catalog-filtering.adoc b/modules/oc-mirror-operator-catalog-filtering.adoc
index 46d734131042..4c0de65dc830 100644
--- a/modules/oc-mirror-operator-catalog-filtering.adoc
+++ b/modules/oc-mirror-operator-catalog-filtering.adoc
@@ -10,10 +10,6 @@ oc-mirror plugin v2 selects the list of bundles for mirroring by processing the
 
 When oc-mirror plugin v2 selects bundles for mirroring, it does not infer Group Version Kind (GVK) or bundle dependencies, omitting them from the mirroring set. Instead, it strictly adheres to the user instructions. You must explicitly specify any required dependent packages and their versions.
 
-Bundle versions typically use semantic versioning standards (SemVer), and you can sort bundles within a channel by version. You can select buncles that fall within a specific range in the `ImageSetConfig`.
-
-This selection algorithm ensures consistent outcomes compared to oc-mirror plugin v1. However, it does not include upgrade graph details, such as `replaces`, `skip`, and `skipRange`. This approach differs from the OLM algorithm. It might mirror more bundles than necessary for upgrading a cluster because of potentially shorter upgrade paths between the `minVersion` and `maxVersion`.
-
 .Use the following table to see what bundle versions are included in different scenarios
 [cols="1,2",options="header"]
 
@@ -31,7 +27,7 @@ mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
 ----
-|For each package in the catalog, 1 bundle, corresponding to the head version of the default channel for that package.
+|For each package in the catalog, one bundle, corresponding to the head version for each channel of that package.
 
 a|Scenario 2
 
@@ -42,7 +38,7 @@ mirror:
     - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
       full: true
 ----
-|All bundles of all channels of the specified catalog
+|All bundles of all channels of the specified catalog.
 
 a|Scenario 3
 
@@ -54,7 +50,7 @@ mirror:
      packages: 
     - name: compliance-operator
 ----
-|One bundle, corresponding to the head version of the default channel for that package
+|One bundle, corresponding to the head version for each channel of that package.
 
 a|Scenario 4
 
@@ -67,7 +63,7 @@ mirror:
       - packages:
           - name: elasticsearch-operator
 ----
-|All bundles of all channels for the packages specified
+|All bundles of all channels for the packages specified.
 
 a|Scenario 5
 
@@ -80,7 +76,7 @@ mirror:
     - name: compliance-operator
        minVersion: 5.6.0
 ----
-|All bundles in the default channel, from the `minVersion`, up to the channel head for that package that do not rely on the shortest path from upgrade the graph.
+|All bundles in all channels, from the `minVersion`, up to the channel head for that package.
 
 a|Scenario 6
 
@@ -93,7 +89,7 @@ mirror:
     - name: compliance-operator
         maxVersion: 6.0.0
 ----
-|All bundles in the default channel that are lower than the `maxVersion` for that package.
+|All bundles in all channels that are lower than the `maxVersion` for that package.
 
 a|Scenario 7
 
@@ -107,7 +103,7 @@ mirror:
         minVersion: 5.6.0
         maxVersion: 6.0.0
 ----
-|All bundles in the default channel, between the `minVersion` and `maxVersion` for that package. The head of the channel is not included, even if multiple channels are included in the filtering.
+|All bundles in all channels, between the `minVersion` and `maxVersion` for that package. The head of the channel is not included, even if multiple channels are included in the filtering.
 
 a|Scenario 8
 
@@ -121,7 +117,7 @@ mirror:
         channels
           - name: stable
 ----
-|The head bundle for the selected channel of that package.
+|The head bundle for the selected channel of that package. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 9
 
@@ -136,7 +132,8 @@ mirror:
             channels:
                - name: 'stable-v0'
 ----
-|All bundles for the specified packages and channels.
+|All bundles for the packages and channels specified.
+The `defaultChannel` should be used in case the filtered channels are not the default.
 
 a|Scenario 10
 
@@ -166,7 +163,7 @@ mirror:
           - name: stable
             minVersion: 5.6.0
 ----
-|Within the selected channel of that package, all versions starting with the `minVersion` up to the channel head. This scenario does not relyon the shortest path from the upgrade graph.
+|Within the selected channel of that package, all versions starting with the `minVersion` up to the channel head. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 12
 
@@ -181,7 +178,9 @@ mirror:
           - name: stable
             maxVersion: 6.0.0
 ----
-|Within the selected channel of that package, all versions up to the `maxVersion` (not relying on the shortest path from the upgrade graph). The head of the channel is not included, even if multiple channels are included in the filtering.
+|Within the selected channel of that package, all versions up to `maxVersion`.
+Head of channel is not included, even if multiple channels are included in the filtering.
+You might see errors if this filtering leads to a channel with multiple heads. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 13
 
@@ -197,27 +196,11 @@ mirror:
             minVersion: 5.6.0
             maxVersion: 6.0.0
 ----
-|Within the selected channel of that package, all versions between the `minVersion` and `maxVersion`, not relying on the shortest path from the upgrade graph. The head of the channel is not included, even if multiple channels are included in the filtering.
+|Within the selected channel of that package, all versions between the `minVersion` and `maxVersion`. The head of channel is not included, even if multiple channels are included in the filtering.
+You might see errors if this filtering leads to a channel with multiple heads. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 14
 
-[source,yaml]
-----
-mirror:
-  operators:
-  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
-    packages:
-    - name: aws-load-balancer-operator
-      bundles:
-      - name: aws-load-balancer-operator.v1.1.0
-    - name: 3scale-operator
-      bundles:
-      - name: 3scale-operator.v0.10.0-mas
-----
-|Only the bundles specified for each package are included in the filtering.
-
-a|Scenario 15
-
 [source,yaml]
 ----
 mirror:
@@ -232,7 +215,7 @@ mirror:
 ----
 |Do not use this scenario. filtering by channel and by package with a `minVersion` or `maxVersion` is not allowed.
 
-a|Scenario 16
+a|Scenario 15
 
 [source,yaml]
 ----
@@ -248,7 +231,7 @@ mirror:
 ----
 |Do not use this scenario. You cannot filter using `full:true` and the `minVersion` or `maxVersion`.
 
-a|Scenario 17
+a|Scenario 16
 
 [source,yaml]
 ----
diff --git a/modules/oc-mirror-procedure-delete-v2.adoc b/modules/oc-mirror-procedure-delete-v2.adoc
index 87128ec2a85b..4beffd251669 100644
--- a/modules/oc-mirror-procedure-delete-v2.adoc
+++ b/modules/oc-mirror-procedure-delete-v2.adoc
@@ -38,18 +38,15 @@ delete:
          minVersion: <operator_max_version> <5>
          maxVersion: <operator_min_version> <5>
   additionalImages:
-    - name: <additional_images> <6>
+    - name: <additional_images>
 ----
 <1> Specify the name of the {product-title} channel to delete, for example `stable-4.15`.
 <2> Specify a version range of the images to delete within the channel, for example `4.15.0` for the minimum version and `4.15.1` for the maximum version.
 To delete only one version's images, use that version number for both the `minVersion` and `maxVersion` fields.
-<3> Specify an Operator catalog image to delete, for example `registry.redhat.io/redhat/redhat-operator-index:v4.14`.
-To delete the catalog image, you must not specify individual Operators using the `delete.operators.packages` parameter.
-<4> Specify a specific Operator bundle to delete, for example `aws-load-balancer-operator`.
-If you specify individual Operators, the Operator catalog image does not get deleted.
+<3> Specify an Operator catalog image containing the Operators to delete, for example `registry.redhat.io/redhat/redhat-operator-index:v4.14`.
+The Operator catalog image will not get deleted. Its presence in the registry might be necessary for other Operators still remaining on the cluster.
+<4> Specify a specific Operator to delete, for example `aws-load-balancer-operator`.
 <5> Specify a version range of the images to delete for the Operator, for example `0.0.1` for the minimum version and `0.0.2` for the maximum version.
-To delete only one version's images, use that version number for both the `minVersion` and `maxVersion` fields.
-<6> Specify additional images to delete, for example `registry.redhat.io/ubi9/ubi-init:latest`.
 
 . Create a `delete-images.yaml` file by running the following command:
 +
@@ -62,6 +59,11 @@ where:
 
 <previously_mirrored_work_folder>:: Specifies the directory where images were previously mirrored to or stored during the mirroring process.
 <remote_registry>:: Specifies the URL or address of the remote container registry from which images will be deleted.
++
+[IMPORTANT]
+====
+When deleting images, specify the correct workspace directory. Modify or delete the cache directory only when starting mirroring from scratch, such as setting up a new cluster. Incorrect changes to the cache directory might disrupt further mirroring operations.
+====
 
 . Go to the `<previously_mirrored_work_folder>/delete` directory that was created.
 
diff --git a/modules/oc-mirror-proxy-support.adoc b/modules/oc-mirror-proxy-support.adoc
new file mode 100644
index 000000000000..fb9e4b5f7f25
--- /dev/null
+++ b/modules/oc-mirror-proxy-support.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * installing/disconnected_install/installing-mirroring-disconnected-v2.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="oc-mirror-proxy-support_{context}"]
+= oc-mirror plugin v2 support proxy setting
+
+The oc-mirror plugin v2 can operate in a proxy-configured environment. The plugin can use system proxy settings to retrieve images for {product-title}, Operator catalog, and the `additionalImages` registry.
\ No newline at end of file
diff --git a/modules/oc-mirror-troubleshooting-v2.adoc b/modules/oc-mirror-troubleshooting-v2.adoc
index bd9a3c6a126b..f07cf44e983b 100644
--- a/modules/oc-mirror-troubleshooting-v2.adoc
+++ b/modules/oc-mirror-troubleshooting-v2.adoc
@@ -12,7 +12,7 @@ oc-mirror plugin v2 now logs all image mirroring errors in a separate file, maki
 ====
 When errors occur while mirroring release or release component images, they are critical. This stops the mirroring process immediately.
 
-Errors with mirroring Operators, Operator-related images, or additional images do not stop the mirroring process. Mirroring continues, and oc-mirror plugin v2 logs updates every 8 images.
+Errors with mirroring Operators, Operator-related images, or additional images do not stop the mirroring process. Mirroring continues, and oc-mirror plugin v2 saves a file under the `working-dir/logs` directory describing which Operator failed to mirror.
 ====
 
 When an image fails to mirror, and that image is mirrored as part of one or more Operator bundles, oc-mirror plugin v2 notifies the user which Operators are incomplete, providing clarity on the Operator bundles affected by the error.
diff --git a/modules/oc-mirror-updating-cluster-manifests-v2.adoc b/modules/oc-mirror-updating-cluster-manifests-v2.adoc
index 2a15b181aa9a..89f4a2886b5b 100644
--- a/modules/oc-mirror-updating-cluster-manifests-v2.adoc
+++ b/modules/oc-mirror-updating-cluster-manifests-v2.adoc
@@ -29,6 +29,20 @@ In oc-mirror plugin v2, the IDMS and ITMS files cover the entire image set, unli
 $ oc apply -f <path_to_oc_mirror_workspace>/working-dir/cluster-resources
 ----
 
+. If you mirrored release images, apply the release image signatures to the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f working-dir/cluster-resources/signature-configmap.json 
+----
++
+[IMPORTANT]
+====
+If you are mirroring Operators instead of clusters, do not run the preceding command. Running the command results in an error because there are no release image signatures to apply.
+
+Additionally, a YAML file is available in the same directory `working-dir/cluster-resources/`. You can use either the JSON or YAML format.
+====
+
 .Verification
 
 . Verify that the `ImageDigestMirrorSet` resources are successfully installed by running the following command:
@@ -51,3 +65,10 @@ $ oc get imagetagmirrorset
 ----
 $ oc get catalogsource -n openshift-marketplace
 ----
+
+. Verify that the `ClusterCatalog` resources are successfully installed by running the following command:
++
+[source,terminal]
+----
+$ oc get clustercatalog
+----
\ No newline at end of file
diff --git a/modules/oc-mirror-updating-cluster-manifests.adoc b/modules/oc-mirror-updating-cluster-manifests.adoc
index 56b673f2d8aa..e4ecbf72c9ce 100644
--- a/modules/oc-mirror-updating-cluster-manifests.adoc
+++ b/modules/oc-mirror-updating-cluster-manifests.adoc
@@ -1,7 +1,6 @@
 // Module included in the following assemblies:
 //
-// * installing/disconnected_install/installing-mirroring-disconnected.adoc
-// * updating/updating_a_cluster/updating_disconnected_cluster/mirroring-image-repository.adoc
+// * disconnected/mirroring/installing-mirroring-disconnected.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="oc-mirror-updating-cluster-manifests_{context}"]
@@ -9,7 +8,14 @@
 
 After you have mirrored your image set to the mirror registry, you must apply the generated `ImageContentSourcePolicy`, `CatalogSource`, and release image signature resources into the cluster.
 
-The `ImageContentSourcePolicy` resource associates the mirror registry with the source registry and redirects image pull requests from the online registries to the mirror registry. The `CatalogSource` resource is used by Operator Lifecycle Manager (OLM) to retrieve information about the available Operators in the mirror registry. The release image signatures are used to verify the mirrored release images.
+The `ImageContentSourcePolicy` resource associates the mirror registry with the source registry and redirects image pull requests from the online registries to the mirror registry. The `CatalogSource` resource is used by {olmv0-first} to retrieve information about the available Operators in the mirror registry. The release image signatures are used to verify the mirrored release images.
+
+[NOTE]
+====
+{olmv1} uses the `ClusterCatalog` resource to retrieve information about the available cluster extensions in the mirror registry.
+
+The oc-mirror plugin v1 does not generate `ClusterCatalog` resources automatically; you must manually create them. For more information on creating and applying `ClusterCatalog` resources, see "Adding a catalog to a cluster" in "Extensions".
+====
 
 .Prerequisites
 
@@ -18,7 +24,7 @@ The `ImageContentSourcePolicy` resource associates the mirror registry with the
 
 .Procedure
 
-. Log in to the OpenShift CLI as a user with the `cluster-admin` role.
+. Log in to {oc-first} as a user with the `cluster-admin` role.
 
 . Apply the YAML files from the results directory to the cluster by running the following command:
 +
diff --git a/modules/oc-mirror-updating-restricted-cluster-manifests.adoc b/modules/oc-mirror-updating-restricted-cluster-manifests.adoc
index 434aa2d57a8b..12ab8e9d7054 100644
--- a/modules/oc-mirror-updating-restricted-cluster-manifests.adoc
+++ b/modules/oc-mirror-updating-restricted-cluster-manifests.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * installing/installing-restricted-networks-nutanix-installer-provisioned.adoc
+// * installing/installing_nutanix/installing-restricted-networks-nutanix-installer-provisioned.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="oc-mirror-updating-cluster-manifests_{context}"]
@@ -9,7 +9,16 @@
 Mirroring the {product-title} content using the oc-mirror OpenShift CLI (oc) plugin creates resources, which include `catalogSource-certified-operator-index.yaml` and `imageContentSourcePolicy.yaml`.
 
 * The `ImageContentSourcePolicy` resource associates the mirror registry with the source registry and redirects image pull requests from the online registries to the mirror registry.
-* The `CatalogSource` resource is used by Operator Lifecycle Manager (OLM) to retrieve information about the available Operators in the mirror registry, which lets users discover and install Operators.
+* The `CatalogSource` resource is used by {olmv0-first} to retrieve information about the available Operators in the mirror registry, which lets users discover and install Operators.
++
+[NOTE]
+====
+{olmv1} uses the `ClusterCatalog` resource to retrieve information about the available cluster extensions in the mirror registry.
+
+The oc-mirror plugin v1 does not generate `ClusterCatalog` resources automatically; you must manually create them. The oc-mirror plugin v2 does, however, generate `ClusterCatalog` resources automatically.
+
+For more information on creating and applying `ClusterCatalog` resources, see "Adding a catalog to a cluster" in "Extensions".
+====
 
 After you install the cluster, you must install these resources into the cluster.
 
diff --git a/modules/oc-mirror-v2-about.adoc b/modules/oc-mirror-v2-about.adoc
index e133d38b6dfb..de2c382c6892 100644
--- a/modules/oc-mirror-v2-about.adoc
+++ b/modules/oc-mirror-v2-about.adoc
@@ -9,10 +9,13 @@
 
 The oc-mirror OpenShift CLI (`oc`) plugin is a single tool that mirrors all required {product-title} content and other images to your mirror registry.
 
-To use the new Technology Preview version of oc-mirror, add the `--v2` flag to the oc-mirror plugin v2 command line.
+To use the new version of oc-mirror, add the `--v2` flag to the oc-mirror plugin v2 command line.
 
 oc-mirror plugin v2 has the following features:
 
+* Provides a centralized method to mirror {product-title} releases, Operators, helm charts, and other images.
+
+
 * Verifies that the complete image set specified in the image set configuration file is mirrored to the mirrored registry, regardless of whether the images were previously mirrored or not.
 
 * Uses a cache system instead of metadata, which prevents the need to start the mirroring process over in the case of a failure for a single step of the process.
@@ -24,9 +27,6 @@ oc-mirror plugin v2 has the following features:
 
 * Can generate `ImageDigestMirrorSet` (IDMS) and `ImageTagMirrorSet` (ITMS) resources, which cover the full image set, instead of an `ImageContentSourcePolicy` (ICSP) resource, which only covered incremental changes to the image set for each mirroring operation with v1.
 
-* Saves Operator versions that are filtered by bundle name.
-// Can anyone elaborate what this means? I am mostly confused with what the word "filter" means here.
-
 * Does not perform automatic pruning. v2 now uses a `Delete` feature, which grants users more control over deleting images.
 
 * Introduces support for `registries.conf` files. This change facilitates mirroring to multiple enclaves while using the same cache.
diff --git a/modules/oc-mirror-v2-procedure-garbage-collector.adoc b/modules/oc-mirror-v2-procedure-garbage-collector.adoc
new file mode 100644
index 000000000000..34fc273d5153
--- /dev/null
+++ b/modules/oc-mirror-v2-procedure-garbage-collector.adoc
@@ -0,0 +1,53 @@
+// Module included in the following assemblies:
+//
+// * disconnected/mirroring/about-installing-oc-mirror-v2.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="oc-mirror-v2-procedure-garbage-collector_{context}"]
+= Resolving storage cleanup issues in the distribution registry
+
+A known issue in the distribution registry prevents the garbage collector from freeing up storage as expected. This issue does not occur when you use {quay}.
+
+.Procedure
+
+* Choose the appropriate method to work around the known issue in the distribution registry:
+
+** To restart the container registry, run the following command:
++
+[source,terminal]
+----
+$ podman restart <registry_container>
+----
+
+** To disable caching in the registry configuration, perform the following steps: 
+
+... To disable the `blobdescriptor` cache, modify the `/etc/docker/registry/config.yml` file:
++
+[source,yaml]
+----
+version: 0.1
+log:
+  fields:
+    service: registry
+storage:
+  cache:
+    blobdescriptor: ""
+  filesystem:
+    rootdirectory: /var/lib/registry
+http:
+  addr: :5000
+  headers:
+    X-Content-Type-Options: [nosniff]
+health:
+  storagedriver:
+    enabled: true
+    interval: 10s
+    threshold: 3
+----
+
+... To apply the changes, restart the container registry by running the following command:
++
+[source,terminal]
+----
+$ podman restart <registry_container>
+----
diff --git a/modules/oc-mirror-workflows-delete-v2.adoc b/modules/oc-mirror-workflows-delete-v2.adoc
index 8329a7c7a189..7d1ddeac89d8 100644
--- a/modules/oc-mirror-workflows-delete-v2.adoc
+++ b/modules/oc-mirror-workflows-delete-v2.adoc
@@ -17,7 +17,6 @@ You must create a `DeleteImageSetConfiguration` file to specify which images to
 In the following example, the `DeleteImageSetConfiguration` file removes the following images:
 
 * All release images for {product-title} 4.13.3.
-* The `redhat-operator-index` `v4.12` catalog image.
 * The `aws-load-balancer-operator` v0.0.1 bundle and all its related images.
 * The additional images for `ubi` and `ubi-minimal`, referenced by their corresponding digests.
 
@@ -47,16 +46,25 @@ delete:
 
 [IMPORTANT]
 ====
-Consider using the mirror-to-disk and disk-to-mirror workflows to reduce mirroring issues.
+Consider using the mirror-to-disk and disk-to-mirror workflows to reduce deletion issues.
 ====
 
 oc-mirror plugin v2 deletes only the manifests of the images, which does not reduce the storage occupied in the registry.
 
-To free up storage space from unnecessary images, such as those with deleted manifests, you must enable the garbage collector on your container registry. With the garbage collector enabled, the registry will delete the image blobs that no longer have references to any manifests, reducing the storage previously occupied by the deleted blobs. The process for enabling the garbage collector differs depending on your container registry.
+To free up storage space from unnecessary images, such as those with deleted manifests, you must enable the garbage collector on your container registry. With the garbage collector enabled, the registry will delete the image blobs that no longer have references to any manifests, reducing the storage previously occupied by the deleted blobs. The process for enabling the garbage collector differs depending on your container registry. 
+
+For more information, see "Resolving storage cleanup issues in the distribution registry".
+
 
 [IMPORTANT]
 ====
-To skip deleting the Operator catalog image while you are deleting Operator images, you must list the specific Operators under the Operator catalog image in the `DeleteImageSetConfiguration` file. This ensures that only the specified Operators are deleted, not the catalog image.
-
+* To skip deleting the Operator catalog image while you are deleting Operator images, you must list the specific Operators under the Operator catalog image in the `DeleteImageSetConfiguration` file. This ensures that only the specified Operators are deleted, not the catalog image.
++
 If only the Operator catalog image is specified, all Operators within that catalog, as well as the catalog image itself, will be deleted.
-====
\ No newline at end of file
+
+* oc-mirror plugin v2 does not delete Operator catalog images automatically because other Operators may still be deployed and depend on these images.
++
+If you are certain that no Operators from a catalog remain in the registry or cluster, you can explicitly add the catalog image to `additionalImages` in `DeleteImageSetConfiguration` to remove it.
+
+* Garbage collection behavior depends on the registry. Some registries do not automatically remove deleted images, requiring a system administrator to manually trigger garbage collection to free up space.
+====
diff --git a/modules/odc-accessing-perspectives.adoc b/modules/odc-accessing-perspectives.adoc
index 4475396dee9d..088cbe257268 100644
--- a/modules/odc-accessing-perspectives.adoc
+++ b/modules/odc-accessing-perspectives.adoc
@@ -13,7 +13,7 @@ You can access the *Administrator* and *Developer* perspective from the web cons
 To access a perspective, ensure that you have logged in to the web console. Your default perspective is automatically determined by the permission of the users. The *Administrator* perspective is selected for users with access to all projects, while the *Developer* perspective is selected for users with limited access to their own projects
 
 .Additional resources
-See link:https://docs.openshift.com/container-platform/4.17/web_console/adding-user-preferences.html[Adding User Preferences] for more information on changing perspectives.
+See link:https://docs.openshift.com/container-platform/4.18/web_console/adding-user-preferences.html[Adding User Preferences] for more information on changing perspectives.
 
 
 .Procedure
diff --git a/modules/olm-catalogsource-image-template.adoc b/modules/olm-catalogsource-image-template.adoc
index 6872197f392e..02fd7436ca9a 100644
--- a/modules/olm-catalogsource-image-template.adoc
+++ b/modules/olm-catalogsource-image-template.adoc
@@ -14,11 +14,11 @@ endif::[]
 
 Operator compatibility with the underlying cluster can be expressed by a catalog source in various ways. One way, which is used for the default Red Hat-provided catalog sources, is to identify image tags for index images that are specifically created for a particular platform release, for example {product-title} {product-version}.
 
-During a cluster upgrade, the index image tag for the default Red Hat-provided catalog sources are updated automatically by the Cluster Version Operator (CVO) so that Operator Lifecycle Manager (OLM) pulls the updated version of the catalog. For example during an upgrade from {product-title} 4.17 to 4.18, the `spec.image` field in the `CatalogSource` object for the `redhat-operators` catalog is updated from:
+During a cluster upgrade, the index image tag for the default Red Hat-provided catalog sources are updated automatically by the Cluster Version Operator (CVO) so that Operator Lifecycle Manager (OLM) pulls the updated version of the catalog. For example during an upgrade from {product-title} {ocp-nminus1} to {product-version}, the `spec.image` field in the `CatalogSource` object for the `redhat-operators` catalog is updated from:
 
 [source,terminal]
 ----
-registry.redhat.io/redhat/redhat-operator-index:v4.17
+registry.redhat.io/redhat/redhat-operator-index:v4.18
 ----
 
 to:
diff --git a/modules/olm-channel-schema.adoc b/modules/olm-channel-schema.adoc
index ec3cb1a95ea7..cf571901f933 100644
--- a/modules/olm-channel-schema.adoc
+++ b/modules/olm-channel-schema.adoc
@@ -5,7 +5,7 @@
 [id="olm-channel-schema_{context}"]
 = olm.channel schema
 
-The `olm.channel` schema defines a channel within a package, the bundle entries that are members of the channel, and the upgrade edges for those bundles.
+The `olm.channel` schema defines a channel within a package, the bundle entries that are members of the channel, and the upgrade paths for those bundles.
 
 If a bundle entry represents an edge in multiple `olm.channel` blobs, it can only appear once per channel.
 
diff --git a/modules/olm-cs-status-cli.adoc b/modules/olm-cs-status-cli.adoc
index 8b2bf0e730dd..3425ed28ac39 100644
--- a/modules/olm-cs-status-cli.adoc
+++ b/modules/olm-cs-status-cli.adoc
@@ -18,12 +18,12 @@ You can view the status of an Operator catalog source by using the CLI.
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc b/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc
index fdc0b89b0ae8..1af151c9c935 100644
--- a/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc
+++ b/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc
@@ -17,9 +17,9 @@ Cluster administrators can delete installed Operators from a selected namespace
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 `cluster-admin` permissions.
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 `dedicated-admin` permissions.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/olm-fb-catalogs-guidelines.adoc b/modules/olm-fb-catalogs-guidelines.adoc
index 5823abb32bd6..466fd0a496a7 100644
--- a/modules/olm-fb-catalogs-guidelines.adoc
+++ b/modules/olm-fb-catalogs-guidelines.adoc
@@ -12,12 +12,12 @@ Consider the following guidelines when maintaining file-based catalogs.
 
 The general advice with Operator Lifecycle Manager (OLM) is that bundle images and their metadata should be treated as immutable.
 
-If a broken bundle has been pushed to a catalog, you must assume that at least one of your users has upgraded to that bundle. Based on that assumption, you must release another bundle with an upgrade edge from the broken bundle to ensure users with the broken bundle installed receive an upgrade. OLM will not reinstall an installed bundle if the contents of that bundle are updated in the catalog.
+If a broken bundle has been pushed to a catalog, you must assume that at least one of your users has upgraded to that bundle. Based on that assumption, you must release another bundle with an upgrade path from the broken bundle to ensure users with the broken bundle installed receive an upgrade. OLM will not reinstall an installed bundle if the contents of that bundle are updated in the catalog.
 
 However, there are some cases where a change in the catalog metadata is preferred:
 
 * Channel promotion: If you already released a bundle and later decide that you would like to add it to another channel, you can add an entry for your bundle in another `olm.channel` blob.
-* New upgrade edges: If you release a new `1.2.z` bundle version, for example `1.2.4`, but `1.3.0` is already released, you can update the catalog metadata for `1.3.0` to skip `1.2.4`.
+* New upgrade paths: If you release a new `1.2.z` bundle version, for example `1.2.4`, but `1.3.0` is already released, you can update the catalog metadata for `1.3.0` to skip `1.2.4`.
 
 [id="olm-fb-catalogs-source-control_{context}"]
 == Source control
diff --git a/modules/olm-fb-catalogs.adoc b/modules/olm-fb-catalogs.adoc
index 67d3e5764d18..54f6ed04b8b1 100644
--- a/modules/olm-fb-catalogs.adoc
+++ b/modules/olm-fb-catalogs.adoc
@@ -16,7 +16,7 @@ This editability enables the following features and user-defined extensions:
 --
 * Promoting an existing bundle to a new channel
 * Changing the default channel of a package
-* Custom algorithms for adding, updating, and removing upgrade edges
+* Custom algorithms for adding, updating, and removing upgrade paths
 --
 
 Composability::
@@ -34,6 +34,6 @@ Because Operator authors are most familiar with their Operator, its dependencies
 Extensibility::
 The file-based catalog specification is a low-level representation of a catalog. While it can be maintained directly in its low-level form, catalog maintainers can build interesting extensions on top that can be used by their own custom tooling to make any number of mutations.
 +
-For example, a tool could translate a high-level API, such as `(mode=semver)`, down to the low-level, file-based catalog format for upgrade edges. Or a catalog maintainer might need to customize all of the bundle metadata by adding a new property to bundles that meet a certain criteria.
+For example, a tool could translate a high-level API, such as `(mode=semver)`, down to the low-level, file-based catalog format for upgrade paths. Or a catalog maintainer might need to customize all of the bundle metadata by adding a new property to bundles that meet a certain criteria.
 +
 While this extensibility allows for additional official tooling to be developed on top of the low-level APIs for future {product-title} releases, the major benefit is that catalog maintainers have this capability as well.
diff --git a/modules/olm-filtering-fbc.adoc b/modules/olm-filtering-fbc.adoc
index 558e74e83b13..e137567b443c 100644
--- a/modules/olm-filtering-fbc.adoc
+++ b/modules/olm-filtering-fbc.adoc
@@ -6,7 +6,7 @@ ifdef::openshift-origin[]
 :registry-image: quay.io/operator-framework/opm:latest
 endif::[]
 ifndef::openshift-origin[]
-:registry-image: registry.redhat.io/openshift4/ose-operator-registry:v{product-version}
+:registry-image: registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version}
 endif::[]
 
 :_mod-docs-content-type: PROCEDURE
diff --git a/modules/olm-installing-operators-from-operatorhub-configure.adoc b/modules/olm-installing-operators-from-operatorhub-configure.adoc
index b2e4d554a71c..c53590c74ccd 100644
--- a/modules/olm-installing-operators-from-operatorhub-configure.adoc
+++ b/modules/olm-installing-operators-from-operatorhub-configure.adoc
@@ -1,88 +1,19 @@
 // Module included in the following assemblies:
 //
-// * operators/user/olm-installing-operators-in-namespace.adoc
-// * operators/admin/olm-adding-operators-to-cluster.adoc
 // * post_installation_configuration/preparing-for-users.adoc
 //
 // Module watched for changes by Ecosystem Catalog team:
 // https://projects.engineering.redhat.com/projects/RHEC/summary
 
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="olm-installing-operators-from-operatorhub-configure_{context}"]
-= Configuring {product-title} to use Red Hat Operators
+= About Operator Catalogs in {product-title}
 
-In {product-title}, Red Hat Operators are not available by default. You can access and install these Operators if you have a pull secret from {cluster-manager-first} by editing the `OperatorHub` custom resource (CR).
+Out of the box {product-title} provides a catalog source for community operators.
+These operators are built and distributed by the community.
+There are ongoing efforts to make more operators available through a community operator catalog.
 
-.Prerequisites
+Please note that the Red Hat Operators catalog is not available in {product-title}. According to the subscription agreement, these operators can be used only on OpenShift Container Platform clusters.
 
-* Ensure that you have downloaded the {cluster-manager-url-pull} as shown in the installation procedure.
-
-.Procedure
-
-To access the Red Hat Operators in an {product-title} cluster:
-
-. Edit the `OperatorHub` CR using the web console or CLI:
-
-.. Using the CLI:
-
-... Edit the `OperatorHub` CR:
-+
-[source,terminal]
-----
-$ oc edit OperatorHub cluster
-----
-
-... Add `redhat-operators` to the list of sources as `disabled: false`:
-+
-.Example `OperatorHub` CR
-[source,yaml]
-----
-apiVersion: config.openshift.io/v1
-kind: OperatorHub
-metadata:
-  name: cluster
-spec:
-  disableAllDefaultSources: true
-  sources:
-  - disabled: false <1>
-    name: redhat-operators
-  - disabled: false
-    name: community-operators
-----
-<1> Add the `name: redhat-operators` and `disabled: false` parameters.
-
-.. Using the web console:
-
-... Switch to the *Administration* -> *Custom Resource Definitions* page.
-
-... On the *Custom Resource Definitions* page, click *OperatorHub*.
-
-... On the *Custom Resource Definition Overview* page, click *Instances*.
-
-... On the *Instances* tab, click *cluster*.
-
-... On the *Instances* tab, click *YAML*.
-
-... In the YAML field, add `redhat-operators` to the list of sources as `disabled: false`:
-+
-.Example `OperatorHub` CR
-[source,yaml]
-----
-apiVersion: config.openshift.io/v1
-kind: OperatorHub
-metadata:
-  name: cluster
-spec:
-  disableAllDefaultSources: true
-  sources:
-  - disabled: false <1>
-    name: redhat-operators
-  - disabled: false
-    name: community-operators
-----
-<1> Add the `name: redhat-operators` and `disabled: false` parameters.
-
-... Click *Save*.
-
-. Log out of the web console, and then log back in.
+// In the future we may add a reference to OKDerators here.
diff --git a/modules/olm-migrating-sqlite-catalog-to-fbc.adoc b/modules/olm-migrating-sqlite-catalog-to-fbc.adoc
index ed1317e58e2d..82d3750aacf4 100644
--- a/modules/olm-migrating-sqlite-catalog-to-fbc.adoc
+++ b/modules/olm-migrating-sqlite-catalog-to-fbc.adoc
@@ -34,7 +34,7 @@ $ opm migrate <registry_image> <fbc_directory>
 ----
 $ opm generate dockerfile <fbc_directory> \
   --binary-image \
-  registry.redhat.io/openshift4/ose-operator-registry:v{product-version}
+  registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version}
 ----
 
 .Next steps
diff --git a/modules/olm-operatorgroups-provided-apis-annotations.adoc b/modules/olm-operatorgroups-provided-apis-annotations.adoc
index eb3ec36b6295..1863215bf27a 100644
--- a/modules/olm-operatorgroups-provided-apis-annotations.adoc
+++ b/modules/olm-operatorgroups-provided-apis-annotations.adoc
@@ -21,7 +21,7 @@ metadata:
   ...
 spec:
   selector: {}
-  serviceAccount:
+  serviceAccountName:
     metadata:
       creationTimestamp: null
   targetNamespaces:
diff --git a/modules/olm-operatorgroups-rbac.adoc b/modules/olm-operatorgroups-rbac.adoc
index 2f5c1ecaac22..ff1acf6e5c34 100644
--- a/modules/olm-operatorgroups-rbac.adoc
+++ b/modules/olm-operatorgroups-rbac.adoc
@@ -5,7 +5,7 @@
 [id="olm-operatorgroups-rbac_{context}"]
 = Role-based access control
 
-When an Operator group is created, three cluster roles are generated. Each contains a single aggregation rule with a cluster role selector set to match a label, as shown below:
+When an Operator group is created, three cluster roles are generated. When the cluster roles are generated, they are automatically suffixed with a hash value to ensure that each cluster role is unique. Each Operator group contains a single aggregation rule with a cluster role selector set to match a label, as shown in the following table:
 
 [cols="1,1",options="header"]
 |===
@@ -21,6 +21,18 @@ When an Operator group is created, three cluster roles are generated. Each conta
 |`olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>`
 |===
 
+[NOTE]
+====
+To use the cluster role of an Operator group to assign role-based access control (RBAC) to a resource, get the full name of cluster role and hash value by running the following command:
+
+[source,terminal]
+----
+$ oc get clusterroles | grep <operatorgroup_name>
+----
+
+Because the hash value is generated when the Operator group is created, you must create the Operator group before you can look up the complete name of the cluster role.
+====
+
 The following RBAC resources are generated when a CSV becomes an active member of an Operator group, as long as the CSV is watching all namespaces with the `AllNamespaces` install mode and is not in a failed state with reason `InterOperatorGroupOwnerConflict`:
 
 * Cluster roles for each API resource from a CRD
diff --git a/modules/olm-overview.adoc b/modules/olm-overview.adoc
index a1e302a91f65..189f3ab0858d 100644
--- a/modules/olm-overview.adoc
+++ b/modules/olm-overview.adoc
@@ -11,28 +11,31 @@ ifeval::["{context}" == "cluster-capabilities"]
 :cluster-caps:
 endif::[]
 
-
 :_mod-docs-content-type: CONCEPT
 [id="olm-overview_{context}"]
 ifndef::operators[]
 ifndef::cluster-caps[]
-= What is Operator Lifecycle Manager?
+= What is {olmv0-first}?
 endif::[]
 endif::[]
 ifdef::operators[]
 = Purpose
 endif::[]
 ifdef::cluster-caps[]
-= Operator Lifecycle Manager capability
+= {olmv0-first} capability
 
 [discrete]
 == Purpose
 endif::[]
 
-_Operator Lifecycle Manager_ (OLM) helps users install, update, and manage the lifecycle of Kubernetes native applications (Operators) and their associated services running across their {product-title} clusters. It is part of the link:https://operatorframework.io/[Operator Framework], an open source toolkit designed to manage Operators in an effective, automated, and scalable way.
+ifdef::cluster-caps[]
+{olmv0} provides the features for the `OperatorLifecycleManager` capability.
+endif::[]
+
+{olmv0-first} helps users install, update, and manage the lifecycle of Kubernetes native applications (Operators) and their associated services running across their {product-title} clusters. It is part of the link:https://operatorframework.io/[Operator Framework], an open source toolkit designed to manage Operators in an effective, automated, and scalable way.
 
 ifndef::cluster-caps[]
-.Operator Lifecycle Manager workflow
+.{olmv0} workflow
 image::olm-workflow.png[]
 
 OLM runs by default in {product-title} {product-version}, which aids
diff --git a/modules/olm-pruning-index-image.adoc b/modules/olm-pruning-index-image.adoc
index 93701ebb5b34..cd20e57ee627 100644
--- a/modules/olm-pruning-index-image.adoc
+++ b/modules/olm-pruning-index-image.adoc
@@ -7,7 +7,7 @@ ifdef::openshift-origin[]
 :catalog-name: catalog
 :index-image-pullspec: quay.io/operatorhubio/catalog:latest
 :index-image: catalog:latest
-:registry-image: quay.io/openshift/origin-operator-registry:4.9.0
+:registry-image: quay.io/openshift/origin-operator-registry:{product-version}
 :package1: couchdb-operator
 :package2: eclipse-che
 :package3: etcd
@@ -16,7 +16,7 @@ ifndef::openshift-origin[]
 :catalog-name: redhat-operators
 :index-image-pullspec: registry.redhat.io/redhat/redhat-operator-index:v{product-version}
 :index-image: redhat-operator-index:v{product-version}
-:registry-image: registry.redhat.io/openshift4/ose-operator-registry:v4.9
+:registry-image: registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version}
 :package1: advanced-cluster-management
 :package2: jaeger-product
 :package3: quay-operator
diff --git a/modules/olm-status-viewing-cli.adoc b/modules/olm-status-viewing-cli.adoc
index dff8103a3c8f..791bbaad3d78 100644
--- a/modules/olm-status-viewing-cli.adoc
+++ b/modules/olm-status-viewing-cli.adoc
@@ -11,12 +11,12 @@ You can view Operator subscription status by using the CLI.
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc b/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc
index 405410fe3904..989510853c34 100644
--- a/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc
+++ b/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc
@@ -26,7 +26,7 @@ endif::openshift-dedicated,openshift-rosa[]
 [source,terminal,subs="attributes+"]
 ----
 $ opm index add --binary-image \
-  registry.redhat.io/openshift4/ose-operator-registry:v{product-version} \
+  registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version} \
   --from-index <your_registry_image> \
   --bundles "" -t \<your_registry_image>
 ----
diff --git a/modules/olm-why-use-operators.adoc b/modules/olm-why-use-operators.adoc
index 2f472688bb69..05ec6ae053ab 100644
--- a/modules/olm-why-use-operators.adoc
+++ b/modules/olm-why-use-operators.adoc
@@ -15,7 +15,7 @@ Operators provide:
 --
 
 Why deploy on Kubernetes?::
-Kubernetes (and by extension, {product-title}) contains all of the primitives needed to build complex distributed systems – secret handling, load balancing, service discovery, autoscaling – that work across on-premises and cloud providers.
+Kubernetes (and by extension, {product-title}) contains all of the primitives needed to build complex distributed systems – secret handling, load balancing, service discovery, autoscaling – that work across on-premise and cloud providers.
 
 Why manage your app with Kubernetes APIs and `kubectl` tooling?::
 These APIs are feature rich, have clients for all platforms and plug into the cluster's access control/auditing. An Operator uses the Kubernetes extension mechanism, custom resource definitions (CRDs), so your custom object, link:https://marketplace.redhat.com/en-us/products/mongodb-enterprise-advanced-from-ibm[for example `MongoDB`], looks and acts just like the built-in, native Kubernetes objects.
diff --git a/modules/olmv1-about-catalogs.adoc b/modules/olmv1-about-catalogs.adoc
index 9805c2fc5aa4..fdf9d6aef9df 100644
--- a/modules/olmv1-about-catalogs.adoc
+++ b/modules/olmv1-about-catalogs.adoc
@@ -10,5 +10,3 @@
 = About catalogs in {olmv1}
 
 You can discover installable content by querying a catalog for Kubernetes extensions, such as Operators and controllers, by using the catalogd component. Catalogd is a Kubernetes extension that unpacks catalog content for on-cluster clients and is part of the {olmv1-first} suite of microservices. Currently, catalogd unpacks catalog content that is packaged and distributed as container images.
-
-include::snippets/olmv1-multi-catalog-admon.adoc[]
diff --git a/modules/olmv1-about-disconnected.adoc b/modules/olmv1-about-disconnected.adoc
new file mode 100644
index 000000000000..918c01db2ed6
--- /dev/null
+++ b/modules/olmv1-about-disconnected.adoc
@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+//
+// * extensions/catalogs/disconnected-catalogs.adoc
+
+:_mod-docs-content-type: CONCEPT
+
+[id="olmv1-about-disconnected_{context}"]
+= About disconnected support and the oc-mirror plugin in {olmv1}
+
+{olmv1-first} supports disconnected environments starting in {product-title} 4.18. After using the oc-mirror plugin for the {oc-first} to mirror the images required for your cluster to a mirror registry in your fully or partially disconnected environments, {olmv1} can function properly in these environments by utilizing either of the following sets of resources, depending on which oc-mirror plugin version you are using:
+
+* `ImageContentSourcePolicy` resources, which are automatically generated by oc-mirror plugin v1, and `ClusterCatalog` resources, which must be manually created after using oc-mirror plugin v1
+* `ImageDigestMirrorSet`, `ImageTagMirrorSet`, and `ClusterCatalog` resources, which are all automatically generated by oc-mirror plugin v2
+
+[NOTE]
+====
+Starting in {product-title} 4.18, oc-mirror plugin v2 is the recommended version for mirroring.
+====
+
+For more information and procedures, see the _Disconnected environments_ guide for the oc-mirror plugin version you plan to use.
\ No newline at end of file
diff --git a/modules/olmv1-about-target-versions.adoc b/modules/olmv1-about-target-versions.adoc
index 83d51b14e1f0..aaf4bf5b5c0f 100644
--- a/modules/olmv1-about-target-versions.adoc
+++ b/modules/olmv1-about-target-versions.adoc
@@ -22,18 +22,22 @@ If you specify a channel in the CR, {olmv1} installs the latest version of the O
 .Example CR with a specified channel
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: ClusterExtension
-metadata:
-  name: pipelines-operator
-spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace_name>
-  serviceAccount:
-    name: <service_account>
-  channel: latest <1>
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace>
+    serviceAccount:
+      name: <service_account_installer_name>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        channels:
+          - latest <1>
 ----
-<1> Installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed.
+<1> Optional: Installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed. Specify the value of the `channels` parameter as an array.
 
 If you specify the Operator or extension's target version in the CR, {olmv1} installs the specified version. When the target version is specified in the CR, {olmv1} does not change the target version when updates are published to the catalog.
 
@@ -42,36 +46,42 @@ If you want to update the version of the Operator that is installed on the clust
 .Example CR with the target version specified
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: ClusterExtension
-metadata:
-  name: pipelines-operator
-spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace_name>
-  serviceAccount:
-    name: <service_account>
-  version: "1.11.1" <1>
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace>
+    serviceAccount:
+      name: <service_account_installer_name>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        version: "1.11.1" <1>
 ----
-<1> Specifies the target version. If you want to update the version of the Operator or extension that is installed, you must manually update this field the CR to the desired target version.
+<1> Optional: Specifies the target version. If you want to update the version of the Operator or extension that is installed, you must manually update this field the CR to the desired target version.
 
 If you want to define a range of acceptable versions for an Operator or extension, you can specify a version range by using a comparison string. When you specify a version range, {olmv1} installs the latest version of an Operator or extension that can be resolved by the Operator Controller.
 
 .Example CR with a version range specified
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: ClusterExtension
-metadata:
-  name: pipelines-operator
-spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace_name>
-  serviceAccount:
-    name: <service_account>
-  version: ">1.11.1" <1>
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace>
+    serviceAccount:
+      name: <service_account_installer_name>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        version: ">1.11.1" <1>
 ----
-<1> Specifies that the desired version range is greater than version `1.11.1`. For more information, see "Support for version ranges".
+<1> Optional: Specifies that the desired version range is greater than version `1.11.1`. For more information, see "Support for version ranges".
 
 After you create or update a CR, apply the configuration file by running the following command:
 
diff --git a/modules/olmv1-adding-a-catalog.adoc b/modules/olmv1-adding-a-catalog.adoc
index 50e1153a25f6..cc7814ccb1f6 100644
--- a/modules/olmv1-adding-a-catalog.adoc
+++ b/modules/olmv1-adding-a-catalog.adoc
@@ -1,48 +1,49 @@
 // Module included in the following assemblies:
 //
-// * operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc
+// * extensions/catalogs/managing-catalogs.adoc
 
 :_mod-docs-content-type: PROCEDURE
 
 [id="olmv1-adding-a-catalog-to-a-cluster_{context}"]
 = Adding a catalog to a cluster
 
-To add a catalog to a cluster, create a catalog custom resource (CR) and apply it to the cluster.
+To add a catalog to a cluster for {olmv1-first} usage, create a `ClusterCatalog` custom resource (CR) and apply it to the cluster.
 
 .Procedure
 
 . Create a catalog custom resource (CR), similar to the following example:
 +
-.Example `redhat-operators.yaml`
+.Example `my-redhat-operators.yaml` file
 [source,yaml,subs="attributes+"]
 ----
-apiVersion: catalogd.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterCatalog
 metadata:
-  name: redhat-operators
+  name: my-redhat-operators <1>
 spec:
+  priority: 1000 <2>
   source:
-    type: image
     image:
-      ref: registry.redhat.io/redhat/redhat-operator-index:v{product-version} <1>
-      pullSecret: <pull_secret_name> <2>
-      pollInterval: <poll_interval_duration> <3>
+      pollIntervalMinutes: 10 <3>
+      ref: registry.redhat.io/redhat/community-operator-index:v{product-version} <4>
+    type: Image
 ----
-<1> Specify the catalog's image in the `spec.source.image` field.
-<2> If your catalog is hosted on a secure registry, such as `registry.redhat.io`, you must create a pull secret scoped to the `openshift-catalog` namespace.
-<3> Specify the interval for polling the remote registry for newer image digests. The default value is `24h`. Valid units include seconds (`s`), minutes (`m`), and hours (`h`). To disable polling, set a zero value, such as `0s`.
+<1> The catalog is automatically labeled with the value of the `metadata.name` field when it is applied to the cluster. For more information about labels and catalog selection, see "Catalog content resolution".
+<2> Optional: Specify the priority of the catalog in relation to the other catalogs on the cluster. For more information, see "Catalog selection by priority".
+<3> Specify the interval in minutes for polling the remote registry for newer image digests. To disable polling, do not set the field.
+<4> Specify the catalog image in the `spec.source.image.ref` field.
 
 . Add the catalog to your cluster by running the following command:
 +
 [source,terminal]
 ----
-$ oc apply -f redhat-operators.yaml
+$ oc apply -f my-redhat-operators.yaml
 ----
 +
 .Example output
 [source,text]
 ----
-catalog.catalogd.operatorframework.io/redhat-operators created
+clustercatalog.olm.operatorframework.io/my-redhat-operators created
 ----
 
 .Verification
@@ -59,58 +60,68 @@ $ oc get clustercatalog
 .Example output
 [source,text]
 ----
-NAME                  AGE
-redhat-operators      20s
+NAME                            LASTUNPACKED   SERVING   AGE
+my-redhat-operators             55s            True      64s
+openshift-certified-operators   83m            True      84m
+openshift-community-operators   43m            True      84m
+openshift-redhat-marketplace    83m            True      84m
+openshift-redhat-operators      54m            True      84m
 ----
 
 .. Check the status of your catalog by running the following command:
 +
 [source,terminal]
 ----
-$ oc describe clustercatalog
+$ oc describe clustercatalog my-redhat-operators
 ----
 +
 .Example output
 [source,text,subs="attributes+"]
 ----
-Name:         redhat-operators
+Name:         my-redhat-operators
 Namespace:
-Labels:       <none>
+Labels:       olm.operatorframework.io/metadata.name=my-redhat-operators
 Annotations:  <none>
-API Version:  catalogd.operatorframework.io/v1alpha1
+API Version:  olm.operatorframework.io/v1
 Kind:         ClusterCatalog
 Metadata:
-  Creation Timestamp:  2024-06-10T17:34:53Z
+  Creation Timestamp:  2025-02-18T20:28:50Z
   Finalizers:
-    catalogd.operatorframework.io/delete-server-cache
+    olm.operatorframework.io/delete-server-cache
   Generation:        1
-  Resource Version:  46075
-  UID:               83c0db3c-a553-41da-b279-9b3cddaa117d
+  Resource Version:  50248
+  UID:               86adf94f-d2a8-4e70-895b-31139f2eeab7
 Spec:
+  Availability Mode:  Available
+  Priority:           1000
   Source:
     Image:
-      Pull Secret:  redhat-cred
-      Ref:          registry.redhat.io/redhat/redhat-operator-index:v4.17
-    Type:           image
+      Poll Interval Minutes:  10
+      Ref:                    registry.redhat.io/redhat/community-operator-index:v{product-version}
+    Type:                     Image
 Status: <1>
   Conditions:
-    Last Transition Time:  2024-06-10T17:35:15Z
-    Message:
-    Reason:                UnpackSuccessful <2>
+    Last Transition Time:  2025-02-18T20:29:00Z
+    Message:               Successfully unpacked and stored content from resolved source
+    Observed Generation:   1
+    Reason:                Succeeded <2>
     Status:                True
-    Type:                  Unpacked
-  Content URL:             https://catalogd-catalogserver.openshift-catalogd.svc/catalogs/redhat-operators/all.json
-  Observed Generation:     1
-  Phase:                   Unpacked <3>
+    Type:                  Progressing
+    Last Transition Time:  2025-02-18T20:29:00Z
+    Message:               Serving desired content from resolved source
+    Observed Generation:   1
+    Reason:                Available
+    Status:                True
+    Type:                  Serving
+  Last Unpacked:           2025-02-18T20:28:59Z
   Resolved Source:
     Image:
-      Last Poll Attempt:  2024-06-10T17:35:10Z
-      Ref:                registry.redhat.io/redhat/redhat-operator-index:v4.17
-      Resolved Ref:       registry.redhat.io/redhat/redhat-operator-index@sha256:f2ccc079b5e490a50db532d1dc38fd659322594dcf3e653d650ead0e862029d9 <4>
-    Type:                 image
-Events:                   <none>
+      Ref:  registry.redhat.io/redhat/community-operator-index@sha256:11627ea6fdd06b8092df815076e03cae9b7cede8b353c0b461328842d02896c5 <3>
+    Type:   Image
+  Urls:
+    Base:  https://catalogd-service.openshift-catalogd.svc/catalogs/my-redhat-operators
+Events:    <none>
 ----
 <1> Describes the status of the catalog.
 <2> Displays the reason the catalog is in the current state.
-<3> Displays the phase of the installation process.
-<4> Displays the image reference of the catalog.
+<3> Displays the image reference of the catalog.
diff --git a/modules/olmv1-blocked-cluster-updates.adoc b/modules/olmv1-blocked-cluster-updates.adoc
new file mode 100644
index 000000000000..cdc667a6523d
--- /dev/null
+++ b/modules/olmv1-blocked-cluster-updates.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/update-paths.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="olmv1-blocked-cluster-updates_{context}"]
+= Cluster updates blocked by olm cluster Operator
+
+If an installed Operator's `olm.maxOpenShiftVersion` field is set and a cluster administrator attempts to update their cluster to a version that the Operator does not provide a valid update path for, the cluster update fails and the `Upgradeable` status for the `olm` cluster Operator is set to `False`.
+
+To resolve the issue, the cluster administrator must either update the installed Operator to a version with a valid update path, if one is available, or they must uninstall the Operator. Then, they can attempt the cluster update again.
\ No newline at end of file
diff --git a/modules/olmv1-catalog-exclusion-by-labels-or-expressions.adoc b/modules/olmv1-catalog-exclusion-by-labels-or-expressions.adoc
new file mode 100644
index 000000000000..f2c88a93cc1c
--- /dev/null
+++ b/modules/olmv1-catalog-exclusion-by-labels-or-expressions.adoc
@@ -0,0 +1,91 @@
+// Module included in the following assemblies:
+// * extensions/catalogs/catalog-content-resolution.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-catalog-exclusion-by-labels-or-expressions_{context}"]
+= Catalog exclusion by labels or expressions
+
+You can exclude catalogs by using match expressions on metadata with the `NotIn` or `DoesNotExist` operators.
+
+The following CRs add an `example.com/testing` label to the `unwanted-catalog-1` and `unwanted-catalog-2` cluster catalogs:
+
+.Example cluster catalog CR
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: unwanted-catalog-1
+  labels:
+    example.com/testing: "true"
+spec:
+  source:
+    type: Image
+    image:
+      ref: quay.io/example/content-management-a:latest
+----
+
+.Example cluster catalog CR
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: unwanted-catalog-2
+  labels:
+    example.com/testing: "true"
+spec:
+  source:
+    type: Image
+    image:
+      ref: quay.io/example/content-management-b:latest
+----
+
+The following cluster extension CR excludes selection from the `unwanted-catalog-1` catalog:
+
+.Example cluster extension CR that excludes a specific catalog
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+spec:
+  namespace: <example_namespace>
+  serviceAccount:
+    name: <example_extension>-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <example_extension>-operator
+      selector:
+        matchExpressions:
+          - key: olm.operatorframework.io/metadata.name
+            operator: NotIn
+            values:
+              - unwanted-catalog-1
+----
+
+The following cluster extension CR selects from catalogs that do not have the `example.com/testing` label. As a result, both `unwanted-catalog-1` and `unwanted-catalog-2` are excluded from catalog selection.
+
+.Example cluster extension CR that excludes catalogs with a specific label
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+spec:
+  namespace: <example_namespace>
+  serviceAccount:
+    name: <example_extension>-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <example_extension>-operator
+      selector:
+        matchExpressions:
+          - key: example.com/testing
+            operator: DoesNotExist
+----
diff --git a/modules/olmv1-catalog-queries.adoc b/modules/olmv1-catalog-queries.adoc
index 8c62edb7b159..aa6d40ff1162 100644
--- a/modules/olmv1-catalog-queries.adoc
+++ b/modules/olmv1-catalog-queries.adoc
@@ -47,7 +47,7 @@ a|
 [source,terminal]
 ----
 $ opm render <catalog_registry_url>:<tag> \
-  \| jq -s '.[] \| select( .schema == "olm.package")
+  \| jq -s '.[] \| select( .schema == "olm.package")'
 ----
 
 |Packages that support `AllNamespaces` install mode and do not use webhooks
diff --git a/modules/olmv1-catalog-selection-by-labels-or-expressions.adoc b/modules/olmv1-catalog-selection-by-labels-or-expressions.adoc
new file mode 100644
index 000000000000..7717ce958a7f
--- /dev/null
+++ b/modules/olmv1-catalog-selection-by-labels-or-expressions.adoc
@@ -0,0 +1,80 @@
+// Module included in the following assemblies:
+// * extensions/catalogs/olmv1-catalog-content-resolution.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-catalog-selection-by-labels-or-exp_{context}"]
+= Catalog selection by labels or expressions
+
+You can add metadata to a catalog by using labels in the custom resource (CR) of a cluster catalog. You can then filter catalog selection by specifying the assigned labels or using expressions in the CR of the cluster extension.
+
+The following cluster catalog CR adds the `example.com/support` label with the value of `true` to the `catalog-a` cluster catalog:
+
+.Example cluster catalog CR with labels
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: catalog-a
+  labels:
+    example.com/support: "true"
+spec:
+  source:
+    type: Image
+    image:
+      ref: quay.io/example/content-management-a:latest
+----
+
+The following cluster extension CR uses the `matchLabels` selector to select catalogs with the `example.com/support` label and the value of `true`:
+
+.Example cluster extension CR with `matchLabels` selector
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+spec:
+  namespace: <example_namespace>
+  serviceAccount:
+    name: <example_extension>-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <example_extension>-operator
+      selector:
+        matchLabels:
+          example.com/support: "true"
+----
+
+You can use the `matchExpressions` field to perform more complex filtering for labels. The following cluster extension CR selects catalogs with the `example.com/support` label and a value of `production` or `supported`:
+
+.Example cluster extension CR with `matchExpression` selector
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+spec:
+  namespace: <example_namespace>
+  serviceAccount:
+    name: <example_extension>-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <example_extension>-operator
+      selector:
+        matchExpressions:
+          - key: example.com/support
+            operator: In
+            values:
+              - "production"
+              - "supported"
+----
+
+[NOTE]
+====
+If you use both the `matchLabels` and `matchExpressions` fields, the selected catalog must satisfy all specified criteria.
+====
diff --git a/modules/olmv1-catalog-selection-by-name.adoc b/modules/olmv1-catalog-selection-by-name.adoc
new file mode 100644
index 000000000000..b3ecfe7e6f06
--- /dev/null
+++ b/modules/olmv1-catalog-selection-by-name.adoc
@@ -0,0 +1,44 @@
+// Module included in the following assemblies:
+// * extensions/catalogs/olmv1-catalog-content-resolution.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-catalog-selection-by-name_{context}"]
+= Catalog selection by name
+
+When a catalog is added to a cluster, a label is created by using the value of the `metadata.name` field of the catalog custom resource (CR). In the CR of an extension, you can specify the catalog name by using the `spec.source.catalog.selector.matchLabels` field. The value of the `matchLabels` field uses the following format:
+
+.Example label derived from the `metadata.name` field
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+  labels:
+    olm.operatorframework.io/metadata.name: <example_extension> <1>
+...
+----
+<1> A label derived from the `metadata.name` field and automatically added when the catalog is applied.
+
+The following example resolves the `<example_extension>-operator` package from a catalog with the `openshift-redhat-operators` label:
+
+.Example extension CR
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterExtension
+metadata:
+  name: <example_extension>
+spec:
+  namespace: <example_namespace>
+  serviceAccount:
+    name: <example_extension>-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <example_extension>-operator
+      selector:
+        matchLabels:
+          olm.operatorframework.io/metadata.name: openshift-redhat-operators
+----
diff --git a/modules/olmv1-catalog-selection-by-priority.adoc b/modules/olmv1-catalog-selection-by-priority.adoc
new file mode 100644
index 000000000000..b0e4ae42f480
--- /dev/null
+++ b/modules/olmv1-catalog-selection-by-priority.adoc
@@ -0,0 +1,46 @@
+// Module included in the following assemblies:
+// * extensions/catalogs/olmv1-catalog-content-resolution.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-catalog-exclusion-by-priority_{context}"]
+= Catalog selection by priority
+
+When multiple catalogs provide the same package, you can resolve ambiguities by specifying the priority in the custom resource (CR) of each catalog. If unspecified, catalogs have a default priority value of `0`. The priority can be any positive or negative 32-bit integer.
+
+[NOTE]
+====
+* During bundle resolution, catalogs with higher priority values are selected over catalogs with lower priority values.
+* Bundles that are not deprecated are prioritized over bundles that are deprecated.
+* If multiple bundles exist in catalogs with the same priority and the catalog selection is ambiguous, an error is printed.
+====
+
+.Example cluster catalog CR with a higher priority
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: high-priority-catalog
+spec:
+  priority: 1000
+  source:
+    type: Image
+    image:
+      ref: quay.io/example/higher-priority-catalog:latest
+----
+
+.Example cluster catalog CR with a lower priority
+[source,yaml]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: lower-priority-catalog
+spec:
+  priority: 10
+  source:
+    type: Image
+    image:
+      ref: quay.io/example/lower-priority-catalog:latest
+----
diff --git a/modules/olmv1-cluster-extension-permissions.adoc b/modules/olmv1-cluster-extension-permissions.adoc
new file mode 100644
index 000000000000..60e655779e02
--- /dev/null
+++ b/modules/olmv1-cluster-extension-permissions.adoc
@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: CONCEPT
+
+[id="olmv1-cluster-extension-permissions_{context}"]
+= Cluster extension permissions
+
+In {olmv0-first}, a single service account with cluster administrator privileges manages all cluster extensions.
+
+{olmv1} is designed to be more secure than {olmv0} by default. {olmv1} manages a cluster extension by using the service account specified in an extension's custom resource (CR). Cluster administrators can create a service account for each cluster extension. As a result, administrators can follow the principle of least privilege and assign only the role-based access controls (RBAC) to install and manage that extension.
+
+You must add each permission to either a cluster role or role. Then you must bind the cluster role or role to the service account with a cluster role binding or role binding.
+
+You can scope the RBAC to either the cluster or to a namespace. Use cluster roles and cluster role bindings to scope permissions to the cluster. Use roles and role bindings to scope permissions to a namespace. Whether you scope the permissions to the cluster or to a namespace depends on the design of the extension you want to install and manage.
+
+include::snippets/olmv1-manual-rbac-scoping-admonition.adoc[]
+
+If a new version of an installed extension requires additional permissions, {olmv1} halts the update process until a cluster administrator grants those permissions.
diff --git a/modules/olmv1-clusterextension-api.adoc b/modules/olmv1-clusterextension-api.adoc
index 528d47470ce3..435985cf0e8a 100644
--- a/modules/olmv1-clusterextension-api.adoc
+++ b/modules/olmv1-clusterextension-api.adoc
@@ -20,13 +20,19 @@ For more information about the earlier behavior, see _Multitenancy and Operator
 .Example `ClusterExtension` object
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
-  name: <operator_name>
+  name: <extension_name>
 spec:
-  packageName: <package_name>
-  installNamespace: <namespace_name>
-  channel: <channel_name>
-  version: <version_number>
+  namespace: <namespace_name>
+  serviceAccount:
+    name: <service_account_name>
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: <package_name>
+      channels:
+        - <channel>
+      version: "<version>"
 ----
diff --git a/modules/olmv1-clusteroperator.adoc b/modules/olmv1-clusteroperator.adoc
index 9af4737d9b21..35d1c516bd49 100644
--- a/modules/olmv1-clusteroperator.adoc
+++ b/modules/olmv1-clusteroperator.adoc
@@ -1,15 +1,33 @@
 // Module included in the following assemblies:
 //
 // * operators/operator-reference.adoc
+// * installing/overview/cluster-capabilities.adoc
+
+ifeval::["{context}" == "cluster-operators-ref"]
+:operators:
+endif::[]
+ifeval::["{context}" == "cluster-capabilities"]
+:cluster-caps:
+endif::[]
 
 :_mod-docs-content-type: CONCEPT
+
 [id="cluster-operators-ref-olmv1_{context}"]
+ifdef::operators[]
 = {olmv1-first} Operator
+endif::[]
+ifdef::cluster-caps[]
+= {olmv1-first} capability
+endif::[]
 
 [discrete]
 == Purpose
 
-Starting in {product-title} 4.18, {olmv1-first} is enabled by default alongside the {olmv0}. This next-generation iteration provides an updated framework that evolves many of the {olmv0} concepts that enable cluster administrators to extend capabilities for their users.
+ifdef::cluster-caps[]
+{olmv1} provides the features for the `OperatorLifecycleManagerV1` capability.
+endif::[]
+
+Starting in {product-title} 4.18, {olmv1} is enabled by default alongside {olmv0}. This next-generation iteration provides an updated framework that evolves many of {olmv0} concepts that enable cluster administrators to extend capabilities for their users.
 
 {olmv1} manages the lifecycle of the new `ClusterExtension` object, which includes Operators via the `registry+v1` bundle format, and controls installation, upgrade, and role-based access control (RBAC) of extensions within a cluster.
 
@@ -44,4 +62,4 @@ Catalogd:: A Kubernetes extension that unpacks file-based catalog (FBC) content
 == Project
 
 * link:https://github.com/operator-framework/operator-controller[operator-framework/operator-controller]
-* link:https://github.com/operator-framework/catalogd[operator-framework/catalogd]
\ No newline at end of file
+* link:https://github.com/operator-framework/catalogd[operator-framework/catalogd]
diff --git a/modules/olmv1-creating-a-cluster-role-binding.adoc b/modules/olmv1-creating-a-cluster-role-binding.adoc
new file mode 100644
index 000000000000..be359b6b762b
--- /dev/null
+++ b/modules/olmv1-creating-a-cluster-role-binding.adoc
@@ -0,0 +1,65 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-creating-a-cluster-rol-binding_{context}"]
+= Creating a cluster role binding for an extension
+
+After you have created a service account and cluster role, you must bind the cluster role to the service account with a cluster role binding manifest.
+
+.Prerequisites
+
+* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
+* You have created and applied the following resources for the extension you want to install:
+** Namespace
+** Service account
+** Cluster role
+
+.Procedure
+
+. Create a cluster role binding to bind the cluster role to the service account, similar to the following example:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: <extension>-installer-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: <extension>-installer-clusterrole
+subjects:
+- kind: ServiceAccount
+  name: <extension>-installer
+  namespace: <namespace>
+----
++
+.Example `pipelines-cluster-role-binding.yaml` file
+[%collapsible]
+====
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: pipelines-installer-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: pipelines-installer-clusterrole
+subjects:
+- kind: ServiceAccount
+  name: pipelines-installer
+  namespace: pipelines
+----
+====
+
+. Apply the cluster role binding by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f pipelines-cluster-role-binding.yaml
+----
diff --git a/modules/olmv1-creating-a-cluster-role.adoc b/modules/olmv1-creating-a-cluster-role.adoc
new file mode 100644
index 000000000000..de0c403d1e82
--- /dev/null
+++ b/modules/olmv1-creating-a-cluster-role.adoc
@@ -0,0 +1,346 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-creating-a-cluster-role_{context}"]
+= Creating a cluster role for an extension
+
+You must review the `install.spec.clusterpermissions` stanza of the cluster service version (CSV) and the manifests of an extension carefully to define the required role-based access controls (RBAC) of the extension that you want to install. You must create a cluster role by copying the required RBAC from the CSV to the new manifest.
+
+[TIP]
+====
+If you want to test the process for installing and updating an extension in {olmv1}, you can use the following cluster role to grant cluster administrator permissions. This manifest is for testing purposes only. It should not be used in production clusters.
+
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: <extension>-installer-clusterrole
+rules:
+- apiGroups: ["*"]
+  resources: ["*"]
+  verbs: ["*"]
+----
+====
+
+The following procedure uses the `openshift-pipelines-operator-rh.clusterserviceversion.yaml` file of the {pipelines-title} Operator as an example. The examples include excerpts of the RBAC required to install and manage the {pipelines-shortname} Operator. For a complete manifest, see "Example cluster role for the {pipelines-title} Operator".
+
+include::snippets/olmv1-manual-rbac-scoping-admonition.adoc[]
+
+.Prerequisites
+
+* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
+* You have downloaded the manifests in the image reference of the extension that you want to install.
+
+.Procedure
+
+. Create a new cluster role manifest, similar to the following example:
++
+.Example `<extension>-cluster-role.yaml` file
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: <extension>-installer-clusterrole
+----
+
+. Edit your cluster role manifest to include permission to update finalizers on the extension, similar to the following example:
++
+.Example <extension>-cluster-role.yaml
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+- apiGroups:
+  - olm.operatorframework.io
+  resources:
+  - clusterextensions/finalizers
+  verbs:
+  - update
+  # Scoped to the name of the ClusterExtension
+  resourceNames:
+  - <metadata_name> # <1>
+----
+<1> Specifies the value from the `metadata.name` field from the custom resource (CR) of the extension.
+
+. Search for the `clusterrole` and `clusterrolebindings` values in the `rules.resources` field in the extension's CSV file.
+
+** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
++
+.Example cluster role manifest
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+# ...
+# ClusterRoles and ClusterRoleBindings for the controllers of the extension
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterroles
+  verbs:
+  - create # <1>
+  - list
+  - watch
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterroles
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames: # <2>
+  - "*"
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterrolebindings
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterrolebindings
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames:
+  - "*"
+# ...
+----
+<1> You cannot scope `create`, `list`, and `watch` permissions to specific resource names (the `resourceNames` field). You must scope these permissions to their resources (the `resources` field).
+<2> Some resource names are generated by using the following format: `<package_name>.<hash>`. After you install the extension, look up the resource names for the cluster roles and cluster role bindings for the controller of the extension. Replace the wildcard characters in this example with the generated names and follow the principle of least privilege.
+
+. Search for the `customresourcedefinitions` value in the `rules.resources` field in the extension's CSV file.
+
+** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+# ...
+# Custom resource definitions of the extension
+- apiGroups:
+  - apiextensions.k8s.io
+  resources:
+  - customresourcedefinitions
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - apiextensions.k8s.io
+  resources:
+  - customresourcedefinitions
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames:
+  - manualapprovalgates.operator.tekton.dev
+  - openshiftpipelinesascodes.operator.tekton.dev
+  - tektonaddons.operator.tekton.dev
+  - tektonchains.operator.tekton.dev
+  - tektonconfigs.operator.tekton.dev
+  - tektonhubs.operator.tekton.dev
+  - tektoninstallersets.operator.tekton.dev
+  - tektonpipelines.operator.tekton.dev
+  - tektonresults.operator.tekton.dev
+  - tektontriggers.operator.tekton.dev
+# ...
+----
+
+. Search the CSV file for stanzas with the `permissions` and `clusterPermissions` values in the `rules.resources` spec.
+
+** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+# ...
+# Excerpt from install.spec.clusterPermissions
+- apiGroups:
+  - ''
+  resources:
+  - nodes
+  - pods
+  - services
+  - endpoints
+  - persistentvolumeclaims
+  - events
+  - configmaps
+  - secrets
+  - pods/log
+  - limitranges
+  verbs:
+  - create
+  - list
+  - watch
+  - delete
+  - deletecollection
+  - patch
+  - get
+  - update
+- apiGroups:
+  - extensions
+  - apps
+  resources:
+  - ingresses
+  - ingresses/status
+  verbs:
+  - create
+  - list
+  - watch
+  - delete
+  - patch
+  - get
+  - update
+ # ...
+----
+
+. Search the CSV file for resources under the `install.spec.deployments` stanza.
+
+** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+# ...
+# Excerpt from install.spec.deployments
+- apiGroups:
+  - apps
+  resources:
+  - deployments
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - apps
+  resources:
+  - deployments
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  # scoped to the extension controller deployment name
+  resourceNames:
+  - openshift-pipelines-operator
+  - tekton-operator-webhook
+# ...
+----
+
+. Search for the `services` and `configmaps` values in the `rules.resources` field in the extension's CSV file.
+
+** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+# ...
+# Services
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - get
+  - list
+  - watch
+  - update
+  - patch
+  - delete
+  # scoped to the service name
+  resourceNames:
+  - openshift-pipelines-operator-monitor
+  - tekton-operator
+  - tekton-operator-webhook
+# configmaps
+- apiGroups:
+  - ""
+  resources:
+  - configmaps
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - configmaps
+  verbs:
+  - get
+  - list
+  - watch
+  - update
+  - patch
+  - delete
+  # scoped to the configmap name
+  resourceNames:
+  - config-logging
+  - tekton-config-defaults
+  - tekton-config-observability
+  - tekton-operator-controller-config-leader-election
+  - tekton-operator-info
+  - tekton-operator-webhook-config-leader-election
+- apiGroups:
+  - operator.tekton.dev
+  resources:
+  - tekton-config-read-role
+  - tekton-result-read-role
+  verbs:
+  - get
+  - watch
+  - list
+----
+
+. Add the cluster role manifest to the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f <extension>-installer-clusterrole.yaml
+----
++
+.Example command
+[source,terminal]
+----
+$ oc apply -f pipelines-installer-clusterrole.yaml
+----
diff --git a/modules/olmv1-creating-a-namespace.adoc b/modules/olmv1-creating-a-namespace.adoc
new file mode 100644
index 000000000000..cf79788ef5fc
--- /dev/null
+++ b/modules/olmv1-creating-a-namespace.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-creating-a-namespace_{context}"]
+= Creating a namespace
+
+Before you create a service account to install and manage your cluster extension, you must create a namespace.
+
+.Prerequisites
+
+* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
+
+.Procedure
+
+* Create a new namespace for the service account of the extension that you want to install by running the following command:
++
+[source,terminal]
+----
+$ oc adm new-project <new_namespace>
+----
diff --git a/modules/olmv1-creating-a-service-account.adoc b/modules/olmv1-creating-a-service-account.adoc
index dc48fb4a8b01..d8d3868b1fab 100644
--- a/modules/olmv1-creating-a-service-account.adoc
+++ b/modules/olmv1-creating-a-service-account.adoc
@@ -5,14 +5,9 @@
 :_mod-docs-content-type: PROCEDURE
 
 [id="olmv1-creating-a-service-account_{context}"]
-= Creating a service account to manage cluster extensions
+= Creating a service account for an extension
 
-Unlike {olmv0-first}, {olmv1} does not have permissions to install, update, and manage cluster extensions. Cluster administrators must create a service account and assign the role-based access controls (RBAC) required to install, update, and manage cluster extensions.
-
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-service-accounts.adoc[]
-====
+You must create a service account to install, manage, and update a cluster extension.
 
 .Prerequisites
 
@@ -50,89 +45,3 @@ metadata:
 ----
 $ oc apply -f extension-service-account.yaml
 ----
-. Create a cluster role and assign RBAC, similar to the following example:
-+
-[WARNING]
-====
-The following cluster role does not follow the principle of least privilege. This cluster role is intended for testing purposes only. Do not use it on production clusters.
-====
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: <extension>-installer-clusterrole
-rules:
-- apiGroups: ["*"]
-  resources: ["*"]
-  verbs: ["*"]
-----
-+
-.Example `pipelines-cluster-role.yaml` file
-[%collapsible]
-====
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: pipelines-installer-clusterrole
-rules:
-- apiGroups: ["*"]
-  resources: ["*"]
-  verbs: ["*"]
-----
-====
-
-. Add the cluster role to the cluster by running the following command:
-+
-[source,terminal]
-----
-$ oc apply -f pipelines-role.yaml
-----
-
-. Bind the permissions granted by the cluster role to the service account by creating a cluster role binding, similar to the following example:
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: <extension>-installer-binding
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: <extension>-installer-clusterrole
-subjects:
-- kind: ServiceAccount
-  name: <extension>-installer
-  namespace: <namespace>
-----
-+
-.Example `pipelines-cluster-role-binding.yaml` file
-[%collapsible]
-====
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: pipelines-installer-binding
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: pipelines-installer-clusterrole
-subjects:
-- kind: ServiceAccount
-  name: pipelines-installer
-  namespace: pipelines
-----
-====
-
-. Apply the cluster role binding by running the following command:
-+
-[source,terminal]
-----
-$ oc apply -f pipelines-cluster-role-binding.yaml
-----
diff --git a/modules/olmv1-creating-fbc.adoc b/modules/olmv1-creating-fbc.adoc
index e1478e6f919c..ed25bb0cc98d 100644
--- a/modules/olmv1-creating-fbc.adoc
+++ b/modules/olmv1-creating-fbc.adoc
@@ -6,7 +6,7 @@ ifdef::openshift-origin[]
 :registry-image: quay.io/operator-framework/opm:latest
 endif::[]
 ifndef::openshift-origin[]
-:registry-image: registry.redhat.io/openshift4/ose-operator-registry:v{product-version}
+:registry-image: registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version}
 endif::[]
 
 :_mod-docs-content-type: PROCEDURE
diff --git a/modules/olmv1-default-cluster-roles-users.adoc b/modules/olmv1-default-cluster-roles-users.adoc
new file mode 100644
index 000000000000..5f7229ec0791
--- /dev/null
+++ b/modules/olmv1-default-cluster-roles-users.adoc
@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/user-access-resources.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-default-cluster-roles-users_{context}"]
+= Common default cluster roles for users
+
+An installed cluster extension might include default cluster roles to determine role-based access control (RBAC) for regular users to API resources provided by the extension. A common set of cluster roles can resemble the following policies:
+
+`view` cluster role:: Grants read-only access to all custom resource (CR) objects of specified API resources across the cluster. Intended for regular users who require visibility into the resources without any permissions to modify them. Ideal for monitoring purposes and limited access viewing.
+`edit` cluster role:: Allows users to modify all CR objects within the cluster. Enables users to create, update, and delete resources, making it suitable for team members who must manage resources but should not control RBAC or manage permissions for others.
+`admin` cluster role:: Provides full permissions, including `create`, `update`, and `delete` verbs, over all custom resource objects for the specified API resources across the cluster.
\ No newline at end of file
diff --git a/modules/olmv1-deleting-catalog.adoc b/modules/olmv1-deleting-catalog.adoc
index e6ddc293179b..7656e776ca7f 100644
--- a/modules/olmv1-deleting-catalog.adoc
+++ b/modules/olmv1-deleting-catalog.adoc
@@ -25,7 +25,7 @@ $ oc delete clustercatalog <catalog_name>
 .Example output
 [source,text]
 ----
-catalog.catalogd.operatorframework.io "my-catalog" deleted
+clustercatalog.olm.operatorframework.io "my-redhat-operators" deleted
 ----
 
 .Verification
diff --git a/modules/olmv1-disabling-a-default-catalog.adoc b/modules/olmv1-disabling-a-default-catalog.adoc
new file mode 100644
index 000000000000..3764240ac8f3
--- /dev/null
+++ b/modules/olmv1-disabling-a-default-catalog.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// * operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-disabling-a-default-catalog_{context}"]
+= Disabling a default catalog
+
+You can disable the Red{nbsp}Hat-provided catalogs that are included with {product-title} by default.
+
+.Procedure
+
+* Disable a default catalog by running the following command:
++
+[source,terminal]
+----
+$ oc patch clustercatalog openshift-certified-operators -p \
+  '{"spec": {"availabilityMode": "Unavailable"}}' --type=merge
+----
++
+.Example output
+[source,text]
+----
+clustercatalog.olm.operatorframework.io/openshift-certified-operators patched
+----
+
+.Verification
+
+* Verify the catalog is disabled by running the following command:
++
+[source,terminal]
+----
+$ oc get clustercatalog openshift-certified-operators
+----
++
+.Example output
+[source,text]
+----
+NAME                            LASTUNPACKED   SERVING   AGE
+openshift-certified-operators                  False     6h54m
+----
diff --git a/modules/olmv1-downloading-bundle-manifests.adoc b/modules/olmv1-downloading-bundle-manifests.adoc
new file mode 100644
index 000000000000..1d35b4c687ab
--- /dev/null
+++ b/modules/olmv1-downloading-bundle-manifests.adoc
@@ -0,0 +1,151 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-downloading-bundle-manifests_{context}"]
+= Downloading the bundle manifests of an extension
+
+Use the `opm` CLI tool to download the bundle manifests of the extension that you want to install. Use the CLI tool or text editor of your choice to view the manifests and find the required permissions to install and manage the extension.
+
+.Prerequisites
+
+* You have access to an {product-title} cluster using an account with `cluster-admin` permissions.
+* You have decided which extension you want to install.
+* You have installed the `opm` CLI tool.
+
+.Procedure
+
+. Inspect the available versions and images of the extension you want to install by running the following command:
++
+[source,terminal]
+----
+$ opm render <registry_url>:<tag_or_version> | \
+  jq -cs '.[] | select( .schema == "olm.bundle" ) | \
+  select( .package == "<extension_name>") | \
+  {"name":.name, "image":.image}'
+----
++
+.Example command
+[%collapsible]
+====
+[source,terminal,subs="attributes"]
+----
+$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} | \
+  jq -cs '.[] | select( .schema == "olm.bundle" ) | \
+  select( .package == "openshift-pipelines-operator-rh") | \
+  {"name":.name, "image":.image}'
+----
+====
++
+.Example output
+[%collapsible]
+====
+[source,text]
+----
+{"name":"openshift-pipelines-operator-rh.v1.14.3","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:3f64b29f6903981470d0917b2557f49d84067bccdba0544bfe874ec4412f45b0"}
+{"name":"openshift-pipelines-operator-rh.v1.14.4","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"}
+{"name":"openshift-pipelines-operator-rh.v1.14.5","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838"}
+{"name":"openshift-pipelines-operator-rh.v1.15.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:22be152950501a933fe6e1df0e663c8056ca910a89dab3ea801c3bb2dc2bf1e6"}
+{"name":"openshift-pipelines-operator-rh.v1.15.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:64afb32e3640bb5968904b3d1a317e9dfb307970f6fda0243e2018417207fd75"}
+{"name":"openshift-pipelines-operator-rh.v1.15.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd"}
+{"name":"openshift-pipelines-operator-rh.v1.16.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:a46b7990c0ad07dae78f43334c9bd5e6cba7b50ca60d3f880099b71e77bed214"}
+{"name":"openshift-pipelines-operator-rh.v1.16.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:29f27245e93b3f605647993884751c490c4a44070d3857a878d2aee87d43f85b"}
+{"name":"openshift-pipelines-operator-rh.v1.16.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2037004666526c90329f4791f14cb6cc06e8775cb84ba107a24cc4c2cf944649"}
+{"name":"openshift-pipelines-operator-rh.v1.17.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:d75065e999826d38408049aa1fde674cd1e45e384bfdc96523f6bad58a0e0dbc"}
+----
+====
+
+. Make a directory to extract the image of the bundle that you want to install by running the following command:
++
+[source,terminal]
+----
+$ mkdir <new_dir>
+----
+
+. Change into the directory by running the following command:
++
+[source,terminal]
+----
+$ cd <new_dir>
+----
+
+. Find the image reference of the version that you want to install and run the following command:
++
+[source,terminal]
+----
+$ oc image extract <full_path_to_registry_image>@sha256:<sha>
+----
++
+.Example command
+[source,terminal]
+----
+$ oc image extract registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
+----
+
+. Change into the `manifests` directory by running the following command:
++
+[source,terminal]
+----
+$ cd manifests
+----
+
+. View the contents of the manifests directory by entering the following command. The output lists the manifests of the resources required to install, manage, and operate your extension.
++
+[source,terminal]
+----
+$ tree
+----
++
+.Example output
+[%collapsible]
+====
+[source,text]
+----
+.
+├── manifests
+│   ├── config-logging_v1_configmap.yaml
+│   ├── openshift-pipelines-operator-monitor_monitoring.coreos.com_v1_servicemonitor.yaml
+│   ├── openshift-pipelines-operator-prometheus-k8s-read-binding_rbac.authorization.k8s.io_v1_rolebinding.yaml
+│   ├── openshift-pipelines-operator-read_rbac.authorization.k8s.io_v1_role.yaml
+│   ├── openshift-pipelines-operator-rh.clusterserviceversion.yaml
+│   ├── operator.tekton.dev_manualapprovalgates.yaml
+│   ├── operator.tekton.dev_openshiftpipelinesascodes.yaml
+│   ├── operator.tekton.dev_tektonaddons.yaml
+│   ├── operator.tekton.dev_tektonchains.yaml
+│   ├── operator.tekton.dev_tektonconfigs.yaml
+│   ├── operator.tekton.dev_tektonhubs.yaml
+│   ├── operator.tekton.dev_tektoninstallersets.yaml
+│   ├── operator.tekton.dev_tektonpipelines.yaml
+│   ├── operator.tekton.dev_tektonresults.yaml
+│   ├── operator.tekton.dev_tektontriggers.yaml
+│   ├── tekton-config-defaults_v1_configmap.yaml
+│   ├── tekton-config-observability_v1_configmap.yaml
+│   ├── tekton-config-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
+│   ├── tekton-config-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
+│   ├── tekton-operator-controller-config-leader-election_v1_configmap.yaml
+│   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_rolebinding.yaml
+│   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_role.yaml
+│   ├── tekton-operator-info_v1_configmap.yaml
+│   ├── tekton-operator_v1_service.yaml
+│   ├── tekton-operator-webhook-certs_v1_secret.yaml
+│   ├── tekton-operator-webhook-config-leader-election_v1_configmap.yaml
+│   ├── tekton-operator-webhook_v1_service.yaml
+│   ├── tekton-result-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
+│   └── tekton-result-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
+├── metadata
+│   ├── annotations.yaml
+│   └── properties.yaml
+└── root
+    └── buildinfo
+        ├── content_manifests
+        │   └── openshift-pipelines-operator-bundle-container-v1.16.2-3.json
+        └── Dockerfile-openshift-pipelines-pipelines-operator-bundle-container-v1.16.2-3
+----
+====
+
+.Next steps
+
+* View the contents of the `install.spec.clusterpermissions` stanza of cluster service version (CSV) file in the `manifests` directory using your preferred CLI tool or text editor. The following examples reference the `openshift-pipelines-operator-rh.clusterserviceversion.yaml` file of the {pipelines-title} Operator.
+* Keep this file open as a reference while assigning permissions to the cluster role file in the following procedure.
diff --git a/modules/olmv1-example-pipelines-operator-cluster-role.adoc b/modules/olmv1-example-pipelines-operator-cluster-role.adoc
new file mode 100644
index 000000000000..24b83911da2d
--- /dev/null
+++ b/modules/olmv1-example-pipelines-operator-cluster-role.adoc
@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-example-cluster-role-pipelines_{context}"]
+= Example cluster role for the {pipelines-title} Operator
+
+See the following example for a complete cluster role manifest for the {pipelines-shortname} Operator.
+
+[source,yaml]
+----
+include::snippets/example-pipelines-installer-clusterrole.yaml[]
+----
diff --git a/modules/olmv1-finding-ce-resources.adoc b/modules/olmv1-finding-ce-resources.adoc
new file mode 100644
index 000000000000..fdcc46e4018e
--- /dev/null
+++ b/modules/olmv1-finding-ce-resources.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/user-access-resources.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-finding-ce-resources_{context}"]
+= Finding API groups and resources exposed by a cluster extension
+
+To create appropriate RBAC policies for granting user access to cluster extension resources, you must know which API groups and resources are exposed by the installed extension. As an administrator, you can inspect custom resource definitions (CRDs) installed on the cluster by using {oc-first}.
+
+.Prerequisites
+
+* A cluster extension has been installed on your cluster.
+
+.Procedure
+
+* To list installed CRDs while specifying a label selector targeting a specific cluster extension by name to find only CRDs owned by that extension, run the following command:
++
+[source,terminal]
+----
+$ oc get crds -l 'olm.operatorframework.io/owner-kind=ClusterExtension,olm.operatorframework.io/owner-name=<cluster_extension_name>'
+----
+
+* Alternatively, you can search through all installed CRDs and individually inspect them by CRD name:
+
+.. List all available custom resource definitions (CRDs) currently installed on the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get crds
+----
++
+Find the CRD you are looking for in the output.
+
+.. Inspect the individual CRD further to find its API groups by running the following command:
++
+[source,terminal]
+----
+$ oc get crd <crd_name> -o yaml
+----
+
diff --git a/modules/olmv1-forcing-an-update-or-rollback.adoc b/modules/olmv1-forcing-an-update-or-rollback.adoc
index 9f4343551455..0682ac058358 100644
--- a/modules/olmv1-forcing-an-update-or-rollback.adoc
+++ b/modules/olmv1-forcing-an-update-or-rollback.adoc
@@ -27,22 +27,28 @@ You must verify the consequences of forcing a manual update or rollback. Failure
 .Example CR
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: Operator
-metadata:
-  name: <operator_name> <1>
-spec:
-  packageName: <package_name> <2>
-  installNamespace: <namespace_name>
-  serviceAccount:
-    name: <service_account>
-  version: <version> <3>
-  upgradeConstraintPolicy: Ignore <4>
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace> <1>
+    serviceAccount:
+      name: <service_account_installer_name> <2>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        channels:
+          - <channel_name> <3>
+        version: <version_or_version_range> <4>
+        upgradeConstraintPolicy: SelfCertified <5>
 ----
-<1> Specifies the name of the Operator or extension, such as `pipelines-operator`
-<2> Specifies the package name, such as `openshift-pipelines-operator-rh`.
-<3> Specifies the blocked update or rollback version.
-<4> Optional: Specifies the upgrade constraint policy. To force an update or rollback, set the field to `Ignore`. If unspecified, the default setting is `Enforce`.
+<1> Specifies the namespace where you want the bundle installed, such as `pipelines` or `my-extension`. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.
+<2> Specifies the name of the service account you created to install, update, and manage your extension.
+<3> Optional: Specifies channel names as an array, such as `pipelines-1.14` or `latest`.
+<4> Optional: Specifies the version or version range, such as `1.14.0`, `1.14.x`, or `>=1.16`, of the package you want to install or update. For more information, see "Example custom resources (CRs) that specify a target version" and "Support for version ranges".
+<5> Optional: Specifies the upgrade constraint policy. To force an update or rollback, set the field to `SelfCertified`. If unspecified, the default setting is `CatalogProvided`. The `CatalogProvided` setting only updates if the new version satisfies the upgrade constraints set by the package author.
 
 . Apply the changes to your Operator or extensions CR by running the following command:
 +
diff --git a/modules/olmv1-granting-user-access-aggregated.adoc b/modules/olmv1-granting-user-access-aggregated.adoc
new file mode 100644
index 000000000000..5e44c0fd9cca
--- /dev/null
+++ b/modules/olmv1-granting-user-access-aggregated.adoc
@@ -0,0 +1,66 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/user-access-resources.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-granting-user-access-aggregated_{context}"]
+= Granting user access to extension resources by using aggregated cluster roles
+
+As a cluster administrator, you can configure role-based access control (RBAC) policies to grant user access to extension resources by using aggregated cluster roles.
+
+To automatically extend existing default cluster roles, you can add _aggregation labels_ by adding one or more of the following labels to a `ClusterRole` object:
+
+.Aggregation labels in a `ClusterRole` object
+[source,yaml]
+----
+# ..
+metadata:
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+# ..
+----
+
+This allows users who already have `view`, `edit`, or `admin` roles to interact with the  custom resource specified by the `ClusterRole` object without requiring additional role or cluster role bindings to specific users or groups.
+
+.Prerequisites
+
+* A cluster extension has been installed on your cluster.
+* You have a list of API groups and resource names, as described in "Finding API groups and resources exposed by a cluster extension".
+
+.Procedure
+
+. Create an object definition for a cluster role that specifies the API groups and resources provided by the cluster extension and add an aggregation label to extend one or more existing default cluster roles:
++
+.Example `ClusterRole` object with an aggregation label
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: view-custom-resource-aggregated
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+rules:
+  - apiGroups:
+      - <cluster_extension_api_group>
+    resources:
+      - <cluster_extension_custom_resource>
+    verbs:
+      - get
+      - list
+      - watch
+----
++
+You can create similar `ClusterRole` objects for `edit` and `admin` with appropriate verbs, such as `create`, `update`, and `delete`. By using aggregation labels, the permissions for the custom resources are added to the default roles.
+
+. Save your object definition to a YAML file.
+
+. Create the object by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/olmv1-granting-user-access-binding.adoc b/modules/olmv1-granting-user-access-binding.adoc
new file mode 100644
index 000000000000..2fb7cb789f13
--- /dev/null
+++ b/modules/olmv1-granting-user-access-binding.adoc
@@ -0,0 +1,155 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/user-access-resources.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="olmv1-granting-user-access-binding_{context}"]
+= Granting user access to extension resources by using custom role bindings
+
+As a cluster administrator, you can manually create and configure role-based access control (RBAC) policies to grant user access to extension resources by using custom role bindings.
+
+.Prerequisites
+
+* A cluster extension has been installed on your cluster.
+* You have a list of API groups and resource names, as described in "Finding API groups and resources exposed by a cluster extension".
+
+.Procedure
+
+. If the installed cluster extension does not provide default cluster roles, manually create one or more roles:
+
+.. Consider the use cases for the set of roles described in "Common default cluster roles for users".
++
+For example, create one or more of the following `ClusterRole` object definitions, replacing `<cluster_extension_api_group>` and `<cluster_extension_custom_resource>` with the actual API group and resource names provided by the installed cluster extension:
++
+.Example `view-custom-resource.yaml` file
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: view-custom-resource
+rules:
+- apiGroups:
+  - <cluster_extension_api_group>
+  resources:
+  - <cluster_extension_custom_resources>
+  verbs:
+  - get
+  - list
+  - watch
+----
++
+.Example `edit-custom-resource.yaml` file
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: edit-custom-resource
+rules:
+- apiGroups:
+  - <cluster_extension_api_group>
+  resources:
+  - <cluster_extension_custom_resources>
+  verbs:
+  - get
+  - list
+  - watch
+  - create
+  - update
+  - patch
+  - delete 
+----
++
+.Example `admin-custom-resource.yaml` file
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: admin-custom-resource
+rules:
+- apiGroups:
+  - <cluster_extension_api_group>
+  resources:
+  - <cluster_extension_custom_resources>
+  verbs:
+  - '*' <1>
+----
+<1> Setting a wildcard (`*`) in `verbs` allows all actions on the specified resources.
+
+.. Create the cluster roles by running the following command for any YAML files you created:
++
+[source,terminal]
+----
+$ oc create -f <filename>.yaml
+----
+
+. Associate a cluster role to specific users or groups to grant them the necessary permissions for the resource by binding the cluster roles to individual user or group names:
+
+.. Create an object definition for either a _cluster role binding_ to grant access across all namespaces or a _role binding_ to grant access within a specific namespace:
++
+--
+*** The following example cluster role bindings grant read-only `view` access to the custom resource across all namespaces:
++
+.Example `ClusterRoleBinding` object for a user
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: view-custom-resource-binding
+subjects:
+- kind: User
+  name: <user_name>
+roleRef:
+  kind: ClusterRole
+  name: view-custom-resource
+  apiGroup: rbac.authorization.k8s.io
+----
++
+.Example `ClusterRoleBinding` object for a user
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: view-custom-resource-binding
+subjects:
+- kind: Group
+  name: <group_name>
+roleRef:
+  kind: ClusterRole
+  name: view-custom-resource
+  apiGroup: rbac.authorization.k8s.io
+----
+ 
+*** The following role binding restricts `edit` permissions to a specific namespace:
++
+.Example `RoleBinding` object for a user
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: edit-custom-resource-edit-binding
+  namespace: <namespace>
+subjects:
+- kind: User
+  name: <username>
+roleRef:
+  kind: Role
+  name: custom-resource-edit
+  apiGroup: rbac.authorization.k8s.io
+----
+--
+
+.. Save your object definition to a YAML file.
+
+.. Create the object by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/olmv1-installing-an-operator.adoc b/modules/olmv1-installing-an-operator.adoc
index fae57b8e1d2d..ad15092b81c4 100644
--- a/modules/olmv1-installing-an-operator.adoc
+++ b/modules/olmv1-installing-an-operator.adoc
@@ -7,126 +7,59 @@
 [id="olmv1-installing-an-operator_{context}"]
 = Installing a cluster extension from a catalog
 
-You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. {olmv1-first} supports installing cluster extensions, including {olmv0} Operators via the `registry+v1` bundle format, that are scoped to the cluster. For more information, see _Supported extensions_.
+You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. {olmv1-first} supports installing cluster extensions, including {olmv0} Operators in the `registry+v1` bundle format, that are scoped to the cluster. For more information, see _Supported extensions_.
 
 .Prerequisites
 
-* You have installed the `jq` CLI tool.
-* You have installed the `opm` CLI tool.
-* You have created a service account and assigned enough role-based access controls (RBAC) to install, update, and manage the extension you want to install. For more information, see "Creating a service account to manage cluster extensions".
+* You have created a service account and assigned enough role-based access controls (RBAC) to install, update, and manage the extension that you want to install. For more information, see "Cluster extension permissions".
 
 .Procedure
 
-. Inspect a package for channel and version information from a local copy of your catalog file by completing the following steps:
-
-.. Get a list of channels from a selected package by running the following command:
-+
-[source,terminal]
-----
-$ opm render <catalog_registry_url>:<tag> \
-  | jq -s '.[] | select( .schema == "olm.channel" ) \
-  | select( .package == "<package_name>") \
-  | .name'
-----
-+
-.Example command
-[%collapsible]
-====
-[source,terminal,subs=attributes+]
-----
-$  opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
-   | jq -s '.[] | select( .schema == "olm.channel" ) \
-   | select( .package == "openshift-pipelines-operator-rh") \
-   | .name'
-----
-====
-+
-.Example output
-[%collapsible]
-====
-[source,text]
-----
-"latest"
-"pipelines-1.14"
-"pipelines-1.15"
-"pipelines-1.16"
-----
-====
-
-.. Get a list of the versions published in a channel by running the following command:
-+
-[source,terminal]
-----
-$  opm render <catalog_registry_url>:<tag> \
-   | jq -s '.[] | select( .package == "<package_name>" ) \
-   | select( .schema == "olm.channel" ) \
-   | select( .name == "<channel_name>" ) | .entries \
-   | .[] | .name'
-----
-+
-.Example command
-[%collapsible]
-====
-[source,terminal,subs=attributes+]
-----
-$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
-  | jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) \
-  | select( .schema == "olm.channel" ) | select( .name == "latest" ) \
-  | .entries | .[] | .name'
-----
-====
-+
-.Example output
-[%collapsible]
-====
-[source,text]
-----
-"openshift-pipelines-operator-rh.v1.14.3"
-"openshift-pipelines-operator-rh.v1.14.4"
-"openshift-pipelines-operator-rh.v1.14.5"
-"openshift-pipelines-operator-rh.v1.15.0"
-"openshift-pipelines-operator-rh.v1.15.1"
-"openshift-pipelines-operator-rh.v1.15.2"
-"openshift-pipelines-operator-rh.v1.16.0"
-"openshift-pipelines-operator-rh.v1.16.1"
-----
-====
-
-. If you want to install your extension into a new namespace, run the following command:
+. Create a CR, similar to the following example:
 +
-[source,terminal]
-----
-$ oc adm new-project <new_namespace>
+[source,yaml]
 ----
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace> <1>
+    serviceAccount:
+      name: <service_account_installer_name> <2>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        channels:
+          - <channel_name> <3>
+        version: <version_or_version_range> <4>
+        upgradeConstraintPolicy: CatalogProvided <5>
+----
+<1> Specifies the namespace where you want the bundle installed, such as `pipelines` or `my-extension`. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.
+<2> Specifies the name of the service account you created to install, update, and manage your extension.
+<3> Optional: Specifies channel names as an array, such as `pipelines-1.14` or `latest`.
+<4> Optional: Specifies the version or version range, such as `1.14.0`, `1.14.x`, or `>=1.16`, of the package you want to install or update. For more information, see "Example custom resources (CRs) that specify a target version" and "Support for version ranges".
+<5> Optional: Specifies the upgrade constraint policy. If unspecified, the default setting is `CatalogProvided`. The `CatalogProvided` setting only updates if the new version satisfies the upgrade constraints set by the package author. To force an update or rollback, set the field to `SelfCertified`. For more information, see "Forcing an update or rollback".
 
-. Create a CR, similar to the following example:
-+
 .Example `pipelines-operator.yaml` CR
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   name: pipelines-operator
 spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace>
+  namespace: pipelines
   serviceAccount:
-    name: <service_account>
-  channel: <channel>
-  version: "<version>"
+    name: pipelines-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      version: "1.14.x"
 ----
-+
-where:
-+
-`<namespace>`:: Specifies the namespace where you want the bundle installed, such as `pipelines` or `my-extension`. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.
-`<service_account>`:: Specifies the name of the service account you created to install, update, and manage your extension.
-`<channel>`:: Optional: Specifies the channel, such as `pipelines-1.11` or `latest`, for the package you want to install or update.
-`<version>`:: Optional: Specifies the version or version range, such as `1.11.1`, `1.12.x`, or `>=1.12.1`, of the package you want to install or update. For more information, see "Example custom resources (CRs) that specify a target version" and "Support for version ranges".
-+
---
-include::snippets/olmv1-multi-catalog-admon.adoc[]
---
+
 
 . Apply the CR to the cluster by running the following command:
 +
@@ -157,76 +90,76 @@ $ oc get clusterextension pipelines-operator -o yaml
 ----
 apiVersion: v1
 items:
-- apiVersion: olm.operatorframework.io/v1alpha1
+- apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     annotations:
       kubectl.kubernetes.io/last-applied-configuration: |
-        {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"pipelines","packageName":"openshift-pipelines-operator-rh","serviceAccount":{"name":"pipelines-installer"},"pollInterval":"30m"}}
-    creationTimestamp: "2024-06-10T17:50:51Z"
+        {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
+    creationTimestamp: "2025-02-18T21:48:13Z"
     finalizers:
     - olm.operatorframework.io/cleanup-unpack-cache
+    - olm.operatorframework.io/cleanup-contentmanager-cache
     generation: 1
     name: pipelines-operator
-    resourceVersion: "53324"
-    uid: c54237be-cde4-46d4-9b31-d0ec6acc19bf
+    resourceVersion: "72725"
+    uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
   spec:
-    channel: latest
-    installNamespace: pipelines
-    packageName: openshift-pipelines-operator-rh
+    namespace: pipelines
     serviceAccount:
       name: pipelines-installer
-    upgradeConstraintPolicy: Enforce
+    source:
+      catalog:
+        packageName: openshift-pipelines-operator-rh
+        upgradeConstraintPolicy: CatalogProvided
+        version: 1.14.x
+      sourceType: Catalog
   status:
     conditions:
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
-      message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
-      observedGeneration: 1
-      reason: Success
-      status: "True"
-      type: Resolved
-    - lastTransitionTime: "2024-06-10T17:51:11Z"
-      message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
-      observedGeneration: 1
-      reason: Success
-      status: "True"
-      type: Installed
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: Deprecated
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: PackageDeprecated
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: ChannelDeprecated
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: BundleDeprecated
-    - lastTransitionTime: "2024-06-10T17:50:58Z"
-      message: 'unpack successful:
+    - lastTransitionTime: "2025-02-18T21:48:16Z"
+      message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
+        successfully
       observedGeneration: 1
-      reason: UnpackSuccess
+      reason: Succeeded
       status: "True"
-      type: Unpacked
-    installedBundle:
-      name: openshift-pipelines-operator-rh.v1.14.4
-      version: 1.14.4
-    resolvedBundle:
-      name: openshift-pipelines-operator-rh.v1.14.4
-      version: 1.14.4
+      type: Installed
+    - lastTransitionTime: "2025-02-18T21:48:16Z"
+      message: desired state reached
+      observedGeneration: 1
+      reason: Succeeded
+      status: "True"
+      type: Progressing
+    install:
+      bundle:
+        name: openshift-pipelines-operator-rh.v1.14.5
+        version: 1.14.5
+kind: List
+metadata:
+  resourceVersion: ""
 ----
 where:
 
@@ -244,6 +177,4 @@ where:
 The value of `False` in the `status` field indicates that the `reason: Deprecated` condition is not deprecated. The value of `True` in the `status` field indicates that the `reason: Deprecated` condition is deprecated.
 `installedBundle.name`:: Displays the name of the bundle installed.
 `installedBundle.version`:: Displays the version of the bundle installed.
-`resolvedBundle.name`:: Displays the name of the resolved bundle.
-`resolvedBundle.version`:: Displays the version of the resolved bundle.
 ====
diff --git a/modules/olmv1-ocp-compat.adoc b/modules/olmv1-ocp-compat.adoc
new file mode 100644
index 000000000000..e53b03bfcf8e
--- /dev/null
+++ b/modules/olmv1-ocp-compat.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/update-paths.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="olmv1-ocp-compat_{context}"]
+= Compatibility with {product-title} versions
+
+Before cluster administrators can update their {product-title} cluster to its next minor version, they must ensure that all installed Operators are updated to a bundle version that is compatible with the cluster's next minor version (4.y+1).
+
+For example, Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. If an extension is using a deprecated API, it might no longer work after the {product-title} cluster is updated to the Kubernetes version where the API has been removed.
+
+If an Operator author knows that a specific bundle version is not supported and will not work correctly, for any reason, on {product-title} later than a certain cluster minor version, they can configure the maximum version of {product-title} that their Operator is compatible with.
+
+In the Operator project's cluster service version (CSV), authors can set the `olm.maxOpenShiftVersion` annotation to prevent administrators from updating the cluster before updating the installed Operator to a compatible version.
+
+.Example CSV with `olm.maxOpenShiftVersion` annotation
+[source,yaml]
+----
+apiVersion: operators.coreos.com/v1alpha1
+kind: ClusterServiceVersion
+metadata:
+  annotations:
+    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' <1>
+----
+<1> Specifies the latest minor version of {product-title} (4.y) that an Operator is compatible with. For example, setting `value` to `{product-version}` prevents cluster updates to minor versions later than {product-version} when this bundle is installed on a cluster.
++
+If the `olm.maxOpenShiftVersion` field is omitted, cluster updates are not blocked by this Operator.
+
+[NOTE]
+====
+When determining a cluster's next minor version (4.y+1), {olmv1} only considers major and minor versions (x and y) for comparisons. It ignores any _z-stream_ versions (4.y.z), also known as patch releases, or pre-release versions.
+
+For example, if the cluster's current version is `{product-version}.0`, the next minor version is `{ocp-nplus1}`. If the current version is `{product-version}.0-rc1`, the next minor version is still `{ocp-nplus1}`.
+====
\ No newline at end of file
diff --git a/modules/olmv1-red-hat-catalogs.adoc b/modules/olmv1-red-hat-catalogs.adoc
index c3735fddd79e..ef498c1e8fd2 100644
--- a/modules/olmv1-red-hat-catalogs.adoc
+++ b/modules/olmv1-red-hat-catalogs.adoc
@@ -11,50 +11,70 @@
 
 {olmv1-first} includes the following Red Hat-provided Operator catalogs on the cluster by default. If you want to add an additional catalog to your cluster, create a custom resource (CR) for the catalog and apply it to the cluster. The following custom resource (CR) examples show the default catalogs installed on the cluster.
 
-.Example Red Hat Operators catalog
+.Red{nbsp}Hat Operators catalog
 [source,yaml,subs="attributes+"]
 ----
-apiVersion: catalogd.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterCatalog
 metadata:
-  name: redhat-operators
+  name: openshift-redhat-operators
 spec:
+  priority: -100
   source:
-    type: image
     image:
+      pollIntervalMinutes: <poll_interval_duration> <1>
       ref: registry.redhat.io/redhat/redhat-operator-index:v{product-version}
-      pollInterval: <poll_interval_duration> <1>
+    type: Image
 ----
-<1> Specify the interval for polling the remote registry for newer image digests. The default value is `24h`. Valid units include seconds (`s`), minutes (`m`), and hours (`h`). To disable polling, set a zero value, such as `0s`.
+<1> Specify the interval in minutes for polling the remote registry for newer image digests. To disable polling, do not set the field.
 
-.Example Certified Operators catalog
+.Certified Operators catalog
 [source,yaml,subs="attributes+"]
 ----
-apiVersion: catalogd.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterCatalog
 metadata:
-  name: certified-operators
+  name: openshift-certified-operators
 spec:
+priority: -200
   source:
     type: image
     image:
+      pollIntervalMinutes: 10
       ref: registry.redhat.io/redhat/certified-operator-index:v{product-version}
-      pollInterval: 24h
+    type: Image
 ----
 
-.Example Community Operators catalog
+.Red{nbsp}Hat Marketplace catalog
 [source,yaml,subs="attributes+"]
 ----
-apiVersion: catalogd.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterCatalog
 metadata:
-  name: community-operators
+  name: openshift-redhat-marketplace
 spec:
+  priority: -300
+  source:
+    image:
+      pollIntervalMinutes: 10
+      ref: registry.redhat.io/redhat/redhat-marketplace-index:v{product-version}
+    type: Image
+----
+
+.Community Operators catalog
+[source,yaml,subs="attributes+"]
+----
+apiVersion: olm.operatorframework.io/v1
+kind: ClusterCatalog
+metadata:
+  name: openshift-community-operators
+spec:
+  priority: -400
   source:
-    type: image
     image:
+      pollIntervalMinutes: 10
       ref: registry.redhat.io/redhat/community-operator-index:v{product-version}
-      pollInterval: 24h
+    type: Image
 ----
 
 The following command adds a catalog to your cluster:
@@ -64,4 +84,4 @@ The following command adds a catalog to your cluster:
 ----
 $ oc apply -f <catalog_name>.yaml <1>
 ----
-<1> Specifies the catalog CR, such as `redhat-operators.yaml`.
+<1> Specifies the catalog CR, such as `my-catalog.yaml`.
diff --git a/modules/olmv1-required-rbac-to-install-and-manage-extension-resources.adoc b/modules/olmv1-required-rbac-to-install-and-manage-extension-resources.adoc
new file mode 100644
index 000000000000..b52c98699339
--- /dev/null
+++ b/modules/olmv1-required-rbac-to-install-and-manage-extension-resources.adoc
@@ -0,0 +1,37 @@
+// Module included in the following assemblies:
+//
+// * extensions/ce/managing-ce.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-required-rbac-to-install-and-manage-extension-resources_{context}"]
+= Required permissions to install and manage a cluster extension
+
+You must inspect the manifests included in the bundle image of a cluster extension to assign the necessary permissions. The service account requires enough role-based access controls (RBAC) to create and manage the following resources.
+
+[IMPORTANT]
+====
+Follow the principle of least privilege and scope permissions to specific resource names with the least RBAC required to run.
+====
+
+Admission plugins:: Because {product-title} clusters use the `OwnerReferencesPermissionEnforcement` admission plugin, cluster extensions must have permissions to update the `blockOwnerDeletion` and `ownerReferences` finalizers.
+
+Cluster role and cluster role bindings for the controllers of the extension:: You must define RBAC so that the installation service account can create and manage cluster roles and cluster role bindings for the extension controllers.
+
+Cluster service version (CSV):: You must define RBAC for the resources defined in the CSV of the cluster extension.
+
+Cluster-scoped bundle resources:: You must define RBAC to create and manage any cluster-scoped resources included in the bundle. If the cluster-scoped resources matches another resource type, such as a `ClusterRole`, you can add the resource to the pre-existing rule under the `resources` or `resourceNames` field.
+
+Custom resource definitions (CRDs):: You must define RBAC so that the installation service account can create and manage the CRDs for the extension. Also, you must grant the service account for the controller of the extension the RBAC to manage its CRDs.
+
+Deployments:: You must define RBAC for the installation service account to create and manage the deployments needed by the extension controller, such as services and config maps.
+
+Extension permissions:: You must include RBAC for the permissions and cluster permissions defined in the CSV. The installation service account needs the ability to grant these permissions to the extension controller, which needs these permissions to run.
+
+Namespace-scoped bundle resources:: You must define RBAC for any namespace-scoped bundle resources. The installation service account requires permission to create and manage resources, such as config maps or services.
+
+Roles and role bindings:: You must define RBAC for any roles or role bindings defined in the CSV. The installation service account needs permission to create and manage those roles and role bindings.
+
+// I am deleting the secrets section because I think it covered under the "extension permissions" term. Please let me know if I should put it back and if you have a suggestion for the defintion.
+
+Service accounts:: You must define RBAC so that the installation service account can create and manage the service accounts for the extension controllers.
diff --git a/modules/olmv1-troubleshooting-catalog-selection-errors.adoc b/modules/olmv1-troubleshooting-catalog-selection-errors.adoc
new file mode 100644
index 000000000000..18f55d84684c
--- /dev/null
+++ b/modules/olmv1-troubleshooting-catalog-selection-errors.adoc
@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+// * extensions/catalogs/olmv1-catalog-content-resolution.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="olmv1-troubleshooting-catalog-selection-errors_{context}"]
+= Troubleshooting catalog selection errors
+
+If bundle resolution fails because of ambiguity or because no catalog is selected, an error message is printed in the `status.conditions` field of the cluster extension.
+
+Perform the following actions to troubleshoot catalog selection errors:
+
+* Refine your selection criteria using labels or expressions.
+* Adjust your catalog priorities.
+* Ensure that only one bundle matches your package name and version requirements.
diff --git a/modules/olmv1-updating-an-operator.adoc b/modules/olmv1-updating-an-operator.adoc
index 7d9302e3ef92..aa293e47eb56 100644
--- a/modules/olmv1-updating-an-operator.adoc
+++ b/modules/olmv1-updating-an-operator.adoc
@@ -11,10 +11,9 @@ You can update your cluster extension or Operator by manually editing the custom
 
 .Prerequisites
 
-* You have a catalog installed.
-* You have downloaded a local copy of the catalog file.
 * You have an Operator or extension installed.
 * You have installed the `jq` CLI tool.
+* You have installed the `opm` CLI tool.
 
 .Procedure
 
@@ -24,19 +23,19 @@ You can update your cluster extension or Operator by manually editing the custom
 +
 [source,terminal]
 ----
-$ jq -s '.[] | select( .schema == "olm.channel" ) | \
-  select( .package == "<package_name>") | \
-  .name' /<path>/<catalog_name>.json
+$ opm render <catalog_registry_url>:<tag> \
+  | jq -s '.[] | select( .schema == "olm.channel" ) \
+  | select( .package == "openshift-pipelines-operator-rh") | .name'
 ----
 +
 .Example command
 [%collapsible]
 ====
-[source,terminal]
+[source,terminal,subs=attributes+]
 ----
-$ jq -s '.[] | select( .schema == "olm.channel" ) | \
-  select( .package == "openshift-pipelines-operator-rh") | \
-  .name' /home/username/rhoc.json
+$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
+  | jq -s '.[] | select( .schema == "olm.channel" ) \
+  | select( .package == "openshift-pipelines-operator-rh") | .name'
 ----
 ====
 +
@@ -46,10 +45,10 @@ $ jq -s '.[] | select( .schema == "olm.channel" ) | \
 [source,text]
 ----
 "latest"
-"pipelines-1.11"
-"pipelines-1.12"
-"pipelines-1.13"
 "pipelines-1.14"
+"pipelines-1.15"
+"pipelines-1.16"
+"pipelines-1.17"
 ----
 ====
 
@@ -57,20 +56,22 @@ $ jq -s '.[] | select( .schema == "olm.channel" ) | \
 +
 [source,terminal]
 ----
-$ jq -s '.[] | select( .package == "<package_name>" ) | \
-  select( .schema == "olm.channel" ) | \
-  select( .name == "<channel_name>" ) | .entries | \
-  .[] | .name' /<path>/<catalog_name>.json
+$ opm render <catalog_registry_url>:<tag> \
+  | jq -s '.[] | select( .package == "<package_name>" ) \
+  | select( .schema == "olm.channel" ) \
+  | select( .name == "<channel_name>" ) | .entries \
+  | .[] | .name'
 ----
 +
 .Example command
 [%collapsible]
 ====
-[source,terminal]
+[source,terminal,subs=attributes+]
 ----
-$ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
-select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
-.entries | .[] | .name' /home/username/rhoc.json
+$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
+  | jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) \
+  | select( .schema == "olm.channel" ) | select( .name == "latest" ) \
+  | .entries | .[] | .name'
 ----
 ====
 +
@@ -79,15 +80,10 @@ select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
 ====
 [source,text]
 ----
-"openshift-pipelines-operator-rh.v1.11.1"
-"openshift-pipelines-operator-rh.v1.12.0"
-"openshift-pipelines-operator-rh.v1.12.1"
-"openshift-pipelines-operator-rh.v1.12.2"
-"openshift-pipelines-operator-rh.v1.13.0"
-"openshift-pipelines-operator-rh.v1.14.1"
-"openshift-pipelines-operator-rh.v1.14.2"
-"openshift-pipelines-operator-rh.v1.14.3"
-"openshift-pipelines-operator-rh.v1.14.4"
+"openshift-pipelines-operator-rh.v1.15.0"
+"openshift-pipelines-operator-rh.v1.16.0"
+"openshift-pipelines-operator-rh.v1.17.0"
+"openshift-pipelines-operator-rh.v1.17.1"
 ----
 ====
 
@@ -109,134 +105,167 @@ $ oc get clusterextension pipelines-operator -o yaml
 ====
 [source,text]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: ClusterExtension
+apiVersion: v1
+items:
+- apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    annotations:
+      kubectl.kubernetes.io/last-applied-configuration: |
+        {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
+    creationTimestamp: "2025-02-18T21:48:13Z"
+    finalizers:
+    - olm.operatorframework.io/cleanup-unpack-cache
+    - olm.operatorframework.io/cleanup-contentmanager-cache
+    generation: 1
+    name: pipelines-operator
+    resourceVersion: "72725"
+    uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
+  spec:
+    namespace: pipelines
+    serviceAccount:
+      name: pipelines-installer
+    source:
+      catalog:
+        packageName: openshift-pipelines-operator-rh
+        upgradeConstraintPolicy: CatalogProvided
+        version: 1.14.x
+      sourceType: Catalog
+  status:
+    conditions:
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
+      message: ""
+      observedGeneration: 1
+      reason: Deprecated
+      status: "False"
+      type: Deprecated
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
+      message: ""
+      observedGeneration: 1
+      reason: Deprecated
+      status: "False"
+      type: PackageDeprecated
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
+      message: ""
+      observedGeneration: 1
+      reason: Deprecated
+      status: "False"
+      type: ChannelDeprecated
+    - lastTransitionTime: "2025-02-18T21:48:13Z"
+      message: ""
+      observedGeneration: 1
+      reason: Deprecated
+      status: "False"
+      type: BundleDeprecated
+    - lastTransitionTime: "2025-02-18T21:48:16Z"
+      message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
+        successfully
+      observedGeneration: 1
+      reason: Succeeded
+      status: "True"
+      type: Installed
+    - lastTransitionTime: "2025-02-18T21:48:16Z"
+      message: desired state reached
+      observedGeneration: 1
+      reason: Succeeded
+      status: "True"
+      type: Progressing
+    install:
+      bundle:
+        name: openshift-pipelines-operator-rh.v1.14.5
+        version: 1.14.5
+kind: List
 metadata:
-  annotations:
-    kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"\u003c1.12"}}
-  creationTimestamp: "2024-06-11T15:55:37Z"
-  generation: 1
-  name: pipelines-operator
-  resourceVersion: "69776"
-  uid: 6a11dff3-bfa3-42b8-9e5f-d8babbd6486f
-spec:
-  channel: latest
-  installNamespace: openshift-operators
-  packageName: openshift-pipelines-operator-rh
-  upgradeConstraintPolicy: Enforce
-  version: <1.12
-status:
-  conditions:
-  - lastTransitionTime: "2024-06-11T15:56:09Z"
-    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
-    observedGeneration: 1
-    reason: Success
-    status: "True"
-    type: Installed
-  - lastTransitionTime: "2024-06-11T15:55:50Z"
-    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
-    observedGeneration: 1
-    reason: Success
-    status: "True"
-    type: Resolved
-  - lastTransitionTime: "2024-06-11T15:55:50Z"
-    message: ""
-    observedGeneration: 1
-    reason: Deprecated
-    status: "False"
-    type: Deprecated
-  - lastTransitionTime: "2024-06-11T15:55:50Z"
-    message: ""
-    observedGeneration: 1
-    reason: Deprecated
-    status: "False"
-    type: PackageDeprecated
-  - lastTransitionTime: "2024-06-11T15:55:50Z"
-    message: ""
-    observedGeneration: 1
-    reason: Deprecated
-    status: "False"
-    type: ChannelDeprecated
-  - lastTransitionTime: "2024-06-11T15:55:50Z"
-    message: ""
-    observedGeneration: 1
-    reason: Deprecated
-    status: "False"
-    type: BundleDeprecated
-  installedBundle:
-    name: openshift-pipelines-operator-rh.v1.11.1
-    version: 1.11.1
-  resolvedBundle:
-    name: openshift-pipelines-operator-rh.v1.11.1
-    version: 1.11.1
+  resourceVersion: ""
 ----
 ====
 
 . Edit your CR by using one of the following methods:
 
-** If you want to pin your Operator or extension to specific version, such as `1.12.1`, edit your CR similar to the following example:
+** If you want to pin your Operator or extension to specific version, such as `1.15.0`, edit your CR similar to the following example:
 +
 .Example `pipelines-operator.yaml` CR
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   name: pipelines-operator
 spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace>
-  version: "1.12.1" <1>
-----
-<1> Update the version from `1.11.1` to `1.12.1`
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      version: "1.15.0" <1>
+----
+<1> Update the version from `1.14.x` to `1.15.0`
 
 ** If you want to define a range of acceptable update versions, edit your CR similar to the following example:
 +
 .Example CR with a version range specified
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   name: pipelines-operator
 spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace>
-  version: ">1.11.1, <1.13" <1>
-----
-<1> Specifies that the desired version range is greater than version `1.11.1` and less than `1.13`. For more information, see "Support for version ranges" and "Version comparison strings".
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      version: ">1.15, <1.17" <1>
+----
+<1> Specifies that the desired version range is greater than version `1.15` and less than `1.17`. For more information, see "Support for version ranges" and "Version comparison strings".
 
 ** If you want to update to the latest version that can be resolved from a channel, edit your CR similar to the following example:
 +
 .Example CR with a specified channel
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   name: pipelines-operator
 spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace>
-  channel: pipelines-1.13 <1>
-----
-<1> Installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed.
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      channels:
+        - latest <1>
+----
+<1> Installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed. Enter values as an array.
 
 ** If you want to specify a channel and version or version range, edit your CR similar to the following example:
 +
 .Example CR with a specified channel and version range
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   name: pipelines-operator
 spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace>
-  channel: latest
-  version: "<1.13"
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    sourceType: Catalog
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      channels:
+        - latest
+      version: "<1.16"
 ----
 +
 For more information, see "Example custom resources (CRs) that specify a target version".
@@ -253,24 +282,6 @@ $ oc apply -f pipelines-operator.yaml
 ----
 clusterextension.olm.operatorframework.io/pipelines-operator configured
 ----
-+
-[TIP]
-====
-You can patch and apply the changes to your CR from the CLI by running the following command:
-
-[source,terminal]
-----
-$ oc patch clusterextension/pipelines-operator -p \
-  '{"spec":{"version":"<1.13"}}' \
-  --type=merge
-----
-
-.Example output
-[source,text]
-----
-clusterextension.olm.operatorframework.io/pipelines-operator patched
-----
-====
 
 .Verification
 
@@ -286,67 +297,73 @@ $ oc get clusterextension pipelines-operator -o yaml
 ====
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   annotations:
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"\u003c1.13"}}
-  creationTimestamp: "2024-06-11T18:23:26Z"
+      {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"\u003c1.16"},"sourceType":"Catalog"}}}
+  creationTimestamp: "2025-02-18T21:48:13Z"
+  finalizers:
+  - olm.operatorframework.io/cleanup-unpack-cache
+  - olm.operatorframework.io/cleanup-contentmanager-cache
   generation: 2
-  name: pipelines-operator
-  resourceVersion: "66310"
-  uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
+  name: pipes
+  resourceVersion: "90693"
+  uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
 spec:
-  channel: latest
-  installNamespace: openshift-operators
-  packageName: openshift-pipelines-operator-rh
-  upgradeConstraintPolicy: Enforce
-  version: <1.13
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      upgradeConstraintPolicy: CatalogProvided
+      version: <1.16
+    sourceType: Catalog
 status:
   conditions:
-  - lastTransitionTime: "2024-06-11T18:23:33Z"
-    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
-    observedGeneration: 2
-    reason: Success
-    status: "True"
-    type: Resolved
-  - lastTransitionTime: "2024-06-11T18:23:52Z"
-    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
-    observedGeneration: 2
-    reason: Success
-    status: "True"
-    type: Installed
-  - lastTransitionTime: "2024-06-11T18:23:33Z"
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
     message: ""
     observedGeneration: 2
     reason: Deprecated
     status: "False"
     type: Deprecated
-  - lastTransitionTime: "2024-06-11T18:23:33Z"
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
     message: ""
     observedGeneration: 2
     reason: Deprecated
     status: "False"
     type: PackageDeprecated
-  - lastTransitionTime: "2024-06-11T18:23:33Z"
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
     message: ""
     observedGeneration: 2
     reason: Deprecated
     status: "False"
     type: ChannelDeprecated
-  - lastTransitionTime: "2024-06-11T18:23:33Z"
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
     message: ""
     observedGeneration: 2
     reason: Deprecated
     status: "False"
     type: BundleDeprecated
-  installedBundle:
-    name: openshift-pipelines-operator-rh.v1.12.2
-    version: 1.12.2
-  resolvedBundle:
-    name: openshift-pipelines-operator-rh.v1.12.2
-    version: 1.12.2
+  - lastTransitionTime: "2025-02-18T21:48:16Z"
+    message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd
+      successfully
+    observedGeneration: 2
+    reason: Succeeded
+    status: "True"
+    type: Installed
+  - lastTransitionTime: "2025-02-18T21:48:16Z"
+    message: desired state reached
+    observedGeneration: 2
+    reason: Succeeded
+    status: "True"
+    type: Progressing
+  install:
+    bundle:
+      name: openshift-pipelines-operator-rh.v1.15.2
+      version: 1.15.2
 ----
 ====
 
@@ -364,61 +381,73 @@ $ oc get clusterextension <operator_name> -o yaml
 ====
 [source,text]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
+apiVersion: olm.operatorframework.io/v1
 kind: ClusterExtension
 metadata:
   annotations:
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"3.0"}}
-  creationTimestamp: "2024-06-11T18:23:26Z"
+      {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"9.x"},"sourceType":"Catalog"}}}
+  creationTimestamp: "2025-02-18T21:48:13Z"
+  finalizers:
+  - olm.operatorframework.io/cleanup-unpack-cache
+  - olm.operatorframework.io/cleanup-contentmanager-cache
   generation: 3
-  name: pipelines-operator
-  resourceVersion: "71852"
-  uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
+  name: pipes
+  resourceVersion: "93334"
+  uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
 spec:
-  channel: latest
-  installNamespace: openshift-operators
-  packageName: openshift-pipelines-operator-rh
-  upgradeConstraintPolicy: Enforce
-  version: "3.0"
+  namespace: pipelines
+  serviceAccount:
+    name: pipelines-installer
+  source:
+    catalog:
+      packageName: openshift-pipelines-operator-rh
+      upgradeConstraintPolicy: CatalogProvided
+      version: 9.x
+    sourceType: Catalog
 status:
   conditions:
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: 'error upgrading from currently installed version "1.12.2": no package
-      "openshift-pipelines-operator-rh" matching version "3.0" found in channel "latest"'
-    observedGeneration: 3
-    reason: ResolutionFailed
-    status: "False"
-    type: Resolved
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: installation has not been attempted as resolution failed
-    observedGeneration: 3
-    reason: InstallationStatusUnknown
-    status: Unknown
-    type: Installed
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: deprecation checks have not been attempted as resolution failed
-    observedGeneration: 3
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
+    message: ""
+    observedGeneration: 2
     reason: Deprecated
-    status: Unknown
+    status: "False"
     type: Deprecated
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: deprecation checks have not been attempted as resolution failed
-    observedGeneration: 3
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
+    message: ""
+    observedGeneration: 2
     reason: Deprecated
-    status: Unknown
+    status: "False"
     type: PackageDeprecated
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: deprecation checks have not been attempted as resolution failed
-    observedGeneration: 3
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
+    message: ""
+    observedGeneration: 2
     reason: Deprecated
-    status: Unknown
+    status: "False"
     type: ChannelDeprecated
-  - lastTransitionTime: "2024-06-11T18:29:02Z"
-    message: deprecation checks have not been attempted as resolution failed
-    observedGeneration: 3
+  - lastTransitionTime: "2025-02-18T21:48:13Z"
+    message: ""
+    observedGeneration: 2
     reason: Deprecated
-    status: Unknown
+    status: "False"
     type: BundleDeprecated
+  - lastTransitionTime: "2025-02-18T21:48:16Z"
+    message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd
+      successfully
+    observedGeneration: 3
+    reason: Succeeded
+    status: "True"
+    type: Installed
+  - lastTransitionTime: "2025-02-18T21:48:16Z"
+    message: 'error upgrading from currently installed version "1.15.2": no bundles
+      found for package "openshift-pipelines-operator-rh" matching version "9.x"'
+    observedGeneration: 3
+    reason: Retrying
+    status: "True"
+    type: Progressing
+  install:
+    bundle:
+      name: openshift-pipelines-operator-rh.v1.15.2
+      version: 1.15.2
 ----
 ====
diff --git a/modules/olmv1-version-range-comparisons.adoc b/modules/olmv1-version-range-comparisons.adoc
index c5f2ac2fda07..2c3cc0e5123a 100644
--- a/modules/olmv1-version-range-comparisons.adoc
+++ b/modules/olmv1-version-range-comparisons.adoc
@@ -40,14 +40,19 @@ You can specify a version range in an Operator or extension's CR by using a rang
 .Example version range comparison
 [source,yaml]
 ----
-apiVersion: olm.operatorframework.io/v1alpha1
-kind: ClusterExtension
-metadata:
-  name: pipelines-operator
-spec:
-  packageName: openshift-pipelines-operator-rh
-  installNamespace: <namespace_name>
-  version: ">=1.11, <1.13"
+apiVersion: olm.operatorframework.io/v1
+  kind: ClusterExtension
+  metadata:
+    name: <clusterextension_name>
+  spec:
+    namespace: <installed_namespace>
+    serviceAccount:
+      name: <service_account_installer_name>
+    source:
+      sourceType: Catalog
+      catalog:
+        packageName: <package_name>
+        version: ">=1.11, <1.13"
 ----
 
 You can use wildcard characters in all types of comparison strings. {olmv1} accepts `x`, `X`, and asterisks (`*`) as wildcard characters. When you use a wildcard character with the equal sign (`=`) comparison operator, you define a comparison at the patch or minor version level.
diff --git a/modules/opening-default-network-ports-udn.adoc b/modules/opening-default-network-ports-udn.adoc
new file mode 100644
index 000000000000..7170f649a152
--- /dev/null
+++ b/modules/opening-default-network-ports-udn.adoc
@@ -0,0 +1,31 @@
+//module included in the following assembly:
+//
+// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="opening-default-network-ports-udn_{context}"]
+= Opening default network ports on user-defined network pods
+
+By default, pods on a user-defined network (UDN) are isolated from the default network. This means that default network pods, such as those running monitoring services (Prometheus or Alertmanager) or the {product-title} image registry, cannot initiate connections to UDN pods.
+
+To allow default network pods to connect to a user-defined network pod, you can use the `k8s.ovn.org/open-default-ports` annotation. This annotation opens specific ports on the user-defined network pod for access from the default network.
+
+The following pod specification allows incoming TCP connections on port `80` and UDP traffic on port `53` from the default network:
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  annotations:
+    k8s.ovn.org/open-default-ports: |
+      - protocol: tcp
+        port: 80
+      - protocol: udp
+        port: 53
+# ...
+----
+ 
+[NOTE]
+====
+Open ports are accessible on the pod's default network IP, not its UDN network IP.
+====
\ No newline at end of file
diff --git a/modules/opm-cli-ref-generate.adoc b/modules/opm-cli-ref-generate.adoc
index ca05596de6b7..941e01fd341d 100644
--- a/modules/opm-cli-ref-generate.adoc
+++ b/modules/opm-cli-ref-generate.adoc
@@ -70,6 +70,6 @@ $ opm generate dockerfile <dcRootDir> [<flags>]
 ifndef::openshift-origin[]
 [NOTE]
 ====
-To build with the official Red Hat image, use the `registry.redhat.io/openshift4/ose-operator-registry:v{product-version}` value with the `-i` flag.
+To build with the official Red Hat image, use the `registry.redhat.io/openshift4/ose-operator-registry-rhel9:v{product-version}` value with the `-i` flag.
 ====
 endif::[]
\ No newline at end of file
diff --git a/modules/osd-aws-privatelink-firewall-prerequisites.adoc b/modules/osd-aws-privatelink-firewall-prerequisites.adoc
index dda76a2a3f2b..1526664756d3 100644
--- a/modules/osd-aws-privatelink-firewall-prerequisites.adoc
+++ b/modules/osd-aws-privatelink-firewall-prerequisites.adoc
@@ -4,28 +4,17 @@
 // * rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc
 // * rosa_planning/rosa-sts-aws-prereqs.adoc
 
-ifeval::["{context}" == "rosa-sts-aws-prereqs"]
-:fedramp:
-:rosa-classic-sts:
-endif::[]
-ifeval::["{context}" == "aws-ccs"]
-:osd:
-endif::[]
-ifeval::["{context}" == "prerequisites"]
-:rosa-classic:
-endif::[]
-
 :_mod-docs-content-type: PROCEDURE
-ifdef::rosa-classic-sts[]
+ifdef::openshift-rosa[]
 [id="rosa-classic-firewall-prerequisites_{context}"]
-= ROSA Classic
-endif::rosa-classic-sts[]
-ifndef::rosa-classic-sts[]
+= Firewall prerequisites for ROSA (classic architecture) clusters using STS
+endif::openshift-rosa[]
+ifdef::openshift-dedicated[]
 [id="osd-aws-privatelink-firewall-prerequisites_{context}"]
-= AWS firewall prerequisites
+= Firewall prerequisites
 
 If you are using a firewall to control egress traffic from {product-title}, you must configure your firewall to grant access to the certain domain and port combinations below. {product-title} requires this access to provide a fully managed OpenShift service.
-endif::rosa-classic-sts[]
+endif::openshift-dedicated[]
 
 ifdef::openshift-rosa[]
 [IMPORTANT]
@@ -65,6 +54,18 @@ endif::[]
 |443
 |Provides core container images.
 
+|`cdn04.quay.io`
+|443
+|Provides core container images.
+
+|`cdn05.quay.io`
+|443
+|Provides core container images.
+
+|`cdn06.quay.io`
+|443
+|Provides core container images.
+
 |`sso.redhat.com`
 |443
 |Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.redhat.com` to download the pull secret and use Red{nbsp}Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, and so on.
@@ -77,10 +78,6 @@ endif::[]
 |443
 |Provides core container images.
 
-|`openshift.org`
-|443
-|Provides {op-system-first} images.
-
 |`registry.access.redhat.com`
 |443
 |Hosts all the container images that are stored on the Red{nbsp}Hat Ecosytem Catalog. Additionally, the registry provides access to the `odo` CLI tool that helps developers build on OpenShift and Kubernetes.
@@ -105,53 +102,15 @@ endif::[]
 |443
 |Provides core container images as a fallback when quay.io is not available.
 
-|`.q1w2.quay.rhcloud.com`
-|443
-|Provides core container images as a fallback when quay.io is not available.
-
-|`www.okd.io`
-|443
-|The `openshift.org` site redirects through `www.okd.io`.
-
-|`www.redhat.com`
-|443
-|The `sso.redhat.com` site redirects through `www.redhat.com`.
-
-|`aws.amazon.com`
-|443
-|The `iam.amazonaws.com` and `sts.amazonaws.com` sites redirect through `aws.amazon.com`.
-
 |`catalog.redhat.com`
 |443
 |The `registry.access.redhat.com` and `https://registry.redhat.io` sites redirect through `catalog.redhat.com`.
 
-|`dvbwgdztaeq9o.cloudfront.net` ^[1]^
+|`oidc.op1.openshiftapps.com`
 |443
 |Used by ROSA for STS implementation with managed OIDC configuration.
-
-ifdef::fedramp[]
-|`time-a-g.nist.gov`
-|123 ^[2]^
-|Allows NTP traffic for FedRAMP.
-
-|`time-a-wwv.nist.gov`
-|123 ^[2]^
-|Allows NTP traffic for FedRAMP.
-
-|`time-a-b.nist.gov`
-|123 ^[2]^
-|Allows NTP traffic for FedRAMP.
-endif::fedramp[]
 |===
 +
-[.small]
---
-1. The string of alphanumeric characters before `cloudfront.net` could change if there is a major cloudfront outage that requires redirecting the resource.
-ifdef::fedramp[]
-2. Both TCP and UDP ports.
-endif::fedramp[]
---
-+
 . Allowlist the following telemetry URLs:
 +
 [cols="6,1,6",options="header"]
@@ -174,10 +133,6 @@ endif::fedramp[]
 |443
 |Required for telemetry and Red{nbsp}Hat Insights.
 
-|`cloud.redhat.com/api/ingress`
-|443
-|Required for telemetry and Red{nbsp}Hat Insights.
-
 |`observatorium-mst.api.openshift.com`
 |443
 |Required for managed OpenShift-specific telemetry.
@@ -259,11 +214,7 @@ Alternatively, if you choose to not use a wildcard for Amazon Web Services (AWS)
 
 |`mirror.openshift.com`
 |443
-|Used to access mirrored installation content and images. This site is also a source of release image signatures, although the Cluster Version Operator (CVO) needs only a single functioning source.
-
-|`storage.googleapis.com/openshift-release` (Recommended)
-|443
-|Alternative site to mirror.openshift.com/. Used to download platform release signatures that are used by the cluster to know what images to pull from quay.io.
+|Used to access mirrored installation content and images. This site is also a source of release image signatures.
 
 |`api.openshift.com`
 |443
@@ -292,25 +243,6 @@ Alternatively, if you choose to not use a wildcard for Amazon Web Services (AWS)
 |443
 |Alerting service used by {product-title} to send periodic pings that indicate whether the cluster is available and running.
 
-|`.osdsecuritylogs.splunkcloud.com`
-OR
-`inputs1.osdsecuritylogs.splunkcloud.com`
-`inputs2.osdsecuritylogs.splunkcloud.com`
-`inputs4.osdsecuritylogs.splunkcloud.com`
-`inputs5.osdsecuritylogs.splunkcloud.com`
-`inputs6.osdsecuritylogs.splunkcloud.com`
-`inputs7.osdsecuritylogs.splunkcloud.com`
-`inputs8.osdsecuritylogs.splunkcloud.com`
-`inputs9.osdsecuritylogs.splunkcloud.com`
-`inputs10.osdsecuritylogs.splunkcloud.com`
-`inputs11.osdsecuritylogs.splunkcloud.com`
-`inputs12.osdsecuritylogs.splunkcloud.com`
-`inputs13.osdsecuritylogs.splunkcloud.com`
-`inputs14.osdsecuritylogs.splunkcloud.com`
-`inputs15.osdsecuritylogs.splunkcloud.com`
-|9997
-|Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}Hat SRE for log-based alerting.
-
 |`http-inputs-osdsecuritylogs.splunkcloud.com`
 |443
 |Required. Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}Hat SRE for log-based alerting.
@@ -318,36 +250,4 @@ OR
 |`sftp.access.redhat.com` (Recommended)
 |22
 |The SFTP server used by `must-gather-operator` to upload diagnostic logs to help troubleshoot issues with the cluster.
-|===
-
-. Allowlist the following URLs for optional third-party content:
-+
-[cols="6,1,6",options="header"]
-|===
-|Domain | Port | Function
-|`registry.connect.redhat.com`
-| 443
-| Required for all third-party-images and certified operators.
-
-|`rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com`
-| 443
-| Provides access to container images hosted on `registry.connect.redhat.com`
-
-|`oso-rhc4tp-docker-registry.s3-us-west-2.amazonaws.com`
-| 443
-| Required for Sonatype Nexus, F5 Big IP operators.
-|===
-
-. Allowlist any site that provides resources for a language or framework that your builds require.
-. Allowlist any outbound URLs that depend on the languages and frameworks used in OpenShift. See link:https://access.redhat.com/solutions/2998411[OpenShift Outbound URLs to Allow] for a list of recommended URLs to be allowed on the firewall or proxy.
-
-ifeval::["{context}" == "rosa-sts-aws-prereqs"]
-:!fedramp:
-:!rosa-classic-sts:
-endif::[]
-ifeval::["{context}" == "aws-ccs"]
-:!osd:
-endif::[]
-ifeval::["{context}" == "prerequisites"]
-:!rosa-classic:
-endif::[]
+|===
\ No newline at end of file
diff --git a/modules/osd-create-cluster-ccs.adoc b/modules/osd-create-cluster-ccs.adoc
index dc67a9f9b39a..b747ec13f89e 100644
--- a/modules/osd-create-cluster-ccs.adoc
+++ b/modules/osd-create-cluster-ccs.adoc
@@ -68,36 +68,36 @@ To successfully create a cluster, you must select *Enable Secure Boot support fo
 +
 
 .. Leave *Enable user workload monitoring* selected to monitor your own projects in isolation from Red Hat Site Reliability Engineer (SRE) platform metrics. This option is enabled by default.
-.. Optional: Expand *Advanced Encryption* to make changes to encryption settings.
 
-... Accept the default setting *Use default KMS Keys* to use your default AWS KMS key, or select *Use Custom KMS keys* to use a custom KMS key.
-.... With *Use Custom KMS keys* selected, enter the AWS Key Management Service (KMS) custom key Amazon Resource Name (ARN) ARN in the *Key ARN* field.
-The key is used for encrypting all control plane, infrastructure, worker node root volumes, and persistent volumes in your cluster.
+. Optional: Expand *Advanced Encryption* to make changes to encryption settings.
 
-+
+.. Select *Use custom KMS keys* to use custom KMS keys. If you prefer not to use custom KMS keys, leave the default setting *Use default KMS Keys*.
 
-... Select *Use custom KMS keys* to use custom KMS keys. If you prefer not to use custom KMS keys, leave the default setting *Use default KMS Keys*.
 +
+
 [IMPORTANT]
 ====
 To use custom KMS keys, the IAM service account `osd-ccs-admin` must be granted the *Cloud KMS CryptoKey Encrypter/Decrypter* role. For more information about granting roles on a resource, see link:https://cloud.google.com/kms/docs/iam#granting_roles_on_a_resource[Granting roles on a resource].
 ====
-+
-With *Use Custom KMS keys* selected:
 
-.... Select a key ring location from the *Key ring location* drop-down menu.
-.... Select a key ring from the *Key ring* drop-down menu.
-.... Select a key name from the *Key name* drop-down menu.
-.... Provide the *KMS Service Account*.
 +
-... Optional: Select *Enable FIPS cryptography* if you require your cluster to be FIPS validated.
+
+.. With *Use Custom KMS keys* selected:
+
+... Select a key ring location from the *Key ring location* drop-down menu.
+... Select a key ring from the *Key ring* drop-down menu.
+... Select a key name from the *Key name* drop-down menu.
+... Provide the *KMS Service Account*.
+
+.. Optional: Select *Enable FIPS cryptography* if you require your cluster to be FIPS validated.
 +
 [NOTE]
 ====
 If *Enable FIPS cryptography* is selected, *Enable additional etcd encryption* is enabled by default and cannot be disabled. You can select *Enable additional etcd encryption* without selecting *Enable FIPS cryptography*.
 ====
 +
-... Optional: Select *Enable additional etcd encryption* if you require etcd key value encryption. With this option, the etcd key values are encrypted, but the keys are not. This option is in addition to the control plane storage encryption that encrypts the etcd volumes in {product-title} clusters by default.
+.. Optional: Select *Enable additional etcd encryption* if you require etcd key value encryption.
+With this option, the etcd key values are encrypted, but not the keys. This option is in addition to the control plane storage encryption that encrypts the etcd volumes in {product-title} clusters by default.
 +
 [NOTE]
 ====
diff --git a/modules/osd-gcp-psc-firewall-prerequisites.adoc b/modules/osd-gcp-psc-firewall-prerequisites.adoc
index 336041e25774..0451f73f5426 100644
--- a/modules/osd-gcp-psc-firewall-prerequisites.adoc
+++ b/modules/osd-gcp-psc-firewall-prerequisites.adoc
@@ -153,40 +153,6 @@ Managed clusters require the enabling of telemetry to allow Red Hat to react mor
 |443
 |Alerting service used by {product-title} to send periodic pings that indicate whether the cluster is available and running.
 
-|`*.osdsecuritylogs.splunkcloud.com`
-
-OR
-
-`inputs1.osdsecuritylogs.splunkcloud.com`
-
-`inputs2.osdsecuritylogs.splunkcloud.com`
-
-`inputs4.osdsecuritylogs.splunkcloud.com`
-
-`inputs5.osdsecuritylogs.splunkcloud.com`
-
-`inputs6.osdsecuritylogs.splunkcloud.com`
-
-`inputs7.osdsecuritylogs.splunkcloud.com`
-
-`inputs8.osdsecuritylogs.splunkcloud.com`
-
-`inputs9.osdsecuritylogs.splunkcloud.com`
-
-`inputs10.osdsecuritylogs.splunkcloud.com`
-
-`inputs11.osdsecuritylogs.splunkcloud.com`
-
-`inputs12.osdsecuritylogs.splunkcloud.com`
-
-`inputs13.osdsecuritylogs.splunkcloud.com`
-
-`inputs14.osdsecuritylogs.splunkcloud.com`
-
-`inputs15.osdsecuritylogs.splunkcloud.com`
-|9997
-|Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}Hat SRE for log-based alerting.
-
 |`http-inputs-osdsecuritylogs.splunkcloud.com`
 |443
 |Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}Hat SRE for log-based alerting.
diff --git a/modules/osd-lifecycle-policy.adoc b/modules/osd-lifecycle-policy.adoc
new file mode 100644
index 000000000000..326ba04ee409
--- /dev/null
+++ b/modules/osd-lifecycle-policy.adoc
@@ -0,0 +1,15 @@
+
+// Module included in the following assemblies:
+//
+// * upgrading/osd-upgrades.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="osd-lifecycle-policy_{context}"]
+= Life cycle policies and planning
+
+To plan an upgrade, review the _{product-title} update life cycle_ guide in the "Additional resources" section. The life cycle page includes release definitions, support and upgrade requirements, installation policy information, and life cycle dates.
+
+You can use update channels to decide which Red Hat OpenShift Container Platform minor version to update your clusters to. {product-title} supports updates only through the `stable` channel. To learn more about OpenShift update channels and releases, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/updating_clusters/understanding-openshift-updates-1#understanding-update-channels-releases[Understanding update channels and releases].
+
+
+
diff --git a/modules/osdk-ansible-inside-operator-logs-full-result.adoc b/modules/osdk-ansible-inside-operator-logs-full-result.adoc
index de8806af831a..d346d28e1e6f 100644
--- a/modules/osdk-ansible-inside-operator-logs-full-result.adoc
+++ b/modules/osdk-ansible-inside-operator-logs-full-result.adoc
@@ -10,7 +10,7 @@ You can set the environment variable `ANSIBLE_DEBUG_LOGS` to `True` to enable ch
 
 .Procedure
 
-* Edit the `config/manager/manager.yaml` and `config/default/manager_auth_proxy_patch.yaml` files to include the following configuration:
+* Edit the `config/manager/manager.yaml` and `config/default/manager_metrics_patch.yaml` files to include the following configuration:
 +
 [source,terminal]
 ----
diff --git a/modules/osdk-bundle-operator.adoc b/modules/osdk-bundle-operator.adoc
index 15fdada31ca4..d27dbcdfdd05 100644
--- a/modules/osdk-bundle-operator.adoc
+++ b/modules/osdk-bundle-operator.adoc
@@ -1,7 +1,6 @@
 // Module included in the following assemblies:
 //
 // * operators/operator_sdk/golang/osdk-golang-tutorial.adoc
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
 // * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
 // * operators/operator_sdk/osdk-working-bundle-images.adoc
diff --git a/modules/osdk-common-prereqs.adoc b/modules/osdk-common-prereqs.adoc
index ddb14007afb5..a02d83933ea3 100644
--- a/modules/osdk-common-prereqs.adoc
+++ b/modules/osdk-common-prereqs.adoc
@@ -6,10 +6,7 @@
 // * operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
 // * operators/operator_sdk/helm/osdk-helm-quickstart.adoc
 // * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
 // * operators/operator_sdk/osdk-working-bundle-images.adoc
-// * operators/operator_sdk/java/osdk-java-quickstart.adoc
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
 
 ifeval::["{context}" == "osdk-ansible-quickstart"]
 :ansible:
@@ -23,12 +20,6 @@ endif::[]
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :golang:
 endif::[]
-ifeval::["{context}" == "osdk-java-quickstart"]
-:java:
-endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-endif::[]
 
 [id="osdk-common-prereqs_{context}"]
 = Prerequisites
@@ -45,10 +36,6 @@ ifdef::ansible[]
 * link:https://www.python.org/downloads/[Python] 3.9+
 * link:https://pypi.org/project/kubernetes/[Python Kubernetes client]
 endif::[]
-ifdef::java[]
-* link:https://java.com/en/download/help/download_options.html[Java] 11+
-* link:https://maven.apache.org/install.html[Maven] 3.6.3+
-endif::[]
 ifndef::openshift-dedicated,openshift-rosa[]
 * Logged into an {product-title} {product-version} cluster with `oc` with an account that has `cluster-admin` permissions
 endif::openshift-dedicated,openshift-rosa[]
@@ -69,9 +56,3 @@ endif::[]
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :!golang:
 endif::[]
-ifeval::["{context}" == "osdk-java-quickstart"]
-:!java:
-endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-endif::[]
diff --git a/modules/osdk-create-project.adoc b/modules/osdk-create-project.adoc
index b2fec6c03c56..cbff19fe7a0e 100644
--- a/modules/osdk-create-project.adoc
+++ b/modules/osdk-create-project.adoc
@@ -19,11 +19,6 @@ ifeval::["{context}" == "osdk-helm-tutorial"]
 :type: Helm
 :app: nginx
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-:type: Java
-:app: memcached
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-create-project_{context}"]
@@ -63,9 +58,6 @@ endif::[]
 ifdef::helm[]
 with the `helm` plugin
 endif::[]
-ifdef::java[]
-with the `quarkus` plugin
-endif::[]
 to initialize the project:
 +
 [source,terminal,subs="attributes+"]
@@ -109,14 +101,6 @@ The `init` command creates the `nginx-operator` project specifically for watchin
 
 . For Helm-based projects, the `init` command generates the RBAC rules in the `config/rbac/role.yaml` file based on the resources that would be deployed by the default manifest for the chart. Verify that the rules generated in this file meet the permission requirements of the Operator.
 endif::[]
-ifdef::java[]
-----
-$ operator-sdk init \
-    --plugins=quarkus \
-    --domain=example.com \
-    --project-name=memcached-operator
-----
-endif::[]
 
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :!golang:
@@ -133,8 +117,3 @@ ifeval::["{context}" == "osdk-helm-tutorial"]
 :!type:
 :!app:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-:!type:
-:!app:
-endif::[]
\ No newline at end of file
diff --git a/modules/osdk-deploy-olm.adoc b/modules/osdk-deploy-olm.adoc
index ee5084d5bf37..9fb528129f17 100644
--- a/modules/osdk-deploy-olm.adoc
+++ b/modules/osdk-deploy-olm.adoc
@@ -11,9 +11,6 @@ endif::[]
 ifeval::["{context}" == "osdk-working-bundle-images"]
 :golang:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-deploy-olm_{context}"]
@@ -70,7 +67,4 @@ ifeval::["{context}" == "osdk-golang-tutorial"]
 endif::[]
 ifeval::["{context}" == "osdk-working-bundle-images"]
 :!golang:
-endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
 endif::[]
\ No newline at end of file
diff --git a/modules/osdk-hh-create-cr.adoc b/modules/osdk-hh-create-cr.adoc
deleted file mode 100644
index 6e2706bfc731..000000000000
--- a/modules/osdk-hh-create-cr.adoc
+++ /dev/null
@@ -1,157 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-hh-create-cr_{context}"]
-= Creating custom resources
-
-After your Operator is installed, you can test it by creating custom resources (CRs) that are now provided on the cluster by the Operator.
-
-.Procedure
-
-. Change to the namespace where your Operator is installed:
-+
-[source,terminal]
-----
-$ oc project <project_name>-system
-----
-
-. Update the sample `Memcached` CR manifest at the `config/samples/cache_v1_memcached.yaml` file by updating the `replicaCount` field to `3`:
-+
-.Example `config/samples/cache_v1_memcached.yaml` file
-[%collapsible]
-====
-[source,yaml]
-----
-apiVersion: cache.my.domain/v1
-kind: Memcached
-metadata:
-  name: memcached-sample
-spec:
-  # Default values copied from <project_dir>/helm-charts/memcached/values.yaml
-  affinity: {}
-  autoscaling:
-    enabled: false
-    maxReplicas: 100
-    minReplicas: 1
-    targetCPUUtilizationPercentage: 80
-  fullnameOverride: ""
-  image:
-    pullPolicy: IfNotPresent
-    repository: nginx
-    tag: ""
-  imagePullSecrets: []
-  ingress:
-    annotations: {}
-    className: ""
-    enabled: false
-    hosts:
-    - host: chart-example.local
-      paths:
-      - path: /
-        pathType: ImplementationSpecific
-    tls: []
-  nameOverride: ""
-  nodeSelector: {}
-  podAnnotations: {}
-  podSecurityContext: {}
-  replicaCount: 3
-  resources: {}
-  securityContext: {}
-  service:
-    port: 80
-    type: ClusterIP
-  serviceAccount:
-    annotations: {}
-    create: true
-    name: ""
-  tolerations: []
-----
-====
-
-. Create the `Memcached` CR:
-+
-[source,terminal]
-----
-$ oc apply -f config/samples/cache_v1_memcached.yaml
-----
-
-. Ensure that the Memcached Operator creates the deployment for the sample CR with the correct size:
-+
-[source,terminal]
-----
-$ oc get pods
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                  READY     STATUS    RESTARTS   AGE
-memcached-sample-6fd7c98d8-7dqdr      1/1       Running   0          18m
-memcached-sample-6fd7c98d8-g5k7v      1/1       Running   0          18m
-memcached-sample-6fd7c98d8-m7vn7      1/1       Running   0          18m
-----
-
-. Update the sample `MemcachedBackup` CR manifest at the `config/samples/cache_v1_memcachedbackup.yaml` file by updating the `size` to `2`:
-+
-.Example `config/samples/cache_v1_memcachedbackup.yaml` file
-[%collapsible]
-====
-[source,yaml]
-----
-apiVersion: cache.my.domain/v1
-kind: MemcachedBackup
-metadata:
-  name: memcachedbackup-sample
-spec:
-  size: 2
-----
-====
-
-. Create the `MemcachedBackup` CR:
-+
-[source,terminal]
-----
-$ oc apply -f config/samples/cache_v1_memcachedbackup.yaml
-----
-
-. Ensure that the count of `memcachedbackup` pods is the same as specified in the CR:
-+
-[source,terminal]
-----
-$ oc get pods
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                        READY     STATUS    RESTARTS   AGE
-memcachedbackup-sample-8649699989-4bbzg     1/1       Running   0          22m
-memcachedbackup-sample-8649699989-mq6mx     1/1       Running   0          22m
-----
-
-. You can update the `spec` in each of the above CRs, and then apply them again. The controller reconciles again and ensures that the size of the pods is as specified in the `spec` of the respective CRs.
-
-. Clean up the resources that have been created as part of this tutorial:
-
-.. Delete the `Memcached` resource:
-+
-[source,terminal]
-----
-$ oc delete -f config/samples/cache_v1_memcached.yaml
-----
-
-.. Delete the `MemcachedBackup` resource:
-+
-[source,terminal]
-----
-$ oc delete -f config/samples/cache_v1_memcachedbackup.yaml
-----
-
-.. If you used the `make deploy` command to test the Operator, run the following command:
-+
-[source,terminal]
-----
-$ make undeploy
-----
diff --git a/modules/osdk-hh-create-go-api.adoc b/modules/osdk-hh-create-go-api.adoc
deleted file mode 100644
index e09f106a62cd..000000000000
--- a/modules/osdk-hh-create-go-api.adoc
+++ /dev/null
@@ -1,36 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-hh-create-go-api_{context}"]
-= Creating a Go API
-
-Use the Operator SDK CLI to create a Go API.
-
-.Procedure
-
-. Run the following command to create a Go API with group `cache`, version `v1`, and kind `MemcachedBackup`:
-+
-[source,terminal]
-----
-$ operator-sdk create api \
-    --group=cache \
-    --version v1 \
-    --kind MemcachedBackup \
-    --resource \
-    --controller \
-    --plugins=go/v4
-----
-
-. When prompted, enter `y` for creating both resource and controller:
-+
-[source,terminal]
-----
-$ Create Resource [y/n]
-y
-Create Controller [y/n]
-y
-----
-
-This procedure generates the `MemcachedBackup` resource API at `api/v1/memcachedbackup_types.go` and the controller at `controllers/memcachedbackup_controller.go`.
diff --git a/modules/osdk-hh-create-helm-api.adoc b/modules/osdk-hh-create-helm-api.adoc
deleted file mode 100644
index 776299bbf318..000000000000
--- a/modules/osdk-hh-create-helm-api.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-hh-create-helm-api_{context}"]
-= Creating a Helm API
-
-Use the Operator SDK CLI to create a Helm API.
-
-.Procedure
-
-* Run the following command to create a Helm API with group `cache`, version `v1`, and kind `Memcached`:
-+
-[source,terminal]
-----
-$ operator-sdk create api \
-    --plugins helm.sdk.operatorframework.io/v1 \
-    --group cache \
-    --version v1 \
-    --kind Memcached
-----
-
-[NOTE]
-====
-This procedure also configures your Operator project to watch the `Memcached` resource with API version `v1` and scaffolds a boilerplate Helm chart. Instead of creating the project from the boilerplate Helm chart scaffolded by the Operator SDK, you can alternatively use an existing chart from your local file system or remote chart repository.
-
-For more details and examples for creating Helm API based on existing or new charts, run the following command:
-
-[source,terminal]
-----
-$ operator-sdk create api --plugins helm.sdk.operatorframework.io/v1 --help
-----
-====
diff --git a/modules/osdk-hh-create-project.adoc b/modules/osdk-hh-create-project.adoc
deleted file mode 100644
index d3541e2a58ea..000000000000
--- a/modules/osdk-hh-create-project.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-hh-create-project_{context}"]
-= Creating a project
-
-Use the Operator SDK CLI to create a project called `memcached-operator`.
-
-.Procedure
-
-. Create a directory for the project:
-+
-[source,terminal]
-----
-$ mkdir -p $HOME/github.com/example/memcached-operator
-----
-
-. Change to the directory:
-+
-[source,terminal]
-----
-$ cd $HOME/github.com/example/memcached-operator
-----
-
-. Run the `operator-sdk init` command to initialize the project. This example uses a domain of `my.domain` so that all API groups are `<group>.my.domain`:
-+
-[source,terminal]
-----
-$ operator-sdk init \
-    --plugins=hybrid.helm.sdk.operatorframework.io \
-    --project-version="3" \
-    --domain my.domain \
-    --repo=github.com/example/memcached-operator
-----
-+
-The `init` command generates the RBAC rules in the `config/rbac/role.yaml` file based on the resources that would be deployed by the chart's default manifests. Verify that the rules generated in the `config/rbac/role.yaml` file meet your Operator's permission requirements.
diff --git a/modules/osdk-hh-defining-go-api.adoc b/modules/osdk-hh-defining-go-api.adoc
deleted file mode 100644
index ff50be3741cb..000000000000
--- a/modules/osdk-hh-defining-go-api.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-hh-defining-go-api_{context}"]
-= Defining the API
-
-Define the API for the `MemcachedBackup` custom resource (CR).
-
-Represent this Go API by defining the `MemcachedBackup` type, which will have a `MemcachedBackupSpec.Size` field to set the quantity of Memcached backup instances (CRs) to be deployed, and a `MemcachedBackupStatus.Nodes` field to store a CR's pod names.
-
-[NOTE]
-====
-The `Node` field is used to illustrate an example of a `Status` field.
-====
-
-.Procedure
-
-. Define the API for the `MemcachedBackup` CR by modifying the Go type definitions in the `api/v1/memcachedbackup_types.go` file to have the following `spec` and `status`:
-+
-.Example `api/v1/memcachedbackup_types.go` file
-[%collapsible]
-====
-[source,golang]
-----
-// MemcachedBackupSpec defines the desired state of MemcachedBackup
-type MemcachedBackupSpec struct {
-	// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
-	// Important: Run "make" to regenerate code after modifying this file
-
-	//+kubebuilder:validation:Minimum=0
-	// Size is the size of the memcached deployment
-	Size int32 `json:"size"`
-}
-
-// MemcachedBackupStatus defines the observed state of MemcachedBackup
-type MemcachedBackupStatus struct {
-	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
-	// Important: Run "make" to regenerate code after modifying this file
-	// Nodes are the names of the memcached pods
-	Nodes []string `json:"nodes"`
-}
-----
-====
-
-. Update the generated code for the resource type:
-+
-[source,terminal]
-----
-$ make generate
-----
-+
-[TIP]
-====
-After you modify a `*_types.go` file, you must run the `make generate` command to update the generated code for that resource type.
-====
-
-. After the API is defined with `spec` and `status` fields and CRD validation markers, generate and update the CRD manifests:
-+
-[source,terminal]
-----
-$ make manifests
-----
-
-This Makefile target invokes the `controller-gen` utility to generate the CRD manifests in the `config/crd/bases/cache.my.domain_memcachedbackups.yaml` file.
diff --git a/modules/osdk-hh-helm-api-logic.adoc b/modules/osdk-hh-helm-api-logic.adoc
deleted file mode 100644
index cfa3f703b62a..000000000000
--- a/modules/osdk-hh-helm-api-logic.adoc
+++ /dev/null
@@ -1,23 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-hh-helm-api-logic_{context}"]
-= Operator logic for the Helm API
-
-By default, your scaffolded Operator project watches `Memcached` resource events as shown in the `watches.yaml` file and executes Helm releases using the specified chart.
-
-.Example `watches.yaml` file
-[%collapsible]
-====
-[source,yaml]
-----
-# Use the 'create api' subcommand to add watches to this file.
-- group: cache.my.domain
-  version: v1
-  kind: Memcached
-  chart: helm-charts/memcached
-#+kubebuilder:scaffold:watch
-----
-====
diff --git a/modules/osdk-hh-helm-reconciler.adoc b/modules/osdk-hh-helm-reconciler.adoc
deleted file mode 100644
index c637f0f15f42..000000000000
--- a/modules/osdk-hh-helm-reconciler.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-hh-helm-reconciler_{context}"]
-= Custom Helm reconciler configurations using provided library APIs
-
-A disadvantage of existing Helm-based Operators is the inability to configure the Helm reconciler, because it is abstracted from users. For a Helm-based Operator to reach the Seamless Upgrades capability (level II and later) that reuses an already existing Helm chart, a hybrid between the Go and Helm Operator types adds value.
-
-The APIs provided in the link:https://github.com/operator-framework/helm-operator-plugins[`helm-operator-plugins`] library allow Operator authors to make the following configurations:
-
-* Customize value mapping based on cluster state
-* Execute code in specific events by configuring the reconciler's event recorder
-* Customize the reconciler's logger
-* Setup `Install`, `Upgrade`, and `Uninstall` annotations to enable Helm's actions to be configured based on the annotations found in custom resources watched by the reconciler
-* Configure the reconciler to run with `Pre` and `Post` hooks
-
-The above configurations to the reconciler can be done in the `main.go` file:
-
-[%collapsible]
-====
-.Example `main.go` file
-[source,golang]
-----
-// Operator's main.go
-// With the help of helpers provided in the library, the reconciler can be
-// configured here before starting the controller with this reconciler.
-reconciler := reconciler.New(
- reconciler.WithChart(*chart),
- reconciler.WithGroupVersionKind(gvk),
-)
-
-if err := reconciler.SetupWithManager(mgr); err != nil {
- panic(fmt.Sprintf("unable to create reconciler: %s", err))
-}
-----
-====
diff --git a/modules/osdk-hh-implement-controller.adoc b/modules/osdk-hh-implement-controller.adoc
deleted file mode 100644
index e025d59757f2..000000000000
--- a/modules/osdk-hh-implement-controller.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-hh-implement-controller_{context}"]
-= Controller implementation
-
-The controller in this tutorial performs the following actions:
-
-* Create a `Memcached` deployment if it does not exist.
-* Ensure that the deployment size is the same as specified by the `Memcached` CR spec.
-* Update the `Memcached` CR status with the names of the `memcached` pods.
diff --git a/modules/osdk-hh-main-go.adoc b/modules/osdk-hh-main-go.adoc
deleted file mode 100644
index 727c0a3cb4a5..000000000000
--- a/modules/osdk-hh-main-go.adoc
+++ /dev/null
@@ -1,79 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-hh-main-go_{context}"]
-= Differences in main.go
-
-For standard Go-based Operators and the Hybrid Helm Operator, the `main.go` file handles the scaffolding the initialization and running of the link:https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Manager[`Manager`] program for the Go API. For the Hybrid Helm Operator, however, the `main.go` file also exposes the logic for loading the `watches.yaml` file and configuring the Helm reconciler.
-
-.Example `main.go` file
-[%collapsible]
-====
-[source,terminal]
-----
-...
-	for _, w := range ws {
-		// Register controller with the factory
-		reconcilePeriod := defaultReconcilePeriod
-		if w.ReconcilePeriod != nil {
-			reconcilePeriod = w.ReconcilePeriod.Duration
-		}
-
-		maxConcurrentReconciles := defaultMaxConcurrentReconciles
-		if w.MaxConcurrentReconciles != nil {
-			maxConcurrentReconciles = *w.MaxConcurrentReconciles
-		}
-
-		r, err := reconciler.New(
-			reconciler.WithChart(*w.Chart),
-			reconciler.WithGroupVersionKind(w.GroupVersionKind),
-			reconciler.WithOverrideValues(w.OverrideValues),
-			reconciler.SkipDependentWatches(w.WatchDependentResources != nil && !*w.WatchDependentResources),
-			reconciler.WithMaxConcurrentReconciles(maxConcurrentReconciles),
-			reconciler.WithReconcilePeriod(reconcilePeriod),
-			reconciler.WithInstallAnnotations(annotation.DefaultInstallAnnotations...),
-			reconciler.WithUpgradeAnnotations(annotation.DefaultUpgradeAnnotations...),
-			reconciler.WithUninstallAnnotations(annotation.DefaultUninstallAnnotations...),
-		)
-...
-----
-====
-
-The manager is initialized with both `Helm` and `Go` reconcilers:
-
-.Example `Helm` and `Go` reconcilers
-[%collapsible]
-====
-[source,terminal]
-----
-...
-// Setup manager with Go API
-   if err = (&controllers.MemcachedBackupReconciler{
-		Client: mgr.GetClient(),
-		Scheme: mgr.GetScheme(),
-	}).SetupWithManager(mgr); err != nil {
-		setupLog.Error(err, "unable to create controller", "controller", "MemcachedBackup")
-		os.Exit(1)
-	}
-
-   ...
-// Setup manager with Helm API
-	for _, w := range ws {
-
-      ...
-		if err := r.SetupWithManager(mgr); err != nil {
-			setupLog.Error(err, "unable to create controller", "controller", "Helm")
-			os.Exit(1)
-		}
-		setupLog.Info("configured watch", "gvk", w.GroupVersionKind, "chartPath", w.ChartPath, "maxConcurrentReconciles", maxConcurrentReconciles, "reconcilePeriod", reconcilePeriod)
-	}
-
-// Start the manager
-   if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
-		setupLog.Error(err, "problem running manager")
-		os.Exit(1)
-	}
-----
-====
diff --git a/modules/osdk-hh-project-layout.adoc b/modules/osdk-hh-project-layout.adoc
deleted file mode 100644
index d2b37bb865f4..000000000000
--- a/modules/osdk-hh-project-layout.adoc
+++ /dev/null
@@ -1,65 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="osdk-hh-project-layout_{context}"]
-= Project layout
-
-The Hybrid Helm Operator scaffolding is customized to be compatible with both Helm and Go APIs.
-
-[options="header",cols="1a,4a"]
-|===
-
-|File/folders |Purpose
-
-|`Dockerfile`
-|Instructions used by a container engine to build your Operator image with the `make docker-build` command.
-
-|`Makefile`
-|Build file with helper targets to help you work with your project.
-
-|`PROJECT`
-|YAML file containing metadata information for the Operator. Represents the project's configuration and is used to track useful information for the CLI and plugins.
-
-|`bin/`
-|Contains useful binaries such as the `manager` which is used to run your project locally and  the `kustomize` utility used for the project configuration.
-
-|`config/`
-|Contains configuration files, including all link:https://kustomize.io/[Kustomize] manifests, to launch your Operator project on a cluster. Plugins might use it to provide functionality. For example, for the Operator SDK to help create your Operator bundle, the CLI looks up the CRDs and CRs which are scaffolded in this directory.
-
-`config/crd/`:: Contains custom resource definitions (CRDs).
-
-`config/default/`:: Contains a Kustomize base for launching the controller in a standard configuration.
-
-`config/manager/`:: Contains the manifests to launch your Operator project as pods on the cluster.
-
-`config/manifests/`:: Contains the base to generate your OLM manifests in the `bundle/` directory.
-
-`config/prometheus/`:: Contains the manifests required to enable project to serve metrics to Prometheus such as the `ServiceMonitor` resource.
-
-`config/scorecard/`:: Contains the manifests required to allow you test your project with the scorecard tool.
-
-`config/rbac/`:: Contains the RBAC permissions required to run your project.
-
-`config/samples/`:: Contains samples for custom resources.
-
-|`api/`
-|Contains the Go API definition.
-
-|`internal/controllers/`
-|Contains the controllers for the Go API.
-
-|`hack/`
-|Contains utility files, such as the file used to scaffold the license header for your project files.
-
-|`main.go`
-|Main program of the Operator. Instantiates a new manager that registers all custom resource definitions (CRDs) in the `apis/` directory and starts all controllers in the `controllers/` directory.
-
-|`helm-charts/`
-|Contains the Helm charts which can be specified using the `create api` command with the Helm plugin.
-
-|`watches.yaml`
-|Contains group/version/kind (GVK) and Helm chart location. Used to configure the Helm watches.
-
-|===
diff --git a/modules/osdk-hh-rbac.adoc b/modules/osdk-hh-rbac.adoc
deleted file mode 100644
index 8fa72d125914..000000000000
--- a/modules/osdk-hh-rbac.adoc
+++ /dev/null
@@ -1,132 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-hh-rbac_{context}"]
-= Permissions and RBAC manifests
-
-The controller requires certain role-based access control (RBAC) permissions to interact with the resources it manages. For the Go API, these are specified with RBAC markers, as shown in the Operator SDK tutorial for standard Go-based Operators.
-
-For the Helm API, the permissions are scaffolded by default in `roles.yaml`. Currently, however, due to a known issue when the Go API is scaffolded, the permissions for the Helm API are overwritten. As a result of this issue, ensure that the permissions defined in `roles.yaml` match your requirements.
-
-[NOTE]
-====
-This known issue is being tracked in link:https://github.com/operator-framework/helm-operator-plugins/issues/142[].
-====
-
-The following is an example `role.yaml` for a Memcached Operator:
-
-.Example `Helm` and `Go` reconcilers
-[%collapsible]
-====
-[source,yaml]
-----
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: manager-role
-rules:
-- apiGroups:
-  - ""
-  resources:
-  - namespaces
-  verbs:
-  - get
-- apiGroups:
-  - apps
-  resources:
-  - deployments
-  - daemonsets
-  - replicasets
-  - statefulsets
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - cache.my.domain
-  resources:
-  - memcachedbackups
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - cache.my.domain
-  resources:
-  - memcachedbackups/finalizers
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - ""
-  resources:
-  - pods
-  - services
-  - services/finalizers
-  - endpoints
-  - persistentvolumeclaims
-  - events
-  - configmaps
-  - secrets
-  - serviceaccounts
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - cache.my.domain
-  resources:
-  - memcachedbackups/status
-  verbs:
-  - get
-  - patch
-  - update
-- apiGroups:
-  - policy
-  resources:
-  - events
-  - poddisruptionbudgets
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - cache.my.domain
-  resources:
-  - memcacheds
-  - memcacheds/status
-  - memcacheds/finalizers
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-----
-====
diff --git a/modules/osdk-java-controller-labels-memcached.adoc b/modules/osdk-java-controller-labels-memcached.adoc
deleted file mode 100644
index 2ee93a21ed73..000000000000
--- a/modules/osdk-java-controller-labels-memcached.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-java-controller-labels-memcached_{context}"]
-= Defining `labelsForMemcached`
-
-`labelsForMemcached` is a utility to return a map of the labels to attach to the resources:
-
-[source,java]
-----
-    private Map<String, String> labelsForMemcached(Memcached m) {
-        Map<String, String> labels = new HashMap<>();
-        labels.put("app", "memcached");
-        labels.put("memcached_cr", m.getMetadata().getName());
-        return labels;
-    }
-----
\ No newline at end of file
diff --git a/modules/osdk-java-controller-memcached-deployment.adoc b/modules/osdk-java-controller-memcached-deployment.adoc
deleted file mode 100644
index 6f673b16e57f..000000000000
--- a/modules/osdk-java-controller-memcached-deployment.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-java-controller-memcached-deployment_{context}"]
-=  Define the `createMemcachedDeployment`
-
-The `createMemcachedDeployment` method uses the link:https://fabric8.io/[fabric8] `DeploymentBuilder` class:
-
-[source,java]
-----
-    private Deployment createMemcachedDeployment(Memcached m) {
-        Deployment deployment = new DeploymentBuilder()
-            .withMetadata(
-                new ObjectMetaBuilder()
-                    .withName(m.getMetadata().getName())
-                    .withNamespace(m.getMetadata().getNamespace())
-                    .build())
-            .withSpec(
-                new DeploymentSpecBuilder()
-                    .withReplicas(m.getSpec().getSize())
-                    .withSelector(
-                        new LabelSelectorBuilder().withMatchLabels(labelsForMemcached(m)).build())
-                    .withTemplate(
-                        new PodTemplateSpecBuilder()
-                            .withMetadata(
-                                new ObjectMetaBuilder().withLabels(labelsForMemcached(m)).build())
-                            .withSpec(
-                                new PodSpecBuilder()
-                                    .withContainers(
-                                        new ContainerBuilder()
-                                            .withImage("memcached:1.4.36-alpine")
-                                            .withName("memcached")
-                                            .withCommand("memcached", "-m=64", "-o", "modern", "-v")
-                                            .withPorts(
-                                                new ContainerPortBuilder()
-                                                    .withContainerPort(11211)
-                                                    .withName("memcached")
-                                                    .build())
-                                            .build())
-                                    .build())
-                            .build())
-                    .build())
-            .build();
-      deployment.addOwnerReference(m);
-      return deployment;
-    }
-----
\ No newline at end of file
diff --git a/modules/osdk-java-controller-reconcile-loop.adoc b/modules/osdk-java-controller-reconcile-loop.adoc
deleted file mode 100644
index ef4a8f5a4532..000000000000
--- a/modules/osdk-java-controller-reconcile-loop.adoc
+++ /dev/null
@@ -1,74 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="osdk-java-controller-reconcile-loop_{context}"]
-= Reconcile loop
-
-. Every controller has a reconciler object with a `Reconcile()` method that implements the reconcile loop. The reconcile loop is passed the `Deployment` argument, as shown in the following example:
-+
-[source,java]
-----
-        Deployment deployment = client.apps()
-                .deployments()
-                .inNamespace(resource.getMetadata().getNamespace())
-                .withName(resource.getMetadata().getName())
-                .get();
-----
-
-. As shown in the following example, if the `Deployment` is `null`, the deployment needs to be created. After you create the `Deployment`, you can determine if reconciliation is necessary. If there is no need of reconciliation, return the value of `UpdateControl.noUpdate()`, otherwise, return the value of `UpdateControl.updateStatus(resource):
-+
-[source, java]
-----
-        if (deployment == null) {
-            Deployment newDeployment = createMemcachedDeployment(resource);
-            client.apps().deployments().create(newDeployment);
-            return UpdateControl.noUpdate();
-        }
-----
-
-. After getting the `Deployment`, get the current and required replicas, as shown in the following example:
-+
-[source,java]
-----
-        int currentReplicas = deployment.getSpec().getReplicas();
-        int requiredReplicas = resource.getSpec().getSize();
-----
-
-. If `currentReplicas` does not match the `requiredReplicas`, you must update the `Deployment`, as shown in the following example:
-+
-[source,java]
-----
-        if (currentReplicas != requiredReplicas) {
-            deployment.getSpec().setReplicas(requiredReplicas);
-            client.apps().deployments().createOrReplace(deployment);
-            return UpdateControl.noUpdate();
-        }
-----
-
-. The following example shows how to obtain the list of pods and their names:
-+
-[source,java]
-----
-        List<Pod> pods = client.pods()
-            .inNamespace(resource.getMetadata().getNamespace())
-            .withLabels(labelsForMemcached(resource))
-            .list()
-            .getItems();
-
-        List<String> podNames =
-            pods.stream().map(p -> p.getMetadata().getName()).collect(Collectors.toList());
-----
-
-. Check if resources were created and verify podnames with the Memcached resources. If a mismatch exists in either of these conditions, perform a reconciliation as shown in the following example:
-+
-[source,java]
-----
-        if (resource.getStatus() == null
-                || !CollectionUtils.isEqualCollection(podNames, resource.getStatus().getNodes())) {
-            if (resource.getStatus() == null) resource.setStatus(new MemcachedStatus());
-            resource.getStatus().setNodes(podNames);
-            return UpdateControl.updateResource(resource);
-        }
-----
\ No newline at end of file
diff --git a/modules/osdk-java-create-api-controller.adoc b/modules/osdk-java-create-api-controller.adoc
deleted file mode 100644
index 0625932185b8..000000000000
--- a/modules/osdk-java-create-api-controller.adoc
+++ /dev/null
@@ -1,57 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-java-create-api-controller_{context}"]
-= Creating an API and controller
-
-Use the Operator SDK CLI to create a custom resource definition (CRD) API and controller.
-
-.Procedure
-
-. Run the following command to create an API:
-+
-[source,terminal]
-----
-$ operator-sdk create api \
-    --plugins=quarkus \// <1>
-    --group=cache \// <2>
-    --version=v1 \// <3>
-    --kind=Memcached <4>
-----
-<1> Set the plugin flag to `quarkus`.
-<2> Set the group flag to `cache`.
-<3> Set the version flag to `v1`.
-<4> Set the kind flag to `Memcached`.
-
-.Verification
-
-. Run the `tree` command to view the file structure:
-+
-[source,terminal]
-----
-$ tree
-----
-+
-.Example output
-[source,terminal]
-----
-.
-├── Makefile
-├── PROJECT
-├── pom.xml
-└── src
-    └── main
-        ├── java
-        │   └── com
-        │       └── example
-        │           ├── Memcached.java
-        │           ├── MemcachedReconciler.java
-        │           ├── MemcachedSpec.java
-        │           └── MemcachedStatus.java
-        └── resources
-            └── application.properties
-
-6 directories, 8 files
-----
diff --git a/modules/osdk-java-create-cr.adoc b/modules/osdk-java-create-cr.adoc
deleted file mode 100644
index 046050f1812f..000000000000
--- a/modules/osdk-java-create-cr.adoc
+++ /dev/null
@@ -1,23 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-java-create-cr_{context}"]
-= Creating a Custom Resource
-
-After generating the CRD manifests, you can create the Custom Resource (CR).
-
-.Procedure
-* Create a Memcached CR called `memcached-sample.yaml`:
-+
-[source,yaml]
-----
-apiVersion: cache.example.com/v1
-kind: Memcached
-metadata:
-  name: memcached-sample
-spec:
-  # Add spec fields here
-  size: 1
-----
\ No newline at end of file
diff --git a/modules/osdk-java-define-api.adoc b/modules/osdk-java-define-api.adoc
deleted file mode 100644
index 5392b6e6489b..000000000000
--- a/modules/osdk-java-define-api.adoc
+++ /dev/null
@@ -1,70 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-java-define-api_{context}"]
-= Defining the API
-
-Define the API for the `Memcached` custom resource (CR).
-
-.Procedure
-* Edit the following files that were generated as part of the `create api` process:
-
-.. Update the following attributes in the `MemcachedSpec.java` file to define the desired state of the `Memcached` CR:
-+
-[source,java]
-----
-public class MemcachedSpec {
-
-    private Integer size;
-
-    public Integer getSize() {
-        return size;
-    }
-
-    public void setSize(Integer size) {
-        this.size = size;
-    }
-}
-----
-
-.. Update the following attributes in the `MemcachedStatus.java` file to define the observed state of the `Memcached` CR:
-+
-[NOTE]
-====
-The example below illustrates a Node status field. It is recommended that you use link:https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties[typical status properties] in practice.
-====
-+
-[source,java]
-----
-import java.util.ArrayList;
-import java.util.List;
-
-public class MemcachedStatus {
-
-    // Add Status information here
-    // Nodes are the names of the memcached pods
-    private List<String> nodes;
-
-    public List<String> getNodes() {
-        if (nodes == null) {
-            nodes = new ArrayList<>();
-        }
-        return nodes;
-    }
-
-    public void setNodes(List<String> nodes) {
-        this.nodes = nodes;
-    }
-}
-----
-
-.. Update the `Memcached.java` file to define the Schema for Memcached APIs that extends to both `MemcachedSpec.java` and `MemcachedStatus.java` files.
-+
-[source,java]
-----
-@Version("v1")
-@Group("cache.example.com")
-public class Memcached extends CustomResource<MemcachedSpec, MemcachedStatus> implements Namespaced {}
-----
\ No newline at end of file
diff --git a/modules/osdk-java-generate-crd.adoc b/modules/osdk-java-generate-crd.adoc
deleted file mode 100644
index 7ae177353f58..000000000000
--- a/modules/osdk-java-generate-crd.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-java-generate-crd_{context}"]
-= Generating CRD manifests
-
-After the API is defined with `MemcachedSpec` and `MemcachedStatus` files, you can generate CRD manifests.
-
-.Procedure
-
-* Run the following command from the `memcached-operator` directory to generate the CRD:
-+
-[source,terminal]
-----
-$ mvn clean install
-----
-
-.Verification
-
-* Verify the contents of the CRD in the `target/kubernetes/memcacheds.cache.example.com-v1.yml` file as shown in the following example:
-+
-[source,terminal]
-----
-$ cat target/kubernetes/memcacheds.cache.example.com-v1.yaml
-----
-+
-.Example output
-[source,yaml]
-----
-# Generated by Fabric8 CRDGenerator, manual edits might get overwritten!
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
-  name: memcacheds.cache.example.com
-spec:
-  group: cache.example.com
-  names:
-    kind: Memcached
-    plural: memcacheds
-    singular: memcached
-  scope: Namespaced
-  versions:
-  - name: v1
-    schema:
-      openAPIV3Schema:
-        properties:
-          spec:
-            properties:
-              size:
-                type: integer
-            type: object
-          status:
-            properties:
-              nodes:
-                items:
-                  type: string
-                type: array
-            type: object
-        type: object
-    served: true
-    storage: true
-    subresources:
-      status: {}
-----
\ No newline at end of file
diff --git a/modules/osdk-java-implement-controller.adoc b/modules/osdk-java-implement-controller.adoc
deleted file mode 100644
index be612051ec6a..000000000000
--- a/modules/osdk-java-implement-controller.adoc
+++ /dev/null
@@ -1,161 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-
-:_mod-docs-content-type: PROCEDURE
-[id="osdk-java-implement-controller_{context}"]
-= Implementing the controller
-
-After creating a new API and controller, you can implement the controller logic.
-
-.Procedure
-
-. Append the following dependency to the `pom.xml` file:
-+
-[source,xml]
-----
-    <dependency>
-      <groupId>commons-collections</groupId>
-      <artifactId>commons-collections</artifactId>
-      <version>3.2.2</version>
-    </dependency>
-----
-
-. For this example, replace the generated controller file `MemcachedReconciler.java` with following example implementation:
-+
-.Example `MemcachedReconciler.java`
-[%collapsible]
-====
-[source,java]
-----
-package com.example;
-
-import io.fabric8.kubernetes.client.KubernetesClient;
-import io.javaoperatorsdk.operator.api.reconciler.Context;
-import io.javaoperatorsdk.operator.api.reconciler.Reconciler;
-import io.javaoperatorsdk.operator.api.reconciler.UpdateControl;
-import io.fabric8.kubernetes.api.model.ContainerBuilder;
-import io.fabric8.kubernetes.api.model.ContainerPortBuilder;
-import io.fabric8.kubernetes.api.model.LabelSelectorBuilder;
-import io.fabric8.kubernetes.api.model.ObjectMetaBuilder;
-import io.fabric8.kubernetes.api.model.OwnerReferenceBuilder;
-import io.fabric8.kubernetes.api.model.Pod;
-import io.fabric8.kubernetes.api.model.PodSpecBuilder;
-import io.fabric8.kubernetes.api.model.PodTemplateSpecBuilder;
-import io.fabric8.kubernetes.api.model.apps.Deployment;
-import io.fabric8.kubernetes.api.model.apps.DeploymentBuilder;
-import io.fabric8.kubernetes.api.model.apps.DeploymentSpecBuilder;
-import org.apache.commons.collections.CollectionUtils;
-import java.util.HashMap;
-import java.util.List;
-import java.util.Map;
-import java.util.stream.Collectors;
-
-public class MemcachedReconciler implements Reconciler<Memcached> {
-  private final KubernetesClient client;
-
-  public MemcachedReconciler(KubernetesClient client) {
-    this.client = client;
-  }
-
-  // TODO Fill in the rest of the reconciler
-
-  @Override
-  public UpdateControl<Memcached> reconcile(
-      Memcached resource, Context context) {
-      // TODO: fill in logic
-      Deployment deployment = client.apps()
-              .deployments()
-              .inNamespace(resource.getMetadata().getNamespace())
-              .withName(resource.getMetadata().getName())
-              .get();
-
-      if (deployment == null) {
-          Deployment newDeployment = createMemcachedDeployment(resource);
-          client.apps().deployments().create(newDeployment);
-          return UpdateControl.noUpdate();
-      }
-
-      int currentReplicas = deployment.getSpec().getReplicas();
-      int requiredReplicas = resource.getSpec().getSize();
-
-      if (currentReplicas != requiredReplicas) {
-          deployment.getSpec().setReplicas(requiredReplicas);
-          client.apps().deployments().createOrReplace(deployment);
-          return UpdateControl.noUpdate();
-      }
-
-      List<Pod> pods = client.pods()
-          .inNamespace(resource.getMetadata().getNamespace())
-          .withLabels(labelsForMemcached(resource))
-          .list()
-          .getItems();
-
-      List<String> podNames =
-          pods.stream().map(p -> p.getMetadata().getName()).collect(Collectors.toList());
-
-
-      if (resource.getStatus() == null
-               || !CollectionUtils.isEqualCollection(podNames, resource.getStatus().getNodes())) {
-           if (resource.getStatus() == null) resource.setStatus(new MemcachedStatus());
-           resource.getStatus().setNodes(podNames);
-           return UpdateControl.updateResource(resource);
-      }
-
-      return UpdateControl.noUpdate();
-  }
-
-  private Map<String, String> labelsForMemcached(Memcached m) {
-    Map<String, String> labels = new HashMap<>();
-    labels.put("app", "memcached");
-    labels.put("memcached_cr", m.getMetadata().getName());
-    return labels;
-  }
-
-  private Deployment createMemcachedDeployment(Memcached m) {
-      Deployment deployment = new DeploymentBuilder()
-          .withMetadata(
-              new ObjectMetaBuilder()
-                  .withName(m.getMetadata().getName())
-                  .withNamespace(m.getMetadata().getNamespace())
-                  .build())
-          .withSpec(
-              new DeploymentSpecBuilder()
-                  .withReplicas(m.getSpec().getSize())
-                  .withSelector(
-                      new LabelSelectorBuilder().withMatchLabels(labelsForMemcached(m)).build())
-                  .withTemplate(
-                      new PodTemplateSpecBuilder()
-                          .withMetadata(
-                              new ObjectMetaBuilder().withLabels(labelsForMemcached(m)).build())
-                          .withSpec(
-                              new PodSpecBuilder()
-                                  .withContainers(
-                                      new ContainerBuilder()
-                                          .withImage("memcached:1.4.36-alpine")
-                                          .withName("memcached")
-                                          .withCommand("memcached", "-m=64", "-o", "modern", "-v")
-                                          .withPorts(
-                                              new ContainerPortBuilder()
-                                                  .withContainerPort(11211)
-                                                  .withName("memcached")
-                                                  .build())
-                                          .build())
-                                  .build())
-                          .build())
-                  .build())
-          .build();
-    deployment.addOwnerReference(m);
-    return deployment;
-  }
-}
-----
-====
-+
-The example controller runs the following reconciliation logic for each `Memcached` custom resource (CR):
-+
---
-* Creates a Memcached deployment if it does not exist.
-* Ensures that the deployment size matches the size specified by the `Memcached` CR spec.
-* Updates the `Memcached` CR status with the names of the `memcached` pods.
---
diff --git a/modules/osdk-java-project-layout.adoc b/modules/osdk-java-project-layout.adoc
deleted file mode 100644
index 44d25728830a..000000000000
--- a/modules/osdk-java-project-layout.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-// Module included in the following assemblies:
-//
-// * operators/operator_sdk/java/osdk-java-project-layout.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="osdk-java-project-layout_{context}"]
-= Java-based project layout
-
-Java-based Operator projects generated by the `operator-sdk init` command contain the following files and directories:
-
-[options="header",cols="1,4"]
-|===
-
-|File or directory |Purpose
-
-|`pom.xml`
-|File that contains the dependencies required to run the Operator.
-
-|`<domain>/`
-|Directory that contains the files that represent the API. If the domain is `example.com`, this folder is called `example/`.
-
-|`MemcachedReconciler.java`
-|Java file that defines controller implementations.
-
-|`MemcachedSpec.java`
-|Java file that defines the desired state of the Memcached CR.
-
-|`MemcachedStatus.java`
-|Java file that defines the observed state of the Memcached CR.
-
-|`Memcached.java`
-|Java file that defines the Schema for Memcached APIs.
-
-|`target/kubernetes/`
-|Directory that contains the CRD yaml files.
-
-|===
diff --git a/modules/osdk-project-file.adoc b/modules/osdk-project-file.adoc
index 5239f3abe1a7..8f0f27d51877 100644
--- a/modules/osdk-project-file.adoc
+++ b/modules/osdk-project-file.adoc
@@ -3,7 +3,6 @@
 // * operators/operator_sdk/golang/osdk-golang-tutorial.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
 // * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
 
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :golang:
@@ -20,11 +19,6 @@ ifeval::["{context}" == "osdk-helm-tutorial"]
 :type: Helm
 :app: nginx
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-:type: Java
-:app: memcached
-endif::[]
 
 [id="osdk-project-file_{context}"]
 = PROJECT file
@@ -80,15 +74,6 @@ resources:
 version: "3"
 ----
 endif::[]
-ifdef::java[]
-----
-domain: example.com
-layout:
-- quarkus.javaoperatorsdk.io/v1-alpha
-projectName: memcached-operator
-version: "3"
-----
-endif::[]
 
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :!golang:
@@ -104,9 +89,4 @@ ifeval::["{context}" == "osdk-helm-tutorial"]
 :!helm:
 :!type:
 :!app:
-endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-:!type:
-:!app:
 endif::[]
\ No newline at end of file
diff --git a/modules/osdk-quickstart.adoc b/modules/osdk-quickstart.adoc
index 93fe1712cd93..d0df298e44d9 100644
--- a/modules/osdk-quickstart.adoc
+++ b/modules/osdk-quickstart.adoc
@@ -25,13 +25,6 @@ ifeval::["{context}" == "osdk-helm-quickstart"]
 :app: nginx
 :group: demo
 endif::[]
-ifeval::["{context}" == "osdk-java-quickstart"]
-:java:
-:type: Java
-:app-proper: Memcached
-:app: memcached
-:group: cache
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-quickstart_{context}"]
@@ -64,9 +57,6 @@ endif::[]
 ifdef::helm[]
 with the `helm` plugin
 endif::[]
-ifdef::java[]
-with the `quarkus` plugin
-endif::[]
 to initialize the project:
 +
 [source,terminal,subs="attributes+"]
@@ -92,14 +82,6 @@ $ operator-sdk init \
     --plugins=helm
 ----
 endif::[]
-ifdef::java[]
-----
-$ operator-sdk init \
-    --plugins=quarkus \
-    --domain=example.com \
-    --project-name=memcached-operator
-----
-endif::[]
 
 . *Create an API.*
 +
@@ -136,15 +118,6 @@ $ operator-sdk create api \
 +
 This API uses the built-in Helm chart boilerplate from the `helm create` command.
 endif::[]
-ifdef::java[]
-----
-$ operator-sdk create api \
-    --plugins quarkus \
-    --group {group} \
-    --version v1 \
-    --kind {app-proper}
-----
-endif::[]
 
 . *Build and push the Operator image.*
 +
@@ -251,9 +224,3 @@ ifeval::["{context}" == "osdk-helm-quickstart"]
 :!app-proper:
 :!app:
 endif::[]
-ifeval::["{context}" == "osdk-java-quickstart"]
-:!java:
-:!type:
-:!app-proper:
-:!app:
-endif::[]
diff --git a/modules/osdk-run-deployment.adoc b/modules/osdk-run-deployment.adoc
index 655b5d4c9327..a3585d25da5b 100644
--- a/modules/osdk-run-deployment.adoc
+++ b/modules/osdk-run-deployment.adoc
@@ -8,9 +8,6 @@
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :golang:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-run-deployment_{context}"]
@@ -59,67 +56,17 @@ $ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
 The name and tag of the image, for example `IMG=<registry>/<user>/<image_name>:<tag>`, in both the commands can also be set in your Makefile. Modify the `IMG ?= controller:latest` value to set your default image name.
 ====
 
-ifdef::java[]
-. Run the following command to install the CRD to the default namespace:
-+
-[source,terminal]
-----
-$ oc apply -f target/kubernetes/memcacheds.cache.example.com-v1.yml
-----
-+
-.Example output
-[source,terminal]
-----
-customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
-----
-
-. Create a file called `rbac.yaml` as shown in the following example:
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: memcached-operator-admin
-subjects:
-- kind: ServiceAccount
-  name: memcached-quarkus-operator-operator
-  namespace: <operator_namespace>
-roleRef:
-  kind: ClusterRole
-  name: cluster-admin
-  apiGroup: ""
-----
-+
-[IMPORTANT]
-====
-The `rbac.yaml` file will be applied at a later step.
-====
-
-endif::[]
-
 . Run the following command to deploy the Operator:
 +
 [source,terminal]
 ----
 $ make deploy IMG=<registry>/<user>/<image_name>:<tag>
 ----
-ifeval::["{context}" != "osdk-java-tutorial"]
 +
 By default, this command creates a namespace with the name of your Operator project in the form `<project_name>-system` and is used for the deployment. This command also installs the RBAC manifests from `config/rbac`.
-endif::[]
 
-ifdef::java[]
-. Run the following command to grant `cluster-admin` privileges to the `memcached-quarkus-operator-operator` by applying the `rbac.yaml` file created in a previous step:
-+
-[source,terminal]
-----
-$ oc apply -f rbac.yaml
-----
-endif::[]
 . Run the following command to verify that the Operator is running:
 +
-ifeval::["{context}" != "osdk-java-tutorial"]
 [source,terminal]
 ----
 $ oc get deployment -n <project_name>-system
@@ -131,53 +78,7 @@ $ oc get deployment -n <project_name>-system
 NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
 <project_name>-controller-manager       1/1     1            1           8m
 ----
-endif::[]
-ifdef::java[]
-[source,terminal]
-----
-$ oc get all -n default
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                                      READY   UP-TO-DATE   AVAILABLE   AGE
-pod/memcached-quarkus-operator-operator-7db86ccf58-k4mlm   0/1       Running   0           18s
-----
-
-. Run the following command to apply the `memcached-sample.yaml` and create the `memcached-sample` pod:
-+
-[source,terminal]
-----
-$ oc apply -f memcached-sample.yaml
-----
-+
-.Example output
-[source,terminal]
-----
-memcached.cache.example.com/memcached-sample created
-----
 
-.Verification
-
-* Run the following command to confirm the pods have started:
-+
-[source,terminal]
-----
-$ oc get all
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                                       READY   STATUS    RESTARTS   AGE
-pod/memcached-quarkus-operator-operator-7b766f4896-kxnzt   1/1     Running   1          79s
-pod/memcached-sample-6c765df685-mfqnz                      1/1     Running   0          18s
-----
-endif::[]
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :!golang:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-endif::[]
diff --git a/modules/osdk-run-locally.adoc b/modules/osdk-run-locally.adoc
index fb0d38d13a10..db45a25e710a 100644
--- a/modules/osdk-run-locally.adoc
+++ b/modules/osdk-run-locally.adoc
@@ -13,9 +13,6 @@ endif::[]
 ifeval::["{context}" == "osdk-helm-tutorial"]
 :helm:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-endif::[]
 
 
 :_mod-docs-content-type: PROCEDURE
@@ -25,7 +22,7 @@ endif::[]
 You can run your Operator project as a Go program outside of the cluster. This is useful for development purposes to speed up deployment and testing.
 
 .Procedure
-ifeval::["{context}" != "osdk-java-tutorial"]
+
 * Run the following command to install the custom resource definitions (CRDs) in the cluster configured in your `~/.kube/config` file and run the Operator locally:
 +
 [source,terminal]
@@ -35,7 +32,6 @@ $ make install run
 +
 .Example output
 [source,terminal]
-endif::[]
 ifdef::golang[]
 ----
 ...
@@ -69,104 +65,7 @@ ifdef::helm[]
 {"level":"info","ts":1612652420.2309358,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting workers","worker count":8}
 ----
 endif::[]
-ifdef::java[]
-. Run the following command to compile the Operator:
-+
-[source,terminal]
-----
-$ mvn clean install
-----
-+
-.Example output
-[source,terminal]
-----
-[INFO] ------------------------------------------------------------------------
-[INFO] BUILD SUCCESS
-[INFO] ------------------------------------------------------------------------
-[INFO] Total time:  11.193 s
-[INFO] Finished at: 2021-05-26T12:16:54-04:00
-[INFO] ------------------------------------------------------------------------
-----
-
-. Run the following command to install the CRD to the default namespace:
-+
-[source,terminal]
-----
-$ oc apply -f target/kubernetes/memcacheds.cache.example.com-v1.yml
-----
-+
-.Example output
-[source,terminal]
-----
-customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
-----
-
-. Create a file called `rbac.yaml` as shown in the following example:
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: memcached-operator-admin
-subjects:
-- kind: ServiceAccount
-  name: memcached-quarkus-operator-operator
-  namespace: <operator_namespace>
-roleRef:
-  kind: ClusterRole
-  name: cluster-admin
-  apiGroup: ""
-----
-
-. Run the following command to grant `cluster-admin` privileges to the `memcached-quarkus-operator-operator` by applying the `rbac.yaml` file:
-+
-[source,terminal]
-----
-$ oc apply -f rbac.yaml
-----
-
-. Enter the following command to run the Operator:
-+
-[source,terminal]
-----
-$ java -jar target/quarkus-app/quarkus-run.jar
-----
-+
-[NOTE]
-====
-The `java` command will run the Operator and remain running until you end the process. You will need another terminal to complete the rest of these commands.
-====
-
-. Apply the `memcached-sample.yaml` file with the following command:
-+
-[source,terminal]
-----
-$ kubectl apply -f memcached-sample.yaml
-----
-+
-.Example output
-[source,terminal]
-----
-memcached.cache.example.com/memcached-sample created
-----
 
-.Verification
-
-* Run the following command to confirm that the pod has started:
-+
-[source,terminal]
-----
-$ oc get all
-----
-+
-.Example output
-[source,terminal]
-----
-NAME                                                       READY   STATUS    RESTARTS   AGE
-pod/memcached-sample-6c765df685-mfqnz                      1/1     Running   0          18s
-----
-endif::[]
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :!golang:
 endif::[]
@@ -175,7 +74,4 @@ ifeval::["{context}" == "osdk-ansible-tutorial"]
 endif::[]
 ifeval::["{context}" == "osdk-helm-tutorial"]
 :!helm:
-endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-endif::[]
+endif::[]
\ No newline at end of file
diff --git a/modules/osdk-run-operator.adoc b/modules/osdk-run-operator.adoc
index d3e029d5937d..c18c25ce2960 100644
--- a/modules/osdk-run-operator.adoc
+++ b/modules/osdk-run-operator.adoc
@@ -3,7 +3,6 @@
 // * operators/operator_sdk/golang/osdk-golang-tutorial.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
 // * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
 
 ifeval::["{context}" == "osdk-golang-tutorial"]
 :golang:
@@ -14,9 +13,6 @@ endif::[]
 ifeval::["{context}" == "osdk-helm-tutorial"]
 :helm:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:java:
-endif::[]
 
 [id="osdk-run-operator_{context}"]
 = Running the Operator
@@ -68,6 +64,3 @@ endif::[]
 ifeval::["{context}" == "osdk-helm-tutorial"]
 :!helm:
 endif::[]
-ifeval::["{context}" == "osdk-java-tutorial"]
-:!java:
-endif::[]
diff --git a/modules/osdk-updating-128-to-131.adoc b/modules/osdk-updating-128-to-131.adoc
index c70c2c939a5a..a599893acc4d 100644
--- a/modules/osdk-updating-128-to-131.adoc
+++ b/modules/osdk-updating-128-to-131.adoc
@@ -3,8 +3,6 @@
 // * operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
 // * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
-// * operators/operator_sdk/java/osdk-java-updating-projects.adoc
 
 ifeval::["{context}" == "osdk-golang-updating-projects"]
 :golang:
@@ -18,14 +16,6 @@ ifeval::["{context}" == "osdk-helm-updating-projects"]
 :helm:
 :type: Helm
 endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:hybrid:
-:type: Hybrid Helm
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:java:
-:type: Java
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-upgrading-projects_{context}"]
@@ -40,7 +30,7 @@ The following procedure updates an existing {type}-based Operator project for co
 
 .Procedure
 
-ifdef::golang,hybrid,java[]
+ifdef::golang[]
 * Edit your Operator project's Makefile to update the Operator SDK version to {osdk_ver}, as shown in the following example:
 +
 .Example Makefile
@@ -211,11 +201,3 @@ ifeval::["{context}" == "osdk-helm-updating-projects"]
 :!helm:
 :!type:
 endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:!hybrid:
-:!type:
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:!java:
-:!type:
-endif::[]
diff --git a/modules/osdk-updating-131-to-1361.adoc b/modules/osdk-updating-131-to-1361.adoc
index 11884cfbbe69..5d0bafb61a3a 100644
--- a/modules/osdk-updating-131-to-1361.adoc
+++ b/modules/osdk-updating-131-to-1361.adoc
@@ -3,8 +3,6 @@
 // * operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
 // * operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
 // * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
-// * operators/operator_sdk/java/osdk-java-updating-projects.adoc
 
 ifeval::["{context}" == "osdk-golang-updating-projects"]
 :golang:
@@ -18,14 +16,6 @@ ifeval::["{context}" == "osdk-helm-updating-projects"]
 :helm:
 :type: Helm
 endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:hybrid:
-:type: Hybrid Helm
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:java:
-:type: Java
-endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="osdk-upgrading-projects_{context}"]
@@ -70,7 +60,7 @@ ifdef::ansible[]
 FROM registry.redhat.io/openshift4/ose-ansible-operator:v{product-version}
 ----
 endif::[]
-ifdef::golang,hybrid[]
+ifdef::golang[]
 . The `go/v4` plugin is now stable and is the default version used when scaffolding a Go-based Operator. The transition from Golang v2 and v3 plugins to the new Golang v4 plugin introduces significant changes. This migration is designed to enhance your project's functionality and compatibility, reflecting the evolving landscape of Golang development.
 +
 For more information on the reasoning behind these changes, see link:https://book.kubebuilder.io/migration/v3vsv4#tldr-of-the-new-gov4-plugin[go/v3 vs go/v4] in the Kubebuilder documentation.
@@ -117,7 +107,7 @@ sigs.k8s.io/controller-runtime v0.17.3
 $ go mod tidy
 ----
 
-ifdef::golang,hybrid[]
+ifdef::golang[]
 .. Projects are now scaffolded with `kube-rbac-proxy` version `0.16.0`. Modify the version of `kube-rbac-proxy` in the scaffolded `config/default/manager_auth_proxy_patch.yaml` file by making the following changes:
 +
 [source,diff]
@@ -268,11 +258,3 @@ ifeval::["{context}" == "osdk-helm-updating-projects"]
 :!helm:
 :!type:
 endif::[]
-ifeval::["{context}" == "osdk-hybrid-helm-updating-projects"]
-:!hybrid:
-:!type:
-endif::[]
-ifeval::["{context}" == "osdk-java-updating-projects"]
-:!java:
-:!type:
-endif::[]
diff --git a/modules/osdk-updating-1361-to-138.adoc b/modules/osdk-updating-1361-to-138.adoc
new file mode 100644
index 000000000000..ea31057a34af
--- /dev/null
+++ b/modules/osdk-updating-1361-to-138.adoc
@@ -0,0 +1,419 @@
+// Module included in the following assemblies:
+//
+// * operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
+// * operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
+// * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
+
+ifeval::["{context}" == "osdk-golang-updating-projects"]
+:golang:
+:type: Go
+endif::[]
+ifeval::["{context}" == "osdk-ansible-updating-projects"]
+:ansible:
+:type: Ansible
+endif::[]
+ifeval::["{context}" == "osdk-helm-updating-projects"]
+:helm:
+:type: Helm
+endif::[]
+
+:_mod-docs-content-type: PROCEDURE
+[id="osdk-upgrading-projects_{context}"]
+= Updating {type}-based Operator projects for Operator SDK {osdk_ver}
+
+The following procedure updates an existing {type}-based Operator project for compatibility with {osdk_ver}.
+
+.Prerequisites
+
+* Operator SDK {osdk_ver} installed
+* An Operator project created or maintained with Operator SDK {osdk_ver_n1}
+
+.Procedure
+
+// The following few steps should be retained/updated for each new migration procedure, as they're just bumping the OSDK version for each language type.
+
+. Edit the Makefile of your Operator project to update the Operator SDK version to {osdk_ver}, as shown in the following example:
++
+.Example Makefile
+[source,make,subs="attributes+"]
+----
+# Set the Operator SDK version to use. By default, what is installed on the system is used.
+# This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit.
+OPERATOR_SDK_VERSION ?= v{osdk_ver} <1>
+----
+<1> Change the version from `{osdk_ver_n1}` to `{osdk_ver}`.
+ifdef::helm[]
+. Edit the Makefile of your Operator project to update the `ose-helm-rhel9-operator` image tag to `{product-version}`, as shown in the following example:
++
+.Example Dockerfile
+[source,docker,subs="attributes+"]
+----
+FROM registry.redhat.io/openshift4/ose-helm-rhel9-operator:v{product-version}
+----
+endif::helm[]
+
+ifdef::ansible[]
+. Edit the Dockerfile of your Operator project to update the `ose-ansible-operator` image tag to `{product-version}`, as shown in the following example:
++
+.Example Dockerfile
+[source,docker,subs="attributes+"]
+----
+FROM registry.redhat.io/openshift4/ose-ansible-operator:v{product-version}
+----
+endif::ansible[]
+
+. You must upgrade the Kubernetes versions in your Operator project to use 1.30 and Kubebuilder v4.
++
+[TIP]
+====
+This update include complex scaffolding changes due to the removal of link:https://github.com/brancz/kube-rbac-proxy[kube-rbac-proxy]. If these migrations become difficult to follow, scaffold a new sample project for comparison.
+====
+
+ifdef::helm,ansible[]
+.. Update the Kustomize version in your Makefile by making the following changes:
++
+[source,diff]
+----
+- curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.0/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \
++ curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.4.2/kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz | \
+----
+endif::helm,ansible[]
+
+ifdef::golang[]
+.. Update your `go.mod` file with the following changes to upgrade your dependencies:
++
+[source,go]
+----
+go 1.22.0
+   
+github.com/onsi/ginkgo/v2 v2.17.1
+github.com/onsi/gomega v1.32.0
+k8s.io/api v0.30.1
+k8s.io/apimachinery v0.30.1
+k8s.io/client-go v0.30.1
+sigs.k8s.io/controller-runtime v0.18.4
+----
+
+.. Download the upgraded dependencies by running the following command:
++
+[source,terminal]
+----
+$ go mod tidy
+----
+
+.. Update your Makefile with the following changes:
++
+[source,diff]
+----
+- ENVTEST_K8S_VERSION = 1.29.0
++ ENVTEST_K8S_VERSION = 1.30.0
+----
++
+[source,diff]
+----
+- KUSTOMIZE ?= $(LOCALBIN)/kustomize-$(KUSTOMIZE_VERSION)
+- CONTROLLER_GEN ?= $(LOCALBIN)/controller-gen-$(CONTROLLER_TOOLS_VERSION)
+- ENVTEST ?= $(LOCALBIN)/setup-envtest-$(ENVTEST_VERSION)
+- GOLANGCI_LINT = $(LOCALBIN)/golangci-lint-$(GOLANGCI_LINT_VERSION)
++ KUSTOMIZE ?= $(LOCALBIN)/kustomize
++ CONTROLLER_GEN ?= $(LOCALBIN)/controller-gen
++ ENVTEST ?= $(LOCALBIN)/setup-envtest
++ GOLANGCI_LINT = $(LOCALBIN)/golangci-lint
+----
++
+[source,diff]
+----
+- KUSTOMIZE_VERSION ?= v5.3.0
+- CONTROLLER_TOOLS_VERSION ?= v0.14.0
+- ENVTEST_VERSION ?= release-0.17
+- GOLANGCI_LINT_VERSION ?= v1.57.2
++ KUSTOMIZE_VERSION ?= v5.4.2
++ CONTROLLER_TOOLS_VERSION ?= v0.15.0
++ ENVTEST_VERSION ?= release-0.18
++ GOLANGCI_LINT_VERSION ?= v1.59.1
+----
++
+[source,diff]
+----
+- $(call go-install-tool,$(GOLANGCI_LINT),github.com/golangci/golangci-lint/cmd/golangci-lint,${GOLANGCI_LINT_VERSION})
++ $(call go-install-tool,$(GOLANGCI_LINT),github.com/golangci/golangci-lint/cmd/golangci-lint,$(GOLANGCI_LINT_VERSION))
+----
++
+[source,diff]
+----
+- $(call go-install-tool,$(GOLANGCI_LINT),github.com/golangci/golangci-lint/cmd/golangci-lint,${GOLANGCI_LINT_VERSION})
++ $(call go-install-tool,$(GOLANGCI_LINT),github.com/golangci/golangci-lint/cmd/golangci-lint,$(GOLANGCI_LINT_VERSION))
+----
++
+[source,diff]
+----
+- @[ -f $(1) ] || { \
++ @[ -f "$(1)-$(3)" ] || { \
+  echo "Downloading $${package}" ;\
++ rm -f $(1) || true ;\
+- mv "$$(echo "$(1)" | sed "s/-$(3)$$//")" $(1) ;\
+- }
++ mv $(1) $(1)-$(3) ;\
++ } ;\
++ ln -sf $(1)-$(3) $(1) 
+----
+
+.. Update your `.golangci.yml` file with the following changes:
++
+[source,diff]
+----
+-  exportloopref
++     - ginkgolinter
+      - prealloc
++     - revive
++ 
++ linters-settings:
++   revive:
++     rules:
++       - name: comment-spacings
+----
+
+.. Update your Dockerfile with the following changes:
++
+[source,diff]
+----
+- FROM golang:1.21 AS builder
++ FROM golang:1.22 AS builder
+----
+
+.. Update your `main.go` file with the following changes:
++
+[source,diff]
+----
+     "sigs.k8s.io/controller-runtime/pkg/log/zap"
++    "sigs.k8s.io/controller-runtime/pkg/metrics/filters"
+
+     var enableHTTP2 bool
+-    flag.StringVar(&metricsAddr, "metrics-bind-address", ":8080", "The address the metric endpoint binds to.")
++    var tlsOpts []func(*tls.Config)
++    flag.StringVar(&metricsAddr, "metrics-bind-address", "0", "The address the metrics endpoint binds to. "+
++        "Use :8443 for HTTPS or :8080 for HTTP, or leave as 0 to disable the metrics service.")
+     flag.StringVar(&probeAddr, "health-probe-bind-address", ":8081", "The address the probe endpoint binds to.")
+     flag.BoolVar(&enableLeaderElection, "leader-elect", false,
+         "Enable leader election for controller manager. "+
+             "Enabling this will ensure there is only one active controller manager.")
+-    flag.BoolVar(&secureMetrics, "metrics-secure", false,
+-        "If set the metrics endpoint is served securely")
++    flag.BoolVar(&secureMetrics, "metrics-secure", true,
++        "If set, the metrics endpoint is served securely via HTTPS. Use --metrics-secure=false to use HTTP instead.")
+
+-    tlsOpts := []func(*tls.Config){}
+
++    // Metrics endpoint is enabled in 'config/default/kustomization.yaml'. The Metrics options configure the server.
++    // More info:
++    // - https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.18.4/pkg/metrics/server
++    // - https://book.kubebuilder.io/reference/metrics.html
++    metricsServerOptions := metricsserver.Options{
++        BindAddress:   metricsAddr,
++        SecureServing: secureMetrics,
++        // TODO(user): TLSOpts is used to allow configuring the TLS config used for the server. If certificates are
++        // not provided, self-signed certificates will be generated by default. This option is not recommended for
++        // production environments as self-signed certificates do not offer the same level of trust and security
++        // as certificates issued by a trusted Certificate Authority (CA). The primary risk is potentially allowing
++        // unauthorized access to sensitive metrics data. Consider replacing with CertDir, CertName, and KeyName
++        // to provide certificates, ensuring the server communicates using trusted and secure certificates.
++        TLSOpts: tlsOpts,
++    }
++
++    if secureMetrics {
++        // FilterProvider is used to protect the metrics endpoint with authn/authz.
++        // These configurations ensure that only authorized users and service accounts
++        // can access the metrics endpoint. The RBAC are configured in 'config/rbac/kustomization.yaml'. More info:
++        // https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.18.4/pkg/metrics/filters#WithAuthenticationAndAuthorization
++        metricsServerOptions.FilterProvider = filters.WithAuthenticationAndAuthorization
++    }
++
+     mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
+-        Scheme: scheme,
+-        Metrics: metricsserver.Options{
+-            BindAddress:   metricsAddr,
+-            SecureServing: secureMetrics,
+-            TLSOpts:       tlsOpts,
+-        },
++        Scheme:                 scheme,
++        Metrics:                metricsServerOptions,
+----
+endif::golang[]
+
+.. Update your `config/default/kustomization.yaml` file with the following changes:
++
+[source,diff]
+----
+  # [PROMETHEUS] To enable prometheus monitor, uncomment all sections with 'PROMETHEUS'.
+  #- ../prometheus
++ # [METRICS] Expose the controller manager metrics service.
++ - metrics_service.yaml
+ 
++ # Uncomment the patches line if you enable Metrics, and/or are using webhooks and cert-manager
+  patches:
+- # Protect the /metrics endpoint by putting it behind auth.
+- # If you want your controller-manager to expose the /metrics
+- # endpoint w/o any authn/z, please comment the following line.
+- - path: manager_auth_proxy_patch.yaml
++ # [METRICS] The following patch will enable the metrics endpoint using HTTPS and the port :8443.
++ # More info: https://book.kubebuilder.io/reference/metrics
++ - path: manager_metrics_patch.yaml
++   target:
++     kind: Deployment
+----
+
+.. Remove the `config/default/manager_auth_proxy_patch.yaml` and `config/default/manager_config_patch.yaml` files.
+
+.. Create a `config/default/manager_metrics_patch.yaml` file with the following content:
++
+[source,text,subs="attributes+"]
+----
+# This patch adds the args to allow exposing the metrics endpoint using HTTPS
+- op: add
+  path: /spec/template/spec/containers/0/args/0
+  value: --metrics-bind-address=:8443
+ifdef::helm,ansible[]
+# This patch adds the args to allow securing the metrics endpoint
+- op: add
+  path: /spec/template/spec/containers/0/args/0
+  value: --metrics-secure
+# This patch adds the args to allow RBAC-based authn/authz the metrics endpoint
+- op: add
+  path: /spec/template/spec/containers/0/args/0
+  value: --metrics-require-rbac
+endif::helm,ansible[]
+----
+
+.. Create a `config/default/metrics_service.yaml` file with the following content:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    control-plane: controller-manager
+    app.kubernetes.io/name: <operator-name>
+    app.kubernetes.io/managed-by: kustomize
+  name: controller-manager-metrics-service
+  namespace: system
+spec:
+  ports:
+    - name: https
+      port: 8443
+      protocol: TCP
+      targetPort: 8443
+  selector:
+    control-plane: controller-manager
+----
+
+.. Update your `config/manager/manager.yaml` file with the following changes:
++
+[source,diff,subs="attributes+"]
+----
+  - --leader-elect
+ifdef::golang,helm[]
++ - --health-probe-bind-address=:8081
+endif::[]
+ifdef::ansible[]
++ - --health-probe-bind-address=:6789
+endif::[]
+----
+
+.. Update your `config/prometheus/monitor.yaml` file with the following changes:
++
+[source,diff]
+----
+     - path: /metrics
+-      port: https
++      port: https # Ensure this is the name of the port that exposes HTTPS metrics
+       tlsConfig:
++        # TODO(user): The option insecureSkipVerify: true is not recommended for production since it disables
++        # certificate verification. This poses a significant security risk by making the system vulnerable to
++        # man-in-the-middle attacks, where an attacker could intercept and manipulate the communication between
++        # Prometheus and the monitored services. This could lead to unauthorized access to sensitive metrics data,
++        # compromising the integrity and confidentiality of the information.
++        # Please use the following options for secure configurations:
++        # caFile: /etc/metrics-certs/ca.crt
++        # certFile: /etc/metrics-certs/tls.crt
++        # keyFile: /etc/metrics-certs/tls.key
+         insecureSkipVerify: true
+----
+
+.. Remove the following files from the `config/rbac/` directory:
++
+--
+* `auth_proxy_client_clusterrole.yaml`
+* `auth_proxy_role.yaml`
+* `auth_proxy_role_binding.yaml`
+* `auth_proxy_service.yaml`
+--
+
+.. Update your `config/rbac/kustomization.yaml` file with the following changes:
++
+[source,diff]
+----
+  - leader_election_role_binding.yaml
+- # Comment the following 4 lines if you want to disable
+- # the auth proxy (https://github.com/brancz/kube-rbac-proxy)
+- # which protects your /metrics endpoint.
+- - auth_proxy_service.yaml
+- - auth_proxy_role.yaml
+- - auth_proxy_role_binding.yaml
+- - auth_proxy_client_clusterrole.yaml
++ # The following RBAC configurations are used to protect
++ # the metrics endpoint with authn/authz. These configurations
++ # ensure that only authorized users and service accounts
++ # can access the metrics endpoint. Comment the following
++ # permissions if you want to disable this protection.
++ # More info: https://book.kubebuilder.io/reference/metrics.html
++ - metrics_auth_role.yaml
++ - metrics_auth_role_binding.yaml
++ - metrics_reader_role.yaml
+----
+
+.. Create a `config/rbac/metrics_auth_role_binding.yaml` file with the following content:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: metrics-auth-rolebinding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: metrics-auth-role
+subjects:
+  - kind: ServiceAccount
+    name: controller-manager
+    namespace: system
+----
+
+.. Create a `config/rbac/metrics_reader_role.yaml` file with the following content:
++
+[source,yaml]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: metrics-reader
+rules:
+- nonResourceURLs:
+  - "/metrics"
+  verbs:
+  - get
+----
+
+ifeval::["{context}" == "osdk-golang-updating-projects"]
+:!golang:
+:!type:
+endif::[]
+ifeval::["{context}" == "osdk-ansible-updating-projects"]
+:!ansible:
+:!type:
+endif::[]
+ifeval::["{context}" == "osdk-helm-updating-projects"]
+:!helm:
+:!type:
+endif::[]
\ No newline at end of file
diff --git a/modules/ossm-about-smcp.adoc b/modules/ossm-about-smcp.adoc
index f94ea4aa8653..efde7b34dbef 100644
--- a/modules/ossm-about-smcp.adoc
+++ b/modules/ossm-about-smcp.adoc
@@ -12,16 +12,16 @@ The control plane includes Istiod, Ingress and Egress Gateways, and other compon
 This basic installation is configured based on the default {product-title} settings and is not designed for production use. Use this default installation to verify your installation, and then configure your `ServiceMeshControlPlane` settings for your environment.
 ====
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [NOTE]
 ====
 The {SMProductShortName} documentation uses `istio-system` as the example project, but you can deploy the service mesh to any project.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 If you are deploying the control plane for use on {product-rosa}, see the Red Hat Knowledgebase article link:https://access.redhat.com/solutions/6529231[OpenShift service mesh operator Istio basic not starting due to authentication errors], which discusses adding a new project and starting pods.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 If you are deploying the control plane for use on {product-dedicated}, see the Red Hat Knowledgebase article link:https://access.redhat.com/solutions/6529231[OpenShift service mesh operator Istio basic not starting due to authentication errors], which discusses adding a new project and starting pods.
 endif::openshift-dedicated[]
diff --git a/modules/ossm-add-project-using-label-selectors-cli.adoc b/modules/ossm-add-project-using-label-selectors-cli.adoc
index 7b9c71347259..b0b98e7385b1 100644
--- a/modules/ossm-add-project-using-label-selectors-cli.adoc
+++ b/modules/ossm-add-project-using-label-selectors-cli.adoc
@@ -11,12 +11,12 @@ You can use label selectors to add a project to the {SMProductShortName} with th
 .Prerequisites
 * You have installed the {SMProductName} Operator.
 * The deployment has an existing `ServiceMeshMemberRoll` resource.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
diff --git a/modules/ossm-add-project-using-label-selectors-console.adoc b/modules/ossm-add-project-using-label-selectors-console.adoc
index c1084c186fcc..7c4da3010779 100644
--- a/modules/ossm-add-project-using-label-selectors-console.adoc
+++ b/modules/ossm-add-project-using-label-selectors-console.adoc
@@ -11,12 +11,12 @@ You can use labels selectors to add a project to the {SMProductShortName} with t
 .Prerequisites
 * You have installed the {SMProductName} Operator.
 * The deployment has an existing `ServiceMeshMemberRoll` resource.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to the {product-title} web console as `cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to the {product-title} web console as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
diff --git a/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc b/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc
index d2924b25cd5f..382f9dba47d7 100644
--- a/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc
+++ b/modules/ossm-configuring-the-threescale-wasm-auth-module.adoc
@@ -25,9 +25,9 @@ Configuring the WebAssembly extension is currently a manual process. Support for
 
 * Identify a Kubernetes workload and namespace on your {SMProductShortName} deployment that you will apply this module.
 * You must have a 3scale tenant account. See link:https://www.3scale.net/signup[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.11/html-single/installing_3scale/index#install-threescale-on-openshift-guide[3scale 2.11 On-Premises] with a matching service and relevant applications and metrics defined.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * If you apply the module to the `<product_page>` microservice in the `bookinfo` namespace, see the xref:../../service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc#ossm-tutorial-bookinfo-overview_deploying-applications-ossm-v1x[Bookinfo sample application].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 ** The following example is the YAML format for the custom resource for `threescale-wasm-auth` module.
 This example refers to the upstream Maistra version of {SMProductShortName}, `WasmPlugin` API. You must declare the namespace where the `threescale-wasm-auth` module is deployed, alongside a `selector` to identify the set of applications the module will apply to:
 +
diff --git a/modules/ossm-control-plane-cli.adoc b/modules/ossm-control-plane-cli.adoc
index c21dab7f1513..7229720a0fea 100644
--- a/modules/ossm-control-plane-cli.adoc
+++ b/modules/ossm-control-plane-cli.adoc
@@ -13,12 +13,12 @@ You can deploy a basic `ServiceMeshControlPlane` from the command line.
 
 * The {SMProductName} Operator must be installed.
 * Access to the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -29,11 +29,11 @@ endif::openshift-rosa,openshift-dedicated[]
 $ oc new-project istio-system
 ----
 +
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 The `ServiceMeshControlPlane` resource must be installed in the `istio-system` project, separate from your microservices and Operators.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Create a `ServiceMeshControlPlane` file named `istio-installation.yaml` using the following example. The version of the {SMProductShortName} control plane determines the features available regardless of the version of the Operator.
 +
 .Example version {MaistraVersion} istio-installation.yaml
@@ -56,8 +56,8 @@ spec:
     grafana:
       enabled: true
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Create a `ServiceMeshControlPlane` file named `istio-installation.yaml` using the following example. The version of the {SMProductShortName} control plane determines the features available regardless of the version of the Operator.
 +
 .Example `ServiceMeshControlPlane` resource
@@ -88,13 +88,13 @@ spec:
   telemetry:
     type: Istiod
 ----
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 <1> Specifies a required setting for {product-rosa}.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 <1> Specifies a required setting for {product-dedicated}.
 endif::openshift-dedicated[]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
 . Run the following command to deploy the {SMProductShortName} control plane, where `<istio_installation.yaml>` includes the full path to your file.
 +
diff --git a/modules/ossm-control-plane-web.adoc b/modules/ossm-control-plane-web.adoc
index b5fa597e407b..d28a3c9cc1b6 100644
--- a/modules/ossm-control-plane-web.adoc
+++ b/modules/ossm-control-plane-web.adoc
@@ -11,12 +11,12 @@ You can deploy a basic `ServiceMeshControlPlane` by using the web console.  In t
 .Prerequisites
 
 * The {SMProductName} Operator must be installed.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to the {product-title} web console as `cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to the {product-title} web console as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -27,16 +27,16 @@ endif::openshift-rosa,openshift-dedicated[]
 .. Navigate to *Home* -> *Projects*.
 +
 .. Click *Create Project*.
-ifndef::openshift-rosa,openshift-dedcated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedcated[]
 +
 .. In the *Name* field, enter `istio-system`. The `ServiceMeshControlPlane` resource must be installed in a project that is separate from your microservices and Operators.
 +
 These steps use `istio-system` as an example, but you can deploy your {SMProductShortName} control plane in any project as long as it is separate from the project that contains your services.
-endif::openshift-rosa,openshift-dedcated[]
-ifdef::openshift-rosa,openshift-dedcated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedcated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedcated[]
 +
 .. In the *Name* field, enter `istio-system`. The `ServiceMeshControlPlane` resource must be installed in the `istio-system` project, separate from your microservices and Operators.
-endif::openshift-rosa,openshift-dedcated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedcated[]
 +
 .. Click *Create*.
 
@@ -49,9 +49,9 @@ endif::openshift-rosa,openshift-dedcated[]
 --
 .. Accept the default {SMProductShortName} control plane version to take advantage of the features available in the most current version of the product. The version of the control plane determines the features available regardless of the version of the Operator.
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 .. Add the `spec.security.identity.type.ThirdParty` field, required by {product-rosa}.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 .. Add the `spec.security.identity.type.ThirdParty` field, required by {product-dedicated}.
 endif::openshift-dedicated[]
diff --git a/modules/ossm-deploy-cluster-wide-control-plane-cli.adoc b/modules/ossm-deploy-cluster-wide-control-plane-cli.adoc
index 630a3350d209..f76c66af9ace 100644
--- a/modules/ossm-deploy-cluster-wide-control-plane-cli.adoc
+++ b/modules/ossm-deploy-cluster-wide-control-plane-cli.adoc
@@ -13,12 +13,12 @@ You can configure the `ServiceMeshControlPlane` resource for cluster-wide deploy
 
 * The {SMProductName} Operator is installed.
 * You have access to the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -31,7 +31,7 @@ $ oc new-project istio-system
 
 . Create a `ServiceMeshControlPlane` file named `istio-installation.yaml` using the following example:
 +
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Example version {MaistraVersion} istio-installation.yaml
 [source,yaml, subs="attributes,verbatim"]
 ----
@@ -44,8 +44,8 @@ spec:
   version: v{MaistraVersion}
   mode: ClusterWide
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Example `ServiceMeshControlPlane` resource
 [source,yaml, subs="attributes,verbatim"]
 ----
@@ -62,13 +62,13 @@ spec:
       type: ThirdParty <2>
 ----
 <1> Specifies that the resource is for a cluster-wide deployment.
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 <2> Specifies a required setting for {product-rosa}. 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 <2> Specifies a required setting for {product-dedicated}. 
 endif::openshift-dedicated[]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Run the following command to deploy the {SMProductShortName} control plane:
 +
diff --git a/modules/ossm-deploy-cluster-wide-control-plane-console.adoc b/modules/ossm-deploy-cluster-wide-control-plane-console.adoc
index ab7429e63851..cf6de3a3d981 100644
--- a/modules/ossm-deploy-cluster-wide-control-plane-console.adoc
+++ b/modules/ossm-deploy-cluster-wide-control-plane-console.adoc
@@ -11,12 +11,12 @@ You can configure the `ServiceMeshControlPlane` resource for cluster-wide deploy
 .Prerequisites
 
 * The {SMProductName} Operator is installed.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -40,7 +40,7 @@ These steps use `istio-system` as an example. You can deploy the {SMProductShort
 
 . Click *YAML view*. The version of the {SMProductShortName} control plane determines the features available regardless of the version of the Operator.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Modify the `spec.mode` field of the YAML file to specify `ClusterWide`.
 +
 .Example version {MaistraVersion} istio-installation.yaml
@@ -56,8 +56,8 @@ spec:
   version: v{MaistraVersion}
   mode: ClusterWide
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Modify the `spec.mode` field and add the `spec.security.identity.type.ThirdParty` field:
 +
 .Example `ServiceMeshControlPlane` resource
@@ -94,13 +94,13 @@ spec:
     type: Istiod
 ----
 <1> Specifies that the resource is for a cluster-wide deployment.
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 <2> Specifies a required setting for {product-rosa}. 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 <2> Specifies a required setting for {product-dedicated}. 
 endif::openshift-dedicated[]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Click *Create*. The Operator creates pods, services, and {SMProductShortName} control plane components based on your configuration parameters. The operator also creates the `ServiceMeshMemberRoll` if it does not exist as part of the default configuration.
 
diff --git a/modules/ossm-federation-across-cluster.adoc b/modules/ossm-federation-across-cluster.adoc
index fa54ce4b82f2..403d8b9b7572 100644
--- a/modules/ossm-federation-across-cluster.adoc
+++ b/modules/ossm-federation-across-cluster.adoc
@@ -15,12 +15,12 @@ If the cluster runs on bare metal and fully supports `LoadBalancer` services, th
 
 If the cluster does not support `LoadBalancer` services, using a `NodePort` service could be an option if the nodes are accessible from the cluster running the other mesh. In the `ServiceMeshPeer` object, specify the IP addresses of the nodes in the `.spec.remote.addresses` field and the service's node ports in the `.spec.remote.discoveryPort` and `.spec.remote.servicePort` fields.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 == Exposing the federation ingress on clusters running on {ibm-power-title} and {ibm-z-title}
 If the cluster runs on {ibm-power-name} or {ibm-z-name} infrastructure and fully supports `LoadBalancer` services, the IP address found in the `.status.loadBalancer.ingress.ip` field of the ingress gateway `Service` object should be specified as one of the entries in the `.spec.remote.addresses` field of the `ServiceMeshPeer` object.
 
 If the cluster does not support `LoadBalancer` services, using a `NodePort` service could be an option if the nodes are accessible from the cluster running the other mesh. In the `ServiceMeshPeer` object, specify the IP addresses of the nodes in the `.spec.remote.addresses` field and the service's node ports in the `.spec.remote.discoveryPort` and `.spec.remote.servicePort` fields.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ifndef::openshift-dedicated[]
 == Exposing the federation ingress on Amazon Web Services (AWS)
@@ -31,16 +31,16 @@ service.beta.kubernetes.io/aws-load-balancer-type: nlb
 The Fully Qualified Domain Name found in the `.status.loadBalancer.ingress.hostname` field of the ingress gateway `Service` object should be specified as one of the entries in the `.spec.remote.addresses` field of the `ServiceMeshPeer` object.
 endif::openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 == Exposing the federation ingress on Azure
 On Microsoft Azure, merely setting the service type to `LoadBalancer` suffices for mesh federation to operate correctly.
 
 The IP address found in the `.status.loadBalancer.ingress.ip` field of the ingress gateway `Service` object should be specified as one of the entries in the `.spec.remote.addresses` field of the `ServiceMeshPeer` object.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 == Exposing the federation ingress on Google Cloud Platform (GCP)
 On Google Cloud Platform, merely setting the service type to `LoadBalancer` suffices for mesh federation to operate correctly.
 
 The IP address found in the `.status.loadBalancer.ingress.ip` field of the ingress gateway `Service` object should be specified as one of the entries in the `.spec.remote.addresses` field of the `ServiceMeshPeer` object.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
diff --git a/modules/ossm-federation-config-smcp.adoc b/modules/ossm-federation-config-smcp.adoc
index 3b7f39dac202..45ce20f50389 100644
--- a/modules/ossm-federation-config-smcp.adoc
+++ b/modules/ossm-federation-config-smcp.adoc
@@ -11,7 +11,7 @@ Before a mesh can be federated, you must configure the `ServiceMeshControlPlane`
 
 In the following example, the administrator for the `red-mesh` is configuring the SMCP for federation with both the `green-mesh` and the `blue-mesh`.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Sample SMCP for red-mesh
 [source,yaml, subs="attributes,verbatim"]
 ----
@@ -83,8 +83,8 @@ spec:
     trust:
       domain: red-mesh.local
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Sample SMCP for red-mesh
 [source,yaml, subs="attributes,verbatim"]
 ----
@@ -162,7 +162,7 @@ spec:
     trust:
       domain: red-mesh.local
 ----
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .ServiceMeshControlPlane federation configuration parameters
 [options="header"]
diff --git a/modules/ossm-install-ossm-operator.adoc b/modules/ossm-install-ossm-operator.adoc
index 4552d29fea73..aae688fd70a5 100644
--- a/modules/ossm-install-ossm-operator.adoc
+++ b/modules/ossm-install-ossm-operator.adoc
@@ -31,12 +31,12 @@ If you have already installed the {es-op} as part of OpenShift {logging-uc}, you
 
 .Procedure
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Log in to the {product-title} web console as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Log in to the {product-title} web console as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . In the {product-title} web console, click *Operators* -> *OperatorHub*.
 
diff --git a/modules/ossm-integrating-with-user-workload-monitoring.adoc b/modules/ossm-integrating-with-user-workload-monitoring.adoc
index 73c90b72428a..b29854ddbe3f 100644
--- a/modules/ossm-integrating-with-user-workload-monitoring.adoc
+++ b/modules/ossm-integrating-with-user-workload-monitoring.adoc
@@ -39,7 +39,7 @@ subjects:
 
 . Configure Kiali for user-workload monitoring:
 +
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [source,yaml]
 ----
 apiVersion: kiali.io/v1alpha1
@@ -59,8 +59,8 @@ spec:
         enabled: true
       url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
 ----
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 [source,yaml]
 ----
 apiVersion: kiali.io/v1alpha1
@@ -78,7 +78,7 @@ spec:
     ingress_enabled: true
     namespace: istio-system
 ----
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 [source,yaml]
 ----
@@ -127,7 +127,7 @@ spec:
       url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
   version: v1.65
 ----
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
 [NOTE]
 ====
@@ -143,7 +143,7 @@ This means that the following common settings for `spec.deployment.accessible_na
 
 The validation error message provides a complete list of all the restricted namespaces.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Configure the SMCP for external Prometheus:
 +
diff --git a/modules/ossm-migrating-from-smcp-defined-gateways-to-gateway-injection.adoc b/modules/ossm-migrating-from-smcp-defined-gateways-to-gateway-injection.adoc
index 1335d93f73e0..1a124a726b07 100644
--- a/modules/ossm-migrating-from-smcp-defined-gateways-to-gateway-injection.adoc
+++ b/modules/ossm-migrating-from-smcp-defined-gateways-to-gateway-injection.adoc
@@ -18,11 +18,11 @@ This procedure explains how to migrate with zero downtime from gateways defined
 
 .Procedure
 
-. Create a new ingress gateway that is configured to use gateway injection. 
+. Create a new ingress gateway that is configured to use gateway injection.
 +
 [NOTE]
 ====
-This procedure migrates away from the default ingress gateway deployment defined in the `ServiceMeshControlPlane` resource to gateway injection. The procedure may be modified to migrate from additional ingress gateways configured in the SMCP.    
+This procedure migrates away from the default ingress gateway deployment defined in the `ServiceMeshControlPlane` resource to gateway injection. The procedure may be modified to migrate from additional ingress gateways configured in the SMCP.
 ====
 +
 .Example ingress gateway resource with gateway injection
@@ -31,13 +31,13 @@ This procedure migrates away from the default ingress gateway deployment defined
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: istio-ingressgateway-canary 
+  name: istio-ingressgateway-canary
   namespace: istio-system <1>
 spec:
   selector:
     matchLabels:
       app: istio-ingressgateway
-      istio: ingressgateway 
+      istio: ingressgateway
   template:
     metadata:
       annotations:
@@ -94,16 +94,16 @@ spec:
     - {}
   policyTypes:
     - Ingress
----- 
-<1> The gateway injection deployment and all supporting resources should be deployed in the same namespace as the SMCP-defined gateway. 
+----
+<1> The gateway injection deployment and all supporting resources should be deployed in the same namespace as the SMCP-defined gateway.
 <2> Ensure that the labels specified in the pod template include all of the label selectors specified in the `Service` object associated with the existing SMCP-defined gateway.
 <3> Grant access to the new gateway from outside the cluster. This access is required whenever the `spec.security.manageNetworkPolicy` of the `ServiceMeshControlPlane` resource is set to `true`, which is the default setting.
 
-. Verify that the new gateway deployment is successfully handling requests. 
+. Verify that the new gateway deployment is successfully handling requests.
 +
 If access logging was configured in the `ServiceMeshControlPlane` resource, view the access logs of the new gateway deployment to confirm the behavior.
 
-. Scale down the old deployment and scale up the new deployment. 
+. Scale down the old deployment and scale up the new deployment.
 +
 Gradually shift traffic from the old gateway deployment to the new gateway deployment by performing the following steps:
 
@@ -120,7 +120,7 @@ $ oc scale -n istio-system deployment/<new_gateway_deployment> --replicas <new_n
 $ oc scale -n istio-system deployment/<old_gateway_deployment> --replicas <new_number_of_replicas>
 ----
 
-.. Repeat running the previous two commands. Each time, increase the number of replicas for the new gateway deployment and decrease the number of replicas for the old gateway deployment. Continue repeating until the new gateway deployment handles all traffic to the gateway `Service` object. 
+.. Repeat running the previous two commands. Each time, increase the number of replicas for the new gateway deployment and decrease the number of replicas for the old gateway deployment. Continue repeating until the new gateway deployment handles all traffic to the gateway `Service` object.
 
 . Remove the `app.kubernetes.io/managed-by` label from the gateway `Service` object by running the following command:
 +
@@ -129,7 +129,7 @@ $ oc scale -n istio-system deployment/<old_gateway_deployment> --replicas <new_n
 $ oc label service -n istio-system istio-ingressgateway app.kubernetes.io/managed-by-
 ----
 +
-Removing the label prevents the service from being deleted when the gateway is disabled in the `ServiceMeshControlPlane` resource. 
+Removing the label prevents the service from being deleted when the gateway is disabled in the `ServiceMeshControlPlane` resource.
 
 . Remove the `ownerReferences` object from the gateway `Service` object by running the following command:
 +
@@ -149,5 +149,6 @@ $ oc patch smcp -n istio-system <smcp_name> --type='json' -p='[{"op": "replace",
 +
 [NOTE]
 ====
-When the old ingress gateway `Service` object is disabled it is not deleted. You may save this `Service` object to a file and manage it alongside the new gateway injection resources.
+* When the old ingress gateway `Service` object is disabled it is not deleted. You may save this `Service` object to a file and manage it alongside the new gateway injection resources.
+* The `/spec/gateways/ingress/enabled` path is available if you explicitly set it for the `ServiceMeshControlPlane` resource. If you are using the default value, you must patch the `/spec/gateways/enabled` path for both ingress and egress gateways.
 ====
\ No newline at end of file
diff --git a/modules/ossm-release-2-4-14.adoc b/modules/ossm-release-2-4-14.adoc
new file mode 100644
index 000000000000..5eadf276ff22
--- /dev/null
+++ b/modules/ossm-release-2-4-14.adoc
@@ -0,0 +1,31 @@
+////
+Module included in the following assemblies:
+* service_mesh/v2x/servicemesh-release-notes.adoc
+////
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-4-14_{context}"]
+= {SMProductName} version 2.4.14
+
+This release of {SMProductName} is included with the {SMProductName} Operator 2.6.5 and is supported on {product-title} 4.14 and later. This release addresses Common Vulnerabilities and Exposures (CVEs).
+
+[id=ossm-release-2-4-14-components_{context}]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.16.7
+
+|Envoy Proxy
+|1.24.12
+
+|Kiali Server
+|1.65.19
+|===
+
+[id="ossm-fixed-issues-2-4-14_{context}"]
+== Fixed issues
+
+* https://issues.redhat.com/browse/OSSM-8608[OSSM-8608] Previously, terminating a Container Network Interface (CNI) pod during the installation phase while copying binaries could leave Istio-CNI temporary files on the node file system. Repeated occurrences could eventually fill up the node disk space. Now, while terminating a CNI pod during the installation phase, existing temporary files are deleted before copying the CNI binary, ensuring that only one temporary file per Istio version exists on the node file system.
\ No newline at end of file
diff --git a/modules/ossm-release-2-4-15.adoc b/modules/ossm-release-2-4-15.adoc
new file mode 100644
index 000000000000..b9d48e7d8fb8
--- /dev/null
+++ b/modules/ossm-release-2-4-15.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * service_mesh/v2x/servicemesh-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-4-15_{context}"]
+= {SMProductName} version 2.4.15
+
+This release of {SMProductName} is included with the {SMProductName} Operator 2.6.6 and is supported on {product-title} 4.14 and later.
+
+[id="ossm-release-2-4-15-components_{context}"]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.16.7
+
+|Envoy Proxy
+|1.24.12
+
+|Kiali Server
+|1.65.20
+|===
diff --git a/modules/ossm-release-2-5-8.adoc b/modules/ossm-release-2-5-8.adoc
new file mode 100644
index 000000000000..916f0a71f96c
--- /dev/null
+++ b/modules/ossm-release-2-5-8.adoc
@@ -0,0 +1,31 @@
+////
+Module included in the following assemblies:
+* service_mesh/v2x/servicemesh-release-notes.adoc
+////
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-5-8_{context}"]
+= {SMProductName} version 2.5.8
+
+This release of {SMProductName} is included with the {SMProductName} Operator 2.6.5 and is supported on {product-title} 4.14 and later. This release addresses Common Vulnerabilities and Exposures (CVEs).
+
+[id=ossm-release-2-5-8-components_{context}]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.18.7
+
+|Envoy Proxy
+|1.26.8
+
+|Kiali Server
+|1.73.18
+|===
+
+[id="ossm-fixed-issues-2-5-8_{context}"]
+== Fixed issues
+
+* https://issues.redhat.com/browse/OSSM-8608[OSSM-8608] Previously, terminating a Container Network Interface (CNI) pod during the installation phase while copying binaries could leave Istio-CNI temporary files on the node file system. Repeated occurrences could eventually fill up the node disk space. Now, while terminating a CNI pod during the installation phase, existing temporary files are deleted before copying the CNI binary, ensuring that only one temporary file per Istio version exists on the node file system.
\ No newline at end of file
diff --git a/modules/ossm-release-2-5-9.adoc b/modules/ossm-release-2-5-9.adoc
new file mode 100644
index 000000000000..702ca5bd2746
--- /dev/null
+++ b/modules/ossm-release-2-5-9.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * service_mesh/v2x/servicemesh-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-5-9_{context}"]
+= {SMProductName} version 2.5.9
+
+This release of {SMProductName} is included with the {SMProductName} Operator 2.6.6 and is supported on {product-title} 4.14 and later. This release addresses Common Vulnerabilities and Exposures (CVEs).
+
+[id="ossm-release-2-5-9-components_{context}"]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.18.7
+
+|Envoy Proxy
+|1.26.8
+
+|Kiali Server
+|1.73.19
+|===
\ No newline at end of file
diff --git a/modules/ossm-release-2-6-0.adoc b/modules/ossm-release-2-6-0.adoc
index 2689207c4d08..2cba06e2adc6 100644
--- a/modules/ossm-release-2-6-0.adoc
+++ b/modules/ossm-release-2-6-0.adoc
@@ -98,13 +98,6 @@ You can expose tracing data to the {TempoName} by appending a named element and
 
 You can create a {OTELName} instance in a mesh namespace and configure it to send tracing data to a tracing platform backend service.
 
-//Still true for 2.6
-//Asked in forum-ocp-tracing channel 06/24/2024, verified 06/25/2024
-[NOTE]
-====
-{TempoName} Stack is not supported on {ibm-z-title}.
-====
-
 [id="jaeger-default-setting-change-ossm-2-6-0_{context}"]
 == {JaegerName} default setting change
 //also included in "Upgrading --> Upgrading 2.5 to 2.6" but added here for increased visibility.
diff --git a/modules/ossm-release-2-6-4.adoc b/modules/ossm-release-2-6-4.adoc
index 551f286c7602..00949da4022b 100644
--- a/modules/ossm-release-2-6-4.adoc
+++ b/modules/ossm-release-2-6-4.adoc
@@ -11,8 +11,6 @@ This release of {SMProductName} updates the {SMProductName} Operator version to
 
 This release addresses Common Vulnerabilities and Exposures (CVEs) and is supported on {product-title} 4.14 and later.
 
-include::snippets/ossm-current-version-support-snippet.adoc[]
-
 The most current version of the {KialiProduct} can be used with all supported versions of {SMProductName}. The version of {SMProductShortName} is specified by using the `ServiceMeshControlPlane` resource. The version of {SMProductShortName} automatically ensures a compatible version of Kiali.
 
 [id=ossm-release-2-6-4-components_{context}]
diff --git a/modules/ossm-release-2-6-5.adoc b/modules/ossm-release-2-6-5.adoc
new file mode 100644
index 000000000000..e178078c7ff6
--- /dev/null
+++ b/modules/ossm-release-2-6-5.adoc
@@ -0,0 +1,40 @@
+////
+Module included in the following assemblies:
+* service_mesh/v2x/servicemesh-release-notes.adoc
+////
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-6-5_{context}"]
+= {SMProductName} version 2.6.5
+
+This release of {SMProductName} updates the {SMProductName} Operator version to 2.6.5, and includes the following `ServiceMeshControlPlane` resource version updates: 2.6.5, 2.5.8, and 2.4.14.
+
+This release addresses Common Vulnerabilities and Exposures (CVEs) and is supported on {product-title} 4.14 and later.
+
+You can use the most current version of the {KialiProduct} with all supported versions of {SMProductName}. The version of {SMProductShortName} is specified by using the `ServiceMeshControlPlane` resource. The version of {SMProductShortName} automatically ensures a compatible version of Kiali.
+
+[id=ossm-release-2-6-5-components_{context}]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.20.8
+
+|Envoy Proxy
+|1.28.7
+
+|Kiali Server
+|1.73.18
+|===
+
+[id="ossm-new-features-2-6-5_{context}"]
+== New features
+
+* {TempoName} Stack is now supported on {ibm-z-title}.
+
+[id="ossm-fixed-issues-2-6-5_{context}"]
+== Fixed issues
+
+* https://issues.redhat.com/browse/OSSM-8608[OSSM-8608] Previously, terminating a Container Network Interface (CNI) pod during the installation phase while copying binaries could leave Istio-CNI temporary files on the node file system. Repeated occurrences could eventually fill up the node disk space. Now, while terminating a CNI pod during the installation phase, existing temporary files are deleted before copying the CNI binary, ensuring that only one temporary file per Istio version exists on the node file system.
\ No newline at end of file
diff --git a/modules/ossm-release-2-6-6.adoc b/modules/ossm-release-2-6-6.adoc
new file mode 100644
index 000000000000..24fc1af0b85f
--- /dev/null
+++ b/modules/ossm-release-2-6-6.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+//
+// * service_mesh/v2x/servicemesh-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="ossm-release-2-6-6_{context}"]
+= {SMProductName} version 2.6.6
+
+This release of {SMProductName} updates the {SMProductName} Operator version to 2.6.6, and includes the following `ServiceMeshControlPlane` resource version updates: 2.6.6, 2.5.9, and 2.4.15.
+
+This release addresses Common Vulnerabilities and Exposures (CVEs) and is supported on {product-title} 4.14 and later.
+
+include::snippets/ossm-current-version-support-snippet.adoc[]
+
+You can use the most current version of the {KialiProduct} with all supported versions of {SMProductName}. The version of {SMProductShortName} is specified by using the `ServiceMeshControlPlane` resource. The version of {SMProductShortName} automatically ensures a compatible version of Kiali.
+
+[id="ossm-release-2-6-6-components_{context}"]
+== Component updates
+
+|===
+|Component |Version
+
+|Istio
+|1.20.8
+
+|Envoy Proxy
+|1.28.7
+
+|Kiali Server
+|1.73.19
+|===
+
+[id="ossm-new-features-2-6-6_{context}"]
+== New features
+
+* With this update, the Operator for {SMProductName} 2.6 is renamed to {SMProductName} 2 to align with the release of {SMProductName} 3.0 and improve clarity.
\ No newline at end of file
diff --git a/modules/ossm-remove-cleanup.adoc b/modules/ossm-remove-cleanup.adoc
index e9a6a2a960a0..c6955458e762 100644
--- a/modules/ossm-remove-cleanup.adoc
+++ b/modules/ossm-remove-cleanup.adoc
@@ -16,7 +16,7 @@ You can manually remove resources left behind after removing the {SMProductName}
 
 .Procedure
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Log in to the {product-title} CLI as a cluster administrator.
 
 . Run the following commands to clean up resources after uninstalling the Operators. If you intend to keep using {JaegerShortName} as a stand-alone service without service mesh, do not delete the Jaeger resources.
@@ -75,10 +75,10 @@ $ oc delete cm -n openshift-operators -lmaistra-version
 ----
 $ oc delete sa -n openshift-operators -lmaistra-version
 ----
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Hiding in ROSA/OSD, dedicated-admins cannot delete resource "mutatingwebhookconfigurations" or "validatingwebhookconfigurations" or "customresourcedefinitions"
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . Log in to the {product-title} CLI as a cluster administrator.
 
 . Run the following commands to clean up resources after uninstalling the Operators. If you intend to keep using {JaegerShortName} as a stand-alone service without service mesh, do not delete the Jaeger resources.
@@ -127,4 +127,4 @@ $ oc delete cm -n openshift-operators istio-cni-config istio-cni-config-v2-3
 ----
 $ oc delete sa -n openshift-operators istio-cni
 ----
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/modules/ossm-rn-fixed-issues.adoc b/modules/ossm-rn-fixed-issues.adoc
index 67ad1f93d18c..917a0c15bbcd 100644
--- a/modules/ossm-rn-fixed-issues.adoc
+++ b/modules/ossm-rn-fixed-issues.adoc
@@ -229,11 +229,11 @@ Upgrading the operator to 2.0 might break client tools that read the SMCP status
 +
 This also causes the READY and STATUS columns to be empty when you run `oc get servicemeshcontrolplanes.v1.maistra.io`.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa-hcp,openshift-rosa,openshift-dedicated[]
 * link:https://issues.jboss.org/browse/MAISTRA-1947[MAISTRA-1947] _Technology Preview_ Updates to ServiceMeshExtensions are not applied.
 +
 Workaround: Remove and recreate the `ServiceMeshExtensions`.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp,openshift-rosa,openshift-dedicated[]
 
 * link:https://issues.redhat.com/browse/MAISTRA-1983[MAISTRA-1983] _Migration to 2.0_ Upgrading to 2.0.0 with an existing invalid `ServiceMeshControlPlane` cannot easily be repaired. The invalid items in the `ServiceMeshControlPlane` resource caused an unrecoverable error. The fix makes the errors recoverable. You can delete the invalid resource and replace it with a new one or edit the resource to fix the errors. For more information about editing your resource, see [Configuring the Red Hat OpenShift Service Mesh installation].
 
diff --git a/modules/ossm-rn-known-issues.adoc b/modules/ossm-rn-known-issues.adoc
index e8badf76e40e..87c3a28d04d7 100644
--- a/modules/ossm-rn-known-issues.adoc
+++ b/modules/ossm-rn-known-issues.adoc
@@ -21,7 +21,7 @@ These limitations exist in {SMProductName}:
 
 * The first time you access related services such as {JaegerShortName} and Grafana, from the Kiali console, you must accept the certificate and re-authenticate using your {product-title} login credentials. This happens due to an issue with how the framework displays embedded pages in the console.
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 * The Bookinfo sample application cannot be installed on {ibm-power-name}, {ibm-z-name}, and {ibm-linuxone-name}.
 
 * WebAssembly extensions are not supported on {ibm-power-name}, {ibm-z-name}, and {ibm-linuxone-name}.
@@ -29,7 +29,7 @@ ifndef::openshift-rosa[]
 * LuaJIT is not supported on {ibm-power-name}, {ibm-z-name}, and {ibm-linuxone-name}.
 
 * Single stack IPv6 support is not available on {ibm-power-name}, {ibm-z-name}, and {ibm-linuxone-name}.
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
 [id="ossm-rn-known-issues-ossm_{context}"]
 == {SMProductShortName} known issues
@@ -131,7 +131,7 @@ For example, if you create a namespace called 'akube-a' and add it to the Servic
 +
 Workaround: Change the Kiali Custom Resource setting so it prefixes the setting with a carat (^). For example:
 +
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 [source,yaml]
 ----
 api:
@@ -143,9 +143,9 @@ api:
     - "^ibm.*"
     - "^kiali-operator"
 ----
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa-hcp,openshift-rosa[]
 [source,yaml]
 ----
 api:
@@ -156,13 +156,13 @@ api:
     - "^openshift.*"
     - "^kiali-operator"
 ----
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 +
 * link:https://issues.redhat.com/browse/MAISTRA-2692[MAISTRA-2692] With Mixer removed, custom metrics that have been defined in {SMProductShortName} 2.0.x cannot be used in 2.1. Custom metrics can be configured using `EnvoyFilter`. Red Hat is unable to support `EnvoyFilter` configuration except where explicitly documented. This is due to tight coupling with the underlying Envoy APIs, meaning that backward compatibility cannot be maintained.
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 
 * link:https://issues.redhat.com/browse/MAISTRA-2648[MAISTRA-2648] Service mesh extensions are currently not compatible with meshes deployed on {ibm-z-name}.
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
 * link:https://issues.jboss.org/browse/MAISTRA-1959[MAISTRA-1959] _Migration to 2.0_ Prometheus scraping (`spec.addons.prometheus.scrape` set to `true`) does not work when mTLS is enabled. Additionally, Kiali displays extraneous graph data when mTLS is disabled.
 +
diff --git a/modules/ossm-rn-new-features-1x.adoc b/modules/ossm-rn-new-features-1x.adoc
index 00da59bfe4f2..9c4a824d34ab 100644
--- a/modules/ossm-rn-new-features-1x.adoc
+++ b/modules/ossm-rn-new-features-1x.adoc
@@ -164,7 +164,7 @@ There are manual steps that must be completed to address CVE-2021-29492 and CVE-
 [id="manual-updates-cve-2021-29492_{context}"]
 === Manual updates required by CVE-2021-29492 and CVE-2021-31920
 
-Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (``%2F` or ``%5C`) could potentially bypass an Istio authorization policy when path-based authorization rules are used.
+Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (`%2F` or `%5C`) could potentially bypass an Istio authorization policy when path-based authorization rules are used.
 
 For example, assume an Istio cluster administrator defines an authorization DENY policy to reject the request at path `/admin`. A request sent to the URL path `//admin` will NOT be rejected by the authorization policy.
 
diff --git a/modules/ossm-rn-new-features.adoc b/modules/ossm-rn-new-features.adoc
index 4b7267830f07..a639fa58ce36 100644
--- a/modules/ossm-rn-new-features.adoc
+++ b/modules/ossm-rn-new-features.adoc
@@ -258,9 +258,9 @@ This release of {SMProductName} addresses Common Vulnerabilities and Exposures (
 
 == New features {SMProductName} version 2.4.3
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * The {SMProductName} Operator is now available on ARM-based clusters as a Technology Preview feature.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * The `envoyExtAuthzGrpc` field has been added, which is used to configure an external authorization provider using the gRPC API.
 * Common Vulnerabilities and Exposures (CVEs) have been addressed.
 * This release is supported on {product-title} 4.10 and newer versions.
@@ -287,13 +287,13 @@ endif::openshift-rosa,openshift-dedicated[]
 //COMPONENTS ABOVE MAY NEED TO BE UPDATED FOR 2.4.3
 
 // Tech Preview features not supported in OSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 === {SMProductName} operator to ARM-based clusters
 :FeatureName: {SMProductName} operator to ARM based clusters
 include::snippets/technology-preview.adoc[]
 
 This release makes the {SMProductName} Operator available on ARM-based clusters as a Technology Preview feature. Images are available for Istio, Envoy, Prometheus, Kiali, and Grafana. Images are not available for Jaeger, so Jaeger must be disabled as a {SMProductShortName} add-on.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 === Remote Procedure Calls (gRPC) API support for external authorization configuration
 
@@ -429,13 +429,13 @@ This enhancement introduces generally available support for single stack IPv6 cl
 Single stack IPv6 support is not available on {ibm-power-name}, {ibm-z-name}, and {ibm-linuxone-name}.
 ====
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 === {product-title} Gateway API support
 :FeatureName: {product-title} Gateway API support
 include::snippets/technology-preview.adoc[]
 
 This enhancement introduces an updated Technology Preview version of the {product-title} Gateway API. By default, the {product-title} Gateway API is disabled.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ==== Enabling {product-title} Gateway API
 To enable the {product-title} Gateway API, set the value of the `enabled` field to `true` in the `techPreview.gatewayAPI` specification of the `ServiceMeshControlPlane` resource.
@@ -463,7 +463,7 @@ spec:
             PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"
 ----
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 
 === Control plane deployment on infrastructure nodes
 {SMProductShortName} control plane deployment is now supported and documented on OpenShift infrastructure nodes. For more information, see the following documentation:
@@ -471,16 +471,16 @@ ifndef::openshift-rosa[]
 * Configuring all {SMProductShortName} control plane components to run on infrastructure nodes
 * Configuring individual {SMProductShortName} control plane components to run on infrastructure nodes
 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 === Istio 1.16 support
 {SMProductShortName} 2.4 is based on Istio 1.16, which brings in new features and product enhancements. While many Istio 1.16 features are supported, the following exceptions should be noted:
 
 * HBONE protocol for sidecars is an experimental feature that is not supported.
 * {SMProductShortName} on ARM64 architecture is not supported.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * OpenTelemetry API remains a Technology Preview feature.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [id="new-features-ossm-2-3-11"]
 == New features {SMProductName} version 2.3.11
@@ -778,20 +778,20 @@ This release introduces generally available support for Gateway injection. Gatew
 {SMProductShortName} 2.3 is based on Istio 1.14, which brings in new features and product enhancements. While many Istio 1.14 features are supported, the following exceptions should be noted:
 
 * ProxyConfig API is supported with the exception of the image field.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Telemetry API is a Technology Preview feature.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * SPIRE runtime is not a supported feature.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 === OpenShift Service Mesh Console
 :FeatureName: OpenShift Service Mesh Console
 include::snippets/technology-preview.adoc[]
 
 This release introduces a Technology Preview version of the {product-title} Service Mesh Console, which integrates the Kiali interface directly into the OpenShift web console. For additional information, see link:https://cloud.redhat.com/blog/introducing-the-openshift-service-mesh-console-a-developer-preview[Introducing the OpenShift Service Mesh Console (A Technology Preview)]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 ===  Cluster-wide deployment
 :FeatureName: Cluster-wide deployment
 include::snippets/technology-preview.adoc[]
@@ -802,7 +802,7 @@ This release introduces cluster-wide deployment as a Technology Preview feature.
 ====
 This cluster-wide deployment documentation is only applicable for control planes deployed using SMCP v2.3. cluster-wide deployments created using SMCP v2.3 are not compatible with cluster-wide deployments created using SMCP v2.4.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ==== Configuring cluster-wide deployment
 
@@ -1163,7 +1163,7 @@ This release marks the end of support for {SMProductShortName} Control Planes ba
 * External control plane is not a supported feature.
 * Gateway injection is not a supported feature.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 === Kubernetes Gateway API
 :FeatureName: Kubernetes Gateway API
 include::snippets/technology-preview.adoc[]
@@ -1171,7 +1171,7 @@ include::snippets/technology-preview.adoc[]
 Kubernetes Gateway API is a technology preview feature that is disabled by default. If the Kubernetes API deployment controller is disabled, you must manually deploy and link an ingress gateway to the created Gateway object.
 
 If the Kubernetes API deployment controller is enabled, then an ingress gateway automatically deploys when a Gateway object is created.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ==== Installing the Gateway API CRDs
 The Gateway API CRDs do not come preinstalled by default on OpenShift clusters. Install the CRDs prior to enabling Gateway API support in the SMCP.
@@ -1484,12 +1484,12 @@ New Custom Resource Definitions (CRDs) have been added to support federating ser
 
 * `ImportedServiceSet` - Defines which services for a given `ServiceMeshPeer` are imported from the peer mesh. These services must also be made available by the peer’s `ExportedServiceMeshSet` resource.
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 Service Mesh Federation is not supported between clusters on Red Hat OpenShift Service on AWS (ROSA), Azure Red Hat OpenShift (ARO), or OpenShift Dedicated (OSD).
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-rosa-hcp,openshift-rosa[]
 Service Mesh Federation is not supported between clusters on Red Hat OpenShift Service on AWS (ROSA) or OpenShift Dedicated (OSD).
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
 === OVN-Kubernetes Container Network Interface (CNI) generally available
 
@@ -1707,16 +1707,16 @@ spec:
 
 This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 == {SMProductName} on {product-dedicated} and Microsoft Azure Red Hat OpenShift
 
 {SMProductName} is now supported through {product-dedicated} and Microsoft Azure Red Hat OpenShift.
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-rosa-hcp,openshift-rosa[]
 == {SMProductName} on {product-dedicated}
 
 {SMProductName} is now supported through {product-dedicated}.
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
 == New features {SMProductName} 2.0.6
 
@@ -1903,12 +1903,12 @@ In addition, this release has the following new features:
 
 == New features {SMProductName} 2.0.2
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa-hcp,openshift-rosa[]
 This release of {SMProductName} adds support for {ibm-z-name} and {ibm-power-name} Systems. It also addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
+ifdef::openshift-rosa-hcp,openshift-rosa[]
 This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
-endif::openshift-rosa[]
+endif::openshift-rosa-hcp,openshift-rosa[]
 
 == New features {SMProductName} 2.0.1
 
@@ -1932,6 +1932,6 @@ In addition, this release has the following new features:
 
 * Updates the ServiceMeshControlPlane resource to v2 with a streamlined configuration to make it easier to manage the {SMProductShortName} Control Plane.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa-hcp,openshift-rosa,openshift-dedicated[]
 * Introduces WebAssembly extensions as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] feature.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp,openshift-rosa,openshift-dedicated[]
diff --git a/modules/ossm-servicemesh-overview.adoc b/modules/ossm-servicemesh-overview.adoc
index 81e11c6213e8..9b21bb6a557c 100644
--- a/modules/ossm-servicemesh-overview.adoc
+++ b/modules/ossm-servicemesh-overview.adoc
@@ -11,3 +11,8 @@ Module included in the following assemblies:
 Microservice architectures split the work of enterprise applications into modular services, which can make scaling and maintenance easier. However, as an enterprise application built on a microservice architecture grows in size and complexity, it becomes difficult to understand and manage. {SMProductShortName} can address those architecture problems by capturing or intercepting traffic between services and can modify, redirect, or create new requests to other services.
 
 {SMProductShortName}, which is based on the open source link:https://istio.io/[Istio project], provides an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provides more complex operational functionality, including A/B testing, canary releases, access control, and end-to-end authentication.
+
+[NOTE]
+====
+{SMProductName} 3 is generally available. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_mesh/[{SMProductName} 3.0].
+====
\ No newline at end of file
diff --git a/modules/ossm-supported-configurations.adoc b/modules/ossm-supported-configurations.adoc
index d0a87f977dda..89b3e08d6802 100644
--- a/modules/ossm-supported-configurations.adoc
+++ b/modules/ossm-supported-configurations.adoc
@@ -16,12 +16,12 @@ The following configurations are supported for the current release of {SMProduct
 The {SMProductName} Operator supports multiple versions of the `ServiceMeshControlPlane` resource. Version {MaistraVersion} {SMProductShortName} control planes are supported on the following platform versions:
 
 // Updating the list so that all 4 supported platforms appear in all versions; the wording works better that way and it removed the repeated ROSA listing.
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Red Hat OpenShift Container Platform version 4.10 or later
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Red Hat {product-title} version 4.10 or later
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * {product-dedicated} version 4
 * Azure Red Hat OpenShift (ARO) version 4
 * Red Hat OpenShift Service on AWS (ROSA)
@@ -46,14 +46,14 @@ Explicitly unsupported cases include:
 [id="ossm-supported-configurations-sm_{context}"]
 == Supported configurations for {SMProductShortName}
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 * This release of {SMProductName} is only available on {product-title} x86_64, {ibm-z-name}, and {ibm-power-name}.
 ** {ibm-z-name} is only supported on {product-title} 4.10 and later.
 ** {ibm-power-name} is only supported on {product-title} 4.10 and later.
-endif::openshift-rosa[]
-ifdef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 * This release of {SMProductName} is only available on {product-title} x86_64.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 * Configurations where all {SMProductShortName} components are contained within a single {product-title} cluster.
 * Configurations that do not integrate external services such as virtual machines.
 * {SMProductName} does not support `EnvoyFilter` configuration except where explicitly documented.
diff --git a/modules/ossm-tutorial-bookinfo-install.adoc b/modules/ossm-tutorial-bookinfo-install.adoc
index ec10471f0e60..9116f44c74de 100644
--- a/modules/ossm-tutorial-bookinfo-install.adoc
+++ b/modules/ossm-tutorial-bookinfo-install.adoc
@@ -15,20 +15,20 @@ This tutorial walks you through how to create a sample application by creating a
 * {product-title} 4.1 or higher installed.
 * {SMProductName} {SMProductVersion} installed.
 * Access to the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 The Bookinfo sample application cannot be installed on {ibm-z-name} and {ibm-power-name}.
 ====
 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 The commands in this section assume the {SMProductShortName} control plane project is `istio-system`.  If you installed the control plane in another namespace, edit each command before you run it.
diff --git a/modules/ossm-tutorial-bookinfo-verify-install.adoc b/modules/ossm-tutorial-bookinfo-verify-install.adoc
index baa5d94b6aa1..28ef693828c9 100644
--- a/modules/ossm-tutorial-bookinfo-verify-install.adoc
+++ b/modules/ossm-tutorial-bookinfo-verify-install.adoc
@@ -14,12 +14,12 @@ To confirm that the sample Bookinfo application was successfully deployed, perfo
 
 * {SMProductName} installed.
 * Complete the steps for installing the Bookinfo sample app.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure from CLI
 
diff --git a/modules/ossm-validate-smcp-cli.adoc b/modules/ossm-validate-smcp-cli.adoc
index f3c507e95de4..7f59131c9035 100644
--- a/modules/ossm-validate-smcp-cli.adoc
+++ b/modules/ossm-validate-smcp-cli.adoc
@@ -11,12 +11,12 @@ You can validate the creation of the `ServiceMeshControlPlane` from the command
 
 * The {SMProductName} Operator must be installed.
 * Access to the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
diff --git a/modules/ossm-validate-smcp-kiali.adoc b/modules/ossm-validate-smcp-kiali.adoc
index fd6b5733ba85..69f83876250a 100644
--- a/modules/ossm-validate-smcp-kiali.adoc
+++ b/modules/ossm-validate-smcp-kiali.adoc
@@ -12,12 +12,12 @@ You can use the Kiali console to validate your {SMProductShortName} installation
 
 * The {SMProductName} Operator must be installed.
 * Access to the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as`cluster-admin`.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You are logged in to {product-title} as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
diff --git a/modules/otel-autoinstrumentation.adoc b/modules/otel-autoinstrumentation.adoc
new file mode 100644
index 000000000000..4fe89f6e4e53
--- /dev/null
+++ b/modules/otel-autoinstrumentation.adoc
@@ -0,0 +1,21 @@
+// Module included in the following assemblies:
+//
+// * observability/otel/otel-configuration-of-instrumentation.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="otel-autoinstrumentation_{context}"]
+= Auto-instrumentation in the {OTELOperator}
+
+Auto-instrumentation in the {OTELOperator} can automatically instrument an application without manual code changes. Developers and administrators can monitor applications with minimal effort and changes to the existing codebase.
+
+Auto-instrumentation runs as follows:
+
+. The {OTELOperator} injects an init-container, or a sidecar container for Go, to add the instrumentation libraries for the programming language of the instrumented application.
+
+. The {OTELOperator} sets the required environment variables in the application's runtime environment. These variables configure the auto-instrumentation libraries to collect traces, metrics, and logs and send them to the appropriate OpenTelemetry Collector or another telemetry backend.
+
+. The injected libraries automatically instrument your application by connecting to known frameworks and libraries, such as web servers or database clients, to collect telemetry data. The source code of the instrumented application is not modified.
+
+. Once the application is running with the injected instrumentation, the application automatically generates telemetry data, which is sent to a designated OpenTelemetry Collector or an external OTLP endpoint for further processing.
+
+Auto-instrumentation enables you to start collecting telemetry data quickly without having to manually integrate the OpenTelemetry SDK into your application code. However, some applications might require specific configurations or custom manual instrumentation.
diff --git a/modules/otel-collector-config-options.adoc b/modules/otel-collector-config-options.adoc
index 77a42a900d2e..83c437b48006 100644
--- a/modules/otel-collector-config-options.adoc
+++ b/modules/otel-collector-config-options.adoc
@@ -19,7 +19,7 @@ You can define multiple instances of components in a custom resource YAML file.
 .Example of the OpenTelemetry Collector custom resource file
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: cluster-collector
@@ -29,7 +29,7 @@ spec:
   observability:
     metrics:
       enableMetrics: true
-  config: |
+  config:
     receivers:
       otlp:
         protocols:
@@ -38,7 +38,7 @@ spec:
     processors: {}
     exporters:
       otlp:
-        endpoint: jaeger-production-collector-headless.tracing-system.svc:4317
+        endpoint: otel-collector-headless.tracing-system.svc:4317
         tls:
           ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
       prometheus:
@@ -50,7 +50,7 @@ spec:
         traces:
           receivers: [otlp]
           processors: []
-          exporters: [jaeger]
+          exporters: [otlp]
         metrics:
           receivers: [otlp]
           processors: []
@@ -85,7 +85,7 @@ spec:
 
 |extensions:
 |Optional components for tasks that do not involve processing telemetry data.
-|`bearertokenauth`, `oauth2client`, `jaegerremotesamplin`, `pprof`, `health_check`, `memory_ballast`, `zpages`
+|`bearertokenauth`, `oauth2client`, `jaegerremotesampling`, `pprof`, `health_check`, `memory_ballast`, `zpages`
 |None
 
 |service:
diff --git a/modules/otel-config-instrumentation.adoc b/modules/otel-config-instrumentation.adoc
index 6485ddf6a561..447f2f868c04 100644
--- a/modules/otel-config-instrumentation.adoc
+++ b/modules/otel-config-instrumentation.adoc
@@ -8,11 +8,9 @@
 
 The {OTELName} can inject and configure the OpenTelemetry auto-instrumentation libraries into your workloads. Currently, the project supports injection of the instrumentation libraries from Go, Java, Node.js, Python, .NET, and the Apache HTTP Server (`httpd`).
 
-Auto-instrumentation in OpenTelemetry refers to the capability where the framework automatically instruments an application without manual code changes. This enables developers and administrators to get observability into their applications with minimal effort and changes to the existing codebase.
-
 [IMPORTANT]
 ====
-The {OTELName} Operator only supports the injection mechanism of the instrumentation libraries but does not support instrumentation libraries or upstream images. Customers can build their own instrumentation images or use community images.
+The {OTELOperator} only supports the injection mechanism of the instrumentation libraries but does not support instrumentation libraries or upstream images. Customers can build their own instrumentation images or use community images.
 ====
 
 [id="otel-instrumentation-options_{context}"]
diff --git a/modules/otel-config-receive-metrics-monitoring-stack.adoc b/modules/otel-config-receive-metrics-monitoring-stack.adoc
index 077a1bf7568f..90aa3a06215b 100644
--- a/modules/otel-config-receive-metrics-monitoring-stack.adoc
+++ b/modules/otel-config-receive-metrics-monitoring-stack.adoc
@@ -32,7 +32,7 @@ metadata:
   annotations:
     service.beta.openshift.io/inject-cabundle: "true" # <2>
 ---
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -47,7 +47,7 @@ spec:
       configMap:
         name: cabundle
   mode: deployment
-  config: |
+  config:
     receivers:
       prometheus: # <3>
         config:
diff --git a/modules/otel-config-send-metrics-monitoring-stack.adoc b/modules/otel-config-send-metrics-monitoring-stack.adoc
index aeb05fa8cbc3..a9a471e572e1 100644
--- a/modules/otel-config-send-metrics-monitoring-stack.adoc
+++ b/modules/otel-config-send-metrics-monitoring-stack.adoc
@@ -11,14 +11,14 @@ You can configure the `OpenTelemetryCollector` custom resource (CR) to create a
 .Example of the OpenTelemetry Collector CR with the Prometheus exporter
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 spec:
   mode: deployment
   observability:
     metrics:
       enableMetrics: true # <1>
-  config: |
+  config:
     exporters:
       prometheus:
         endpoint: 0.0.0.0:8889
@@ -30,7 +30,6 @@ spec:
           address: ":8888"
       pipelines:
         metrics:
-          receivers: [otlp]
           exporters: [prometheus]
 ----
 <1> Configures the {OTELOperator} to create the Prometheus `ServiceMonitor` CR or `PodMonitor` CR to scrape the Collector's internal metrics endpoint and the Prometheus exporter metrics endpoints.
diff --git a/modules/otel-forwarding-logs-to-tempostack.adoc b/modules/otel-forwarding-logs-to-tempostack.adoc
index 9abfb9095b63..d122347c663c 100644
--- a/modules/otel-forwarding-logs-to-tempostack.adoc
+++ b/modules/otel-forwarding-logs-to-tempostack.adoc
@@ -6,12 +6,7 @@
 [id="otel-forwarding-logs-to-tempostack_{context}"]
 = Forwarding logs to a LokiStack instance
 
-You can deploy the OpenTelemetry Collector with Collector components to forward logs to a LokiStack instance.
-
-This use of the Loki Exporter is a temporary Technology Preview feature that is planned to be replaced with the publication of an improved solution in which the Loki Exporter is replaced with the OTLP HTTP Exporter.
-
-:FeatureName: The Loki Exporter
-include::snippets/technology-preview.adoc[leveloffset=+1]
+You can deploy the OpenTelemetry Collector to forward logs to a LokiStack instance.
 
 .Prerequisites
 
@@ -99,56 +94,30 @@ spec:
           grpc: {}
           http: {}
     processors:
-      k8sattributes:
-        auth_type: "serviceAccount"
-        passthrough: false
-        extract:
-          metadata:
-            - k8s.pod.name
-            - k8s.container.name
-            - k8s.namespace.name
-          labels:
-          - tag_name: app.label.component
-            key: app.kubernetes.io/component
-            from: pod
-        pod_association:
-          - sources:
-              - from: resource_attribute
-                name: k8s.pod.name
-              - from: resource_attribute
-                name: k8s.container.name
-              - from: resource_attribute
-                name: k8s.namespace.name
-          - sources:
-              - from: connection
+      k8sattributes: {}
       resource:
         attributes: # <1>
-          - key: loki.format # <2>
-            action: insert
-            value: json
-          - key:  kubernetes_namespace_name
+          - key:  kubernetes.namespace_name
             from_attribute: k8s.namespace.name
             action: upsert
-          - key:  kubernetes_pod_name
+          - key:  kubernetes.pod_name
             from_attribute: k8s.pod.name
             action: upsert
-          - key: kubernetes_container_name
+          - key: kubernetes.container_name
             from_attribute: k8s.container.name
             action: upsert
           - key: log_type
             value: application
             action: upsert
-          - key: loki.resource.labels # <3>
-            value: log_type, kubernetes_namespace_name, kubernetes_pod_name, kubernetes_container_name
-            action: insert
       transform:
         log_statements:
           - context: log
             statements:
               - set(attributes["level"], ConvertCase(severity_text, "lower"))
     exporters:
-      loki:
-        endpoint: https://logging-loki-gateway-http.openshift-logging.svc.cluster.local:8080/api/logs/v1/application/loki/api/v1/push # <4>
+      otlphttp:
+        endpoint: https://logging-loki-gateway-http.openshift-logging.svc.cluster.local:8080/api/logs/v1/application/otlp
+        encoding: json
         tls:
           ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
         auth:
@@ -156,23 +125,20 @@ spec:
       debug:
         verbosity: detailed
     service:
-      extensions: [bearertokenauth] # <5>
+      extensions: [bearertokenauth] # <2>
       pipelines:
         logs:
           receivers: [otlp]
           processors: [k8sattributes, transform, resource]
-          exporters: [loki] # <6>
+          exporters: [otlphttp] # <3>
         logs/test:
           receivers: [otlp]
           processors: []
           exporters: [debug]
 ----
-<1> Provides the following resource attributes to be used by the web console: `kubernetes_namespace_name`, `kubernetes_pod_name`, `kubernetes_container_name`, and `log_type`. If you specify them as values for this `loki.resource.labels` attribute, then the Loki Exporter processes them as labels.
-<2> Configures the format of Loki logs. Supported values are `json`, `logfmt` and `raw`.
-<3> Configures which resource attributes are processed as Loki labels.
-<4> Points the Loki Exporter to the gateway of the LokiStack `logging-loki` instance and uses the `application` tenant.
-<5> Enables the BearerTokenAuth Extension that is required by the Loki Exporter.
-<6> Enables the Loki Exporter to export logs from the Collector.
+<1> Provides the following resource attributes to be used by the web console: `kubernetes.namespace_name`, `kubernetes.pod_name`, `kubernetes.container_name`, and `log_type`.
+<2> Enables the BearerTokenAuth Extension that is required by the OTLP HTTP Exporter.
+<3> Enables the OTLP HTTP Exporter to export logs from the Collector.
 
 [TIP]
 ====
diff --git a/modules/otel-forwarding-traces.adoc b/modules/otel-forwarding-traces.adoc
index 8cdcfbac29b4..2dcdd520ddb4 100644
--- a/modules/otel-forwarding-traces.adoc
+++ b/modules/otel-forwarding-traces.adoc
@@ -70,14 +70,14 @@ roleRef:
 .Example OpenTelemetryCollector
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
 spec:
   mode: deployment
   serviceAccount: otel-collector-deployment
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
@@ -113,7 +113,7 @@ spec:
           exporters: [otlp]
 ----
 <1> The Collector exporter is configured to export OTLP and points to the Tempo distributor endpoint, `"tempo-simplest-distributor:4317"` in this example, which is already created.
-<2> The Collector is configured with a receiver for Jaeger traces, OpenCensus traces over the OpenCensus protocol, Zipkin traces over the Zipkin protocol, and OTLP traces over the GRPC protocol.
+<2> The Collector is configured with a receiver for Jaeger traces, OpenCensus traces over the OpenCensus protocol, Zipkin traces over the Zipkin protocol, and OTLP traces over the gRPC protocol.
 
 [TIP]
 ====
diff --git a/modules/otel-migrating-from-jaeger-with-sidecars.adoc b/modules/otel-migrating-from-jaeger-with-sidecars.adoc
index e43afd16a584..71f149922e13 100644
--- a/modules/otel-migrating-from-jaeger-with-sidecars.adoc
+++ b/modules/otel-migrating-from-jaeger-with-sidecars.adoc
@@ -19,14 +19,14 @@ The {OTELShortName} Operator supports sidecar injection into deployment workload
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
   namespace: <otel-collector-namespace>
 spec:
   mode: sidecar
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
diff --git a/modules/otel-migrating-from-jaeger-without-sidecars.adoc b/modules/otel-migrating-from-jaeger-without-sidecars.adoc
index 32816326d993..09e578dc967b 100644
--- a/modules/otel-migrating-from-jaeger-without-sidecars.adoc
+++ b/modules/otel-migrating-from-jaeger-without-sidecars.adoc
@@ -83,7 +83,7 @@ This collector will export traces to a TempoStack instance. You must create your
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -91,7 +91,7 @@ metadata:
 spec:
   mode: deployment
   serviceAccount: otel-collector-deployment
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
@@ -101,7 +101,7 @@ spec:
           thrift_http: {}
     processors:
       batch: {}
-      k8sattributes:
+      k8sattributes: {}
       memory_limiter:
         check_interval: 1s
         limit_percentage: 50
diff --git a/modules/otel-send-traces-and-metrics-to-otel-collector-with-sidecar.adoc b/modules/otel-send-traces-and-metrics-to-otel-collector-with-sidecar.adoc
index c8a7e630af2b..36a4113ff685 100644
--- a/modules/otel-send-traces-and-metrics-to-otel-collector-with-sidecar.adoc
+++ b/modules/otel-send-traces-and-metrics-to-otel-collector-with-sidecar.adoc
@@ -76,7 +76,7 @@ roleRef:
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -84,7 +84,7 @@ metadata:
 spec:
   serviceAccount: otel-collector-sidecar
   mode: sidecar
-  config: |
+  config:
     serviceAccount: otel-collector-sidecar
     receivers:
       otlp:
@@ -108,7 +108,7 @@ spec:
     service:
       pipelines:
         traces:
-          receivers: [jaeger]
+          receivers: [otlp]
           processors: [memory_limiter, resourcedetection, batch]
           exporters: [otlp]
 ----
diff --git a/modules/otel-send-traces-and-metrics-to-otel-collector-without-sidecar.adoc b/modules/otel-send-traces-and-metrics-to-otel-collector-without-sidecar.adoc
index 9a34d10c3dee..00202a499388 100644
--- a/modules/otel-send-traces-and-metrics-to-otel-collector-without-sidecar.adoc
+++ b/modules/otel-send-traces-and-metrics-to-otel-collector-without-sidecar.adoc
@@ -74,7 +74,7 @@ roleRef:
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -82,7 +82,7 @@ metadata:
 spec:
   mode: deployment
   serviceAccount: otel-collector-deployment
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
diff --git a/modules/otel-troubleshoot-collector-logs.adoc b/modules/otel-troubleshoot-collector-logs.adoc
index 8452ff816d9a..19a2ae07327e 100644
--- a/modules/otel-troubleshoot-collector-logs.adoc
+++ b/modules/otel-troubleshoot-collector-logs.adoc
@@ -14,7 +14,7 @@ You can get the logs for the OpenTelemetry Collector as follows.
 +
 [source,yaml]
 ----
-  config: |
+  config:
     service:
       telemetry:
         logs:
diff --git a/modules/otel-troubleshoot-logging-exporter-stdout.adoc b/modules/otel-troubleshoot-debug-exporter-stdout.adoc
similarity index 87%
rename from modules/otel-troubleshoot-logging-exporter-stdout.adoc
rename to modules/otel-troubleshoot-debug-exporter-stdout.adoc
index f7d81994392f..3eed406905b6 100644
--- a/modules/otel-troubleshoot-logging-exporter-stdout.adoc
+++ b/modules/otel-troubleshoot-debug-exporter-stdout.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="debug-exporter-to-stdout_{context}"]
-= Debug exporter
+= Debug Exporter
 
-You can configure the debug exporter to export the collected data to the standard output.
+You can configure the Debug Exporter to export the collected data to the standard output.
 
 .Procedure
 
@@ -14,7 +14,7 @@ You can configure the debug exporter to export the collected data to the standar
 +
 [source,yaml]
 ----
-  config: |
+  config:
     exporters:
       debug:
         verbosity: detailed
diff --git a/modules/otel-troubleshoot-metrics.adoc b/modules/otel-troubleshoot-metrics.adoc
index 1de46e33b1f4..a69579f8bbf8 100644
--- a/modules/otel-troubleshoot-metrics.adoc
+++ b/modules/otel-troubleshoot-metrics.adoc
@@ -25,7 +25,7 @@ The Operator creates a `<cr_name>-collector-monitoring` telemetry service that y
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     service:
       telemetry:
         metrics:
@@ -45,7 +45,7 @@ $ oc port-forward <collector_pod>
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 spec:
 # ...
diff --git a/modules/otel-troubleshooting-instrumentation-injection-into-your-workload.adoc b/modules/otel-troubleshooting-instrumentation-injection-into-your-workload.adoc
new file mode 100644
index 000000000000..cb26973abba4
--- /dev/null
+++ b/modules/otel-troubleshooting-instrumentation-injection-into-your-workload.adoc
@@ -0,0 +1,93 @@
+// Module included in the following assemblies:
+//
+// * observability/otel/otel-troubleshooting.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="otel-troubleshooting-instrumentation-injection-into-your-workload_{context}"]
+= Troubleshooting instrumentation injection into your workload
+
+To troubleshoot instrumentation injection, you can perform the following activities:
+
+* Checking if the `Instrumentation` object was created
+* Checking if the init-container started
+* Checking if the resources were deployed in the correct order
+* Searching for errors in the Operator logs
+* Double-checking the pod annotations
+
+.Procedure
+
+. Run the following command to verify that the `Instrumentation` object was successfully created:
++
+[source,terminal]
+----
+$ oc get instrumentation -n <workload_project> # <1>
+----
+<1> The namespace where the instrumentation was created.
+
+. Run the following command to verify that the `opentelemetry-auto-instrumentation` init-container successfully started, which is a prerequisite for instrumentation injection into workloads:
++
+[source,terminal]
+----
+$ oc get events -n <workload_project> # <1>
+----
+<1> The namespace where the instrumentation is injected for workloads.
++
+.Example output
+[source,terminal]
+----
+... Created container opentelemetry-auto-instrumentation
+... Started container opentelemetry-auto-instrumentation
+----
+
+. Verify that the resources were deployed in the correct order for the auto-instrumentation to work correctly. The correct order is to deploy the `Instrumentation` custom resource (CR) before the application. For information about the `Instrumentation` CR, see the section "Configuring the instrumentation".
++
+[NOTE]
+====
+When the pod starts, the {OTELOperator} checks the `Instrumentation` CR for annotations containing instructions for injecting auto-instrumentation. Generally, the Operator then adds an init-container to the application’s pod that injects the auto-instrumentation and environment variables into the application's container. If the `Instrumentation` CR is not available to the Operator when the application is deployed, the Operator is unable to inject the auto-instrumentation.
+====
++
+Fixing the order of deployment requires the following steps:
+
+.. Update the instrumentation settings.
+.. Delete the instrumentation object.
+.. Redeploy the application.
+
+. Run the following command to inspect the Operator logs for instrumentation errors:
++
+[source,terminal]
+----
+$ oc logs -l app.kubernetes.io/name=opentelemetry-operator --container manager -n openshift-opentelemetry-operator --follow
+----
+
+. Troubleshoot pod annotations for the instrumentations for a specific programming language. See the required annotation fields and values in "Configuring the instrumentation".
+
+.. Verify that the application pods that you are instrumenting are labeled with correct annotations and the appropriate auto-instrumentation settings have been applied.
++
+.Example
+----
+instrumentation.opentelemetry.io/inject-python="true"
+----
++
+.Example command to get pod annotations for an instrumented Python application
+[source,terminal]
+----
+$ oc get pods -n <workload_project> -o jsonpath='{range .items[?(@.metadata.annotations["instrumentation.opentelemetry.io/inject-python"]=="true")]}{.metadata.name}{"\n"}{end}'
+----
+
+.. Verify that the annotation applied to the instrumentation object is correct for the programming language that you are instrumenting.
+
+.. If there are multiple instrumentations in the same namespace, specify the name of the `Instrumentation` object in their annotations.
++
+.Example
+----
+instrumentation.opentelemetry.io/inject-nodejs: "<instrumentation_object>"
+----
+
+.. If the `Instrumentation` object is in a different namespace, specify the namespace in the annotation.
++
+.Example
+----
+instrumentation.opentelemetry.io/inject-nodejs: "<other_namespace>/<instrumentation_object>"
+----
+
+.. Verify that the `OpenTelemetryCollector` custom resource specifies the auto-instrumentation annotations under `spec.template.metadata.annotations`. If the auto-instrumentation annotations are in `spec.metadata.annotations` instead, move them into `spec.template.metadata.annotations`.
diff --git a/modules/otel-troubleshooting-telemetry-data-generation-by-the-instrumentation-libraries.adoc b/modules/otel-troubleshooting-telemetry-data-generation-by-the-instrumentation-libraries.adoc
new file mode 100644
index 000000000000..70669d230041
--- /dev/null
+++ b/modules/otel-troubleshooting-telemetry-data-generation-by-the-instrumentation-libraries.adoc
@@ -0,0 +1,31 @@
+// Module included in the following assemblies:
+//
+// * observability/otel/otel-troubleshooting.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="otel-troubleshooting-telemetry-data-generation-by-the-instrumentation-libraries_{context}"]
+= Troubleshooting telemetry data generation by the instrumentation libraries
+
+You can troubleshoot telemetry data generation by the instrumentation libraries by checking the endpoint, looking for errors in your application logs, and verifying that the Collector is receiving the telemetry data.
+
+.Procedure
+
+. Verify that the instrumentation is transmitting data to the correct endpoint:
++
+[source,terminal]
+----
+$ oc get instrumentation <instrumentation_name> -n <workload_project> -o jsonpath='{.spec.endpoint}'
+----
++
+The default endpoint `+http://localhost:4317+` for the `Instrumentation` object is only applicable to a Collector instance that is deployed as a sidecar in your application pod. If you are using an incorrect endpoint, correct it by editing the `Instrumentation` object and redeploying your application.
+
+. Inspect your application logs for error messages that might indicate that the instrumentation is malfunctioning:
++
+[source,terminal]
+----
+$ oc logs <application_pod> -n <workload_project>
+----
+
+. If the application logs contain error messages that indicate that the instrumentation might be malfunctioning, install the OpenTelemetry SDK and libraries locally. Then run your application locally and troubleshoot for issues between the instrumentation libraries and your application without {product-title}.
+
+. Use the Debug Exporter to verify that the telemetry data is reaching the destination OpenTelemetry Collector instance. For more information, see "Debug Exporter".
diff --git a/modules/persistent-storage-csi-drivers-supported.adoc b/modules/persistent-storage-csi-drivers-supported.adoc
index fc99f4a0d746..de1f0dac2141 100644
--- a/modules/persistent-storage-csi-drivers-supported.adoc
+++ b/modules/persistent-storage-csi-drivers-supported.adoc
@@ -35,45 +35,42 @@ In addition to the drivers listed in the following table, ROSA functions with CS
 endif::openshift-rosa,openshift-aro[]
 
 .Supported CSI drivers and features in {product-title}
-[cols=",^v,^v,^v,^v,^v width="100%",options="header"]
+[cols=",^v,^v,^v,^v,^v,^v width="100%",options="header"]
 |===
-|CSI driver |CSI volume snapshots  |CSI cloning  |CSI resize |Inline ephemeral volumes
-|AWS EBS | ✅ |  | ✅| 
-|AWS EFS |  |  |  | 
+|CSI driver |CSI volume snapshots  |CSI volume group snapshots ^[1]^ |CSI cloning  |CSI resize |Inline ephemeral volumes
+|AWS EBS | ✅ |  |  | ✅| 
+|AWS EFS |  |  |  |  | 
 ifndef::openshift-rosa[]
-|Google Compute Platform (GCP) persistent disk (PD)|  ✅|  ✅ | ✅|  
-|GCP Filestore | ✅ |   | ✅|  
+|Google Compute Platform (GCP) persistent disk (PD)|  ✅|  |✅^[2]^ | ✅|
+|GCP Filestore | ✅ |  | | ✅|  
 endif::openshift-rosa[]
 ifndef::openshift-dedicated,openshift-rosa[]
-|{ibm-power-server-name} Block |   |   | ✅ |  
-|{ibm-cloud-name} Block | ✅^[3]^ |   | ✅^[3]^|  
+|{ibm-power-server-name} Block |   |  |   | ✅ |  
+|{ibm-cloud-name} Block | ✅^[3]^ |  |   | ✅^[3]^|  
 endif::openshift-dedicated,openshift-rosa[]
-|LVM Storage | ✅ | ✅ | ✅ |  
+|LVM Storage | ✅ |  | ✅ | ✅ |  
 ifndef::openshift-dedicated,openshift-rosa[]
-|Microsoft Azure Disk | ✅ | ✅ | ✅|  
-|Microsoft Azure Stack Hub | ✅ | ✅ | ✅|  
-|Microsoft Azure File | ✅^[4]^  | ✅^[4]^ | ✅| ✅
-|OpenStack Cinder | ✅ | ✅ | ✅|  
-|OpenShift Data Foundation | ✅ | ✅ | ✅|  
-|OpenStack Manila | ✅ |   |  |  
-|Shared Resource |   |   |   | ✅
-|CIFS/SMB |   | ✅  |   |   
-|VMware vSphere | ✅^[1]^ |   | ✅^[2]^|  
+|Microsoft Azure Disk | ✅ |  | ✅ | ✅|  
+|Microsoft Azure Stack Hub | ✅ |  | ✅ | ✅|  
+|Microsoft Azure File | ✅^[4]^  |  | ✅^[4]^ | ✅| ✅
+|OpenStack Cinder | ✅ |  | ✅ | ✅|  
+|OpenShift Data Foundation | ✅ | ✅ | ✅ | ✅|  
+|OpenStack Manila | ✅ |  |   | ✅  |  
+|Shared Resource |   |  |   |   | ✅
+|CIFS/SMB |   |  | ✅  |   |   
+|VMware vSphere | ✅^[5]^ |  |   | ✅^[6]^|  
 endif::openshift-dedicated,openshift-rosa[]
 |===
 ifndef::openshift-dedicated,openshift-rosa[]
 --
 1. 
 
-* Requires vSphere version 7.0 Update 3 or later for both vCenter Server and ESXi.
-
-* Does not support fileshare volumes.
+:FeatureName: CSI volume group snapshots
+include::snippets/technology-preview.adoc[leveloffset=+1]
 
 2.
 
-* Offline volume expansion: minimum required vSphere version is 6.7 Update 3 P06
-
-* Online volume expansion: minimum required vSphere version is 7.0 Update 2.
+* Cloning is not supported on hyperdisk-balanced disks with storage pools.
 
 3.
 
@@ -87,5 +84,15 @@ ifndef::openshift-dedicated,openshift-rosa[]
 
 :FeatureName: Azure File CSI cloning and snapshot
 include::snippets/technology-preview.adoc[leveloffset=+1]
+
+5. 
+
+* Requires vSphere version 7.0 Update 3 or later for both vCenter Server and ESXi.
+
+* Does not support fileshare volumes.
+
+6.
+
+* Online expansion is supported from vSphere version 7.0 Update 2 and later.
 --
 endif::openshift-dedicated,openshift-rosa[]
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-gcp-file-install.adoc b/modules/persistent-storage-csi-gcp-file-install.adoc
index 17252eb3da9e..f8f4352a55fd 100644
--- a/modules/persistent-storage-csi-gcp-file-install.adoc
+++ b/modules/persistent-storage-csi-gcp-file-install.adoc
@@ -4,16 +4,17 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="persistent-storage-csi-olm-operator-install_{context}"]
-= Installing the GCP Filestore CSI Driver Operator
+= Installing the {gcp-short} Filestore CSI Driver Operator
 
-The Google Compute Platform (GCP) Filestore Container Storage Interface (CSI) Driver Operator is not installed in {product-title} by default.
-Use the following procedure to install the GCP Filestore CSI Driver Operator in your cluster.
+The Google Compute Platform ({gcp-short}) Filestore Container Storage Interface (CSI) Driver Operator is not installed in {product-title} by default.
+Use the following procedure to install the {gcp-short} Filestore CSI Driver Operator in your cluster.
 
 .Prerequisites
 * Access to the {product-title} web console.
+* If using {gcp-wid-short}, certain {gcp-wid-short} parameters are needed. See the preceding Section _Preparing to install the {gcp-short} Filestore CSI Driver Operator with Workload Identity_.
 
 .Procedure
-To install the GCP Filestore CSI Driver Operator from the web console:
+To install the {gcp-short} Filestore CSI Driver Operator from the web console:
 
 ifdef::openshift-dedicated[]
 
@@ -40,26 +41,33 @@ $ gcloud services enable file.googleapis.com  --project <my_gce_project> <1>
 +
 You can also do this using Google Cloud web console.
 
-. Install the GCP Filestore CSI Operator:
+. Install the {gcp-short} Filestore CSI Operator:
 
 .. Click *Operators* -> *OperatorHub*.
 
-.. Locate the GCP Filestore CSI Operator by typing *GCP Filestore* in the filter box.
+.. Locate the {gcp-short} Filestore CSI Operator by typing *{gcp-short} Filestore* in the filter box.
 
-.. Click the *GCP Filestore CSI Driver Operator* button.
+.. Click the *{gcp-short} Filestore CSI Driver Operator* button.
 
-.. On the *GCP Filestore CSI Driver Operator* page, click *Install*.
+.. On the *{gcp-short} Filestore CSI Driver Operator* page, click *Install*.
 
 .. On the *Install Operator* page, ensure that:
 +
 * *All namespaces on the cluster (default)* is selected.
 * *Installed Namespace* is set to *openshift-cluster-csi-drivers*.
++
+If using {gcp-wid-short}, enter values for the following fields obtained from the procedure in Section _Preparing to install the {gcp-short} Filestore CSI Driver Operator with Workload Identity_:
++
+* *{gcp-short} Project Number*
+* *{gcp-short} Pool ID* 
+* *{gcp-short} Provider ID* 
+* *{gcp-short} Service Account Email* 
 
 .. Click *Install*.
 +
-After the installation finishes, the GCP Filestore CSI Operator is listed in the *Installed Operators* section of the web console.
+After the installation finishes, the {gcp-short} Filestore CSI Operator is listed in the *Installed Operators* section of the web console.
 
-. Install the GCP Filestore CSI Driver:
+. Install the {gcp-short} Filestore CSI Driver:
 
 .. Click *administration* → *CustomResourceDefinitions* → *ClusterCSIDriver*.
 
diff --git a/modules/persistent-storage-csi-gcp-filestore-wif.adoc b/modules/persistent-storage-csi-gcp-filestore-wif.adoc
new file mode 100644
index 000000000000..b5da08cac839
--- /dev/null
+++ b/modules/persistent-storage-csi-gcp-filestore-wif.adoc
@@ -0,0 +1,126 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_csi-google_cloud_file.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="persistent-storage-csi-gcp-filestore-wif_{context}"]
+= Preparing to install the {gcp-short} Filestore CSI Driver Operator with Workload Identity
+
+If you are planning to use {gcp-wid-short} with Google Compute Platform Filestore, you must obtain certain parameters that you will use during the installation of the {gcp-short} Filestore Container Storage Interface (CSI) Driver Operator.
+
+.Prerequisites
+* Access to the cluster as a user with the cluster-admin role.
+
+// Put note in install area of docs to remind users to take note of the identity pool ID and the provider ID
+
+.Procedure
+
+To prepare to install the {gcp-short} Filestore CSI Driver Operator with Workload Identity:
+
+. Obtain the project number:
+
+.. Obtain the project ID by running the following command:
++
+[source, terminal]
+----
+$ export PROJECT_ID=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.gcp.projectID}')
+----
+
+.. Obtain the project number, using the project ID, by running the following command:
++
+[source, terminal]
+----
+$ gcloud projects describe $PROJECT_ID --format="value(projectNumber)"
+----
+
+. Find the identity pool ID and the provider ID:
++
+During cluster installation, the names of these resources are provided to the Cloud Credential Operator utility (`ccoctl`) with the `--name parameter`. See "Creating {gcp-short} resources with the Cloud Credential Operator utility".
+
+. Create Workload Identity resources for the {gcp-short} Filestore Operator:
+
+.. Create a `CredentialsRequest` file using the following example file:
++
+.Example Credentials Request YAML file
+[source, YAML]
+----
+apiVersion: cloudcredential.openshift.io/v1
+kind: CredentialsRequest
+metadata:
+  name: openshift-gcp-filestore-csi-driver-operator
+  namespace: openshift-cloud-credential-operator
+  annotations:
+    include.release.openshift.io/self-managed-high-availability: "true"
+    include.release.openshift.io/single-node-developer: "true"
+spec:
+  serviceAccountNames:
+  - gcp-filestore-csi-driver-operator
+  - gcp-filestore-csi-driver-controller-sa
+  secretRef:
+    name: gcp-filestore-cloud-credentials
+    namespace: openshift-cluster-csi-drivers
+  providerSpec:
+    apiVersion: cloudcredential.openshift.io/v1
+	kind: GCPProviderSpec
+    predefinedRoles:
+    - roles/file.editor
+    - roles/resourcemanager.tagUser
+    skipServiceCheck: true
+----
+
+.. Use the `CredentialsRequest` file to create a {gcp-short} service account by running the following command:
++
+[source, terminal]
+----
+$ ./ccoctl gcp create-service-accounts --name=<filestore-service-account> \// <1>
+  --workload-identity-pool=<workload-identity-pool> \// <2> 
+  --workload-identity-provider=<workload-identity-provider> \// <3> 
+  --project=<project-id> \// <4> 
+  --credentials-requests-dir=/tmp/credreq <5>
+----
+<1> <filestore-service-account> is a user-chosen name. 
+<2> <workload-identity-pool> comes from Step 2 above.
+<3> <workload-identity-provider> comes from Step 2 above.
+<4> <project-id> comes from Step 1.a above.
+<5> The name of directory where the `CredentialsRequest` file resides.
++
+.Example output
+[source, terminal]
+----
+2025/02/10 17:47:39 Credentials loaded from gcloud CLI defaults
+2025/02/10 17:47:42 IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator created
+2025/02/10 17:47:44 Unable to add predefined roles to IAM service account, retrying...
+2025/02/10 17:47:59 Updated policy bindings for IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator
+2025/02/10 17:47:59 Saved credentials configuration to: /tmp/install-dir/ <1>
+openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml
+----
+<1> The current directory.
+
+.. Find the service account email of the newly created service account by running the following command:
++
+[source, terminal]
+----
+$ cat /tmp/install-dir/manifests/openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml | yq '.data["service_account.json"]' | base64 -d | jq '.service_account_impersonation_url'
+----
++
+.Example output
+[source, terminal]
+----
+https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com:generateAccessToken
+----
++
+In this example output, the service account email is `filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com`.
+
+.Results
+
+You now have the following parameters that you need to install the {gcp-short} Filestore CSI Driver Operator:
+
+* Project number - from Step 1.b
+
+* Pool ID - from Step 2
+
+* Provider ID - from Step 2
+
+* Service account email - from Step 3.c
+
+
diff --git a/modules/persistent-storage-csi-gcp-hyperdisk-limitations.adoc b/modules/persistent-storage-csi-gcp-hyperdisk-limitations.adoc
new file mode 100644
index 000000000000..269d9bcd3ad9
--- /dev/null
+++ b/modules/persistent-storage-csi-gcp-hyperdisk-limitations.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="persistent-storage-csi-gcp-hyperdisk-limitations_{context}"]
+= C3 and N4 instance type limitations
+The GCP PD CSI driver support for the C3 instance type for bare metal and N4 machine series have the following limitations:
+
+* Cloning volumes is not supported when using storage pools.
+
+* For cloning or resizing, hyperdisk-balanced disks original volume size must be 6Gi or greater.
+
+* The default storage class is standard-csi. 
++
+[IMPORTANT]
+====
+You need to manually create a storage class.
+
+For information about creating the storage class, see Step 2 in Section _Setting up hyperdisk-balanced disks_.
+====
+
+* Clusters with mixed virtual machines (VMs) that use different storage types, for example, N2 and N4, are not supported. This is due to hyperdisks-balanced disks not being usable on most legacy VMs. Similarly, regular persistent disks are not usable on N4/C3 VMs.
+
+* A GCP cluster with c3-standard-2, c3-standard-4, n4-standard-2, and n4-standard-4 nodes can erroneously exceed the maximum attachable disk number, which should be 16 (link:https://issues.redhat.com/browse/OCPBUGS-39258[JIRA link]).
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-overview.adoc b/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-overview.adoc
new file mode 100644
index 000000000000..e8f632449beb
--- /dev/null
+++ b/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-overview.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="persistent-storage-csi-gcp-hyperdisk-storage-pools-overview_{context}"]
+= Storage pools for hyperdisk-balanced disks overview
+
+Hyperdisk storage pools can be used with Compute Engine for large-scale storage. A hyperdisk storage pool is a purchased collection of capacity, throughput, and IOPS, which you can then provision for your applications as needed. You can use hyperdisk storage pools to create and manage disks in pools and use the disks across multiple workloads. By managing disks in aggregate, you can save costs while achieving expected capacity and performance growth. By using only the storage that you need in hyperdisk storage pools, you reduce the complexity of forecasting capacity and reduce management by going from managing hundreds of disks to managing a single storage pool.
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure.adoc b/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure.adoc
new file mode 100644
index 000000000000..9d9e983a01e4
--- /dev/null
+++ b/modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure.adoc
@@ -0,0 +1,249 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure_{context}"]
+= Setting up hyperdisk-balanced disks
+
+.Prerequisites
+* Access to the cluster with administrative privileges
+
+.Procedure
+To set up hyperdisk-balanced disks:
+
+ifndef::openshift-dedicated[]
+. Create GCP cluster with attached disks provisioned with hyperdisk-balanced disks.
+endif::openshift-dedicated[]
+
+ifndef::openshift-dedicated[]
+. Create a storage class specifying the hyperdisk-balanced disks during installation:
+endif::openshift-dedicated[]
+
+ifndef::openshift-dedicated[]
+.. Follow the procedure in the _Installing a cluster on GCP with customizations_ section.
++ 
+For your install-config.yaml file, use the following example file:
++
+.Example install-config YAML file
+[source, yaml]
+----
+apiVersion: v1
+metadata:
+  name: ci-op-9976b7t2-8aa6b
+
+sshKey: |
+  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+baseDomain: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+platform:
+  gcp:
+    projectID: XXXXXXXXXXXXXXXXXXXXXX
+    region: us-central1
+controlPlane:
+  architecture: amd64
+  name: master
+  platform:
+    gcp:
+      type: n4-standard-4 <1>
+      osDisk:
+        diskType: hyperdisk-balanced <2>
+        diskSizeGB: 200
+  replicas: 3
+compute:
+- architecture: amd64
+  name: worker
+  replicas: 3
+  platform:
+    gcp:
+      type: n4-standard-4 <1>
+      osDisk:
+        diskType: hyperdisk-balanced <2>
+----
+<1> Specifies the node type as n4-standard-4.
+<2> Specifies the node has the root disk backed by hyperdisk-balanced disk type. All nodes in the cluster should use the same disk type, either hyperdisks-balanced or pd-*.
++
+[NOTE]
+====
+All nodes in the cluster must support hyperdisk-balanced volumes. Clusters with mixed nodes are not supported, for example N2 and N3 using hyperdisk-balanced disks.
+====
+endif::openshift-dedicated[]
+
+ifndef::openshift-dedicated[]
+.. After step 3 in _Incorporating the Cloud Credential Operator utility manifests_ section, copy the following manifests into the manifests directory created by the installation program:
++
+* cluster_csi_driver.yaml - specifies opting out of the default storage class creation
+* storageclass.yaml - creates a hyperdisk-specific storage class
++
+.Example cluster CSI driver YAML file
+[source, yaml]
+----
+apiVersion: operator.openshift.io/v1
+kind: "ClusterCSIDriver"
+metadata:
+  name: "pd.csi.storage.gke.io"
+spec:
+  logLevel: Normal
+  managementState: Managed
+  operatorLogLevel: Normal
+  storageClassState: Unmanaged <1>
+----
+<1> Specifies disabling creation of the default {product-title} storage classes.
++
+.Example storage class YAML file
+[source, yaml]
+----
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: hyperdisk-sc <1>
+  annotations:
+    storageclass.kubernetes.io/is-default-class: "true"
+provisioner: pd.csi.storage.gke.io <2>
+volumeBindingMode: WaitForFirstConsumer
+allowVolumeExpansion: true
+reclaimPolicy: Delete
+parameters:
+  type: hyperdisk-balanced <3>
+  replication-type: none
+  provisioned-throughput-on-create: "140Mi" <4>
+  provisioned-iops-on-create: "3000" <5>
+  storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c <6>
+allowedTopologies: <7>
+- matchLabelExpressions:
+  - key: topology.kubernetes.io/zone
+    values:
+    - us-east4-c
+...
+----
+<1> Specify the name for your storage class. In this example, it is `hyperdisk-sc`.
+<2> `pd.csi.storage.gke.io` specifies GCP CSI provisioner.
+<3> Specifies using hyperdisk-balanced disks.
+<4> Specifies the throughput value in MiBps using the "Mi" qualifier. For example, if your required throughput is 250 MiBps, specify "250Mi". If you do not specify a value, the capacity is based upon the disk type default.
+<5> Specifies the IOPS value without any qualifiers. For example, if you require 7,000 IOPS, specify "7000". If you do not specify a value, the capacity is based upon the disk type default.
+<6> If using storage pools, specify a list of specific storage pools that you want to use in the format: projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME.
+<7> If using storage pools, set `allowedTopologies` to restrict the topology of provisioned volumes to where the storage pool exists. In this example, `us-east4-c`. 
+endif::openshift-dedicated[]
+
+. Create a persistent volume claim (PVC) that uses the hyperdisk-specific storage class using the following example YAML file:
++
+.Example PVC YAML file
+[source, yaml]
+----
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: my-pvc
+spec:
+  storageClassName: hyperdisk-sc <1>
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 2048Gi <2>
+----
+<1> PVC references the the storage pool-specific storage class. In this example, `hyperdisk-sc`.
+<2> Target storage capacity of the hyperdisk-balanced volume. In this example, `2048Gi`.
+
+. Create a deployment that uses the PVC that you just created. Using a deployment helps ensure that your application has access to the persistent storage even after the pod restarts and rescheduling:
+
+.. Ensure a node pool with the specified machine series is up and running before creating the deployment. Otherwise, the pod fails to schedule.
+
+.. Use the following example YAML file to create the deployment:
++
+.Example deployment YAML file
+[source, yaml]
+----
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: postgres
+spec:
+  selector:
+    matchLabels:
+      app: postgres
+  template:
+    metadata:
+      labels:
+        app: postgres
+    spec:
+      nodeSelector:
+        cloud.google.com/machine-family: n4 <1>
+      containers:
+      - name: postgres
+        image: postgres:14-alpine
+        args: [ "sleep", "3600" ]
+        volumeMounts:
+        - name: sdk-volume
+          mountPath: /usr/share/data/
+      volumes:
+      - name: sdk-volume
+        persistentVolumeClaim:
+          claimName: my-pvc <2>
+----
+<1> Specifies the machine family. In this example, it is `n4`.
+<2> Specifies the name of the PVC created in the preceding step. In this example, it is `my-pfc`.
+
+.. Confirm that the deployment was successfully created by running the following command:
++
+[source, terminal]
+----
+$ oc get deployment
+----
++
+.Example output
+[source, terminal]
+----
+NAME       READY   UP-TO-DATE   AVAILABLE   AGE
+postgres   0/1     1            0           42s
+----
++
+It might take a few minutes for hyperdisk instances to complete provisioning and display a READY status.
+
+.. Confirm that PVC `my-pvc` has been successfully bound to a persistent volume (PV) by running the following command:
++
+[source, terminal]
+----
+$ oc get pvc my-pvc
+----
++
+.Example output
++
+[source, terminal]
+----
+NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       VOLUMEATTRIBUTESCLASS  AGE
+my-pvc        Bound    pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6   2Ti        RWO            hyperdisk-sc       <unset>                2m24s
+----
+
+.. Confirm the expected configuration of your hyperdisk-balanced disk:
++
+[source, terminal]
+----
+$ gcloud compute disks list
+----
++
+.Example output
++
+[source, terminal]
+----
+NAME                                        LOCATION        LOCATION_SCOPE  SIZE_GB  TYPE                STATUS
+instance-20240914-173145-boot               us-central1-a   zone            150      pd-standard         READY
+instance-20240914-173145-data-workspace     us-central1-a   zone            100      pd-balanced         READY
+c4a-rhel-vm                                 us-central1-a   zone            50       hyperdisk-balanced  READY <1>
+----
+<1> Hyperdisk-balanced disk.
+
+.. If using storage pools, check that the volume is provisioned as specified in your storage class and PVC by running the following command:
++
+[source, terminal]
+----
+$ gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
+----
++
+.Example output
++
+[source, terminal]
+----
+NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
+pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048
+----
+
diff --git a/modules/persistent-storage-csi-group-snapshot-create-admin.adoc b/modules/persistent-storage-csi-group-snapshot-create-admin.adoc
new file mode 100644
index 000000000000..2ace7dae60ee
--- /dev/null
+++ b/modules/persistent-storage-csi-group-snapshot-create-admin.adoc
@@ -0,0 +1,43 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="persistent-storage-csi-group-snapshots-create-admin_{context}"]
+= Creating a volume group snapshot class
+
+Before you can create volume group snapshots, the cluster administrator needs to create a `VolumeGroupSnapshotClass`. 
+
+This object describes how volume group snapshots should be created, including the driver information, the deletion policy, etc.
+
+.Prerequisites
+* Logged in to a running {product-title} cluster with administrator privileges.
+
+* Enabled this feature using feature gates. For information about how to use feature gates, see _Enabling features sets by using feature gates_.
+
+.Procedure
+
+To create a `VolumeGroupSnapshotClass`:
+
+. Create a `VolumeGroupSnapshotClass` YAML file using the following example file:
++
+.Example volume group snapshot class YAML file
+[source, yaml]
+----
+apiVersion: groupsnapshot.storage.k8s.io/v1beta1
+kind: VolumeGroupSnapshotClass <1>
+metadata:
+  name: csi-hostpath-groupsnapclass <2>
+deletionPolicy: Delete
+driver: hostpath.csi.k8s.io 
+     …...
+----
+<1> Specifies the `VolumeGroupSnapshotClass` object.
+<2> Name of the `VolumeGroupSnapshotClass`.
+
+. Create the 'VolumeGroupSnapshotClass' object by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <volume-group-snapshot-class-filename>.yaml
+----
diff --git a/modules/persistent-storage-csi-group-snapshots-create.adoc b/modules/persistent-storage-csi-group-snapshots-create.adoc
new file mode 100644
index 000000000000..0ceb001bb380
--- /dev/null
+++ b/modules/persistent-storage-csi-group-snapshots-create.adoc
@@ -0,0 +1,132 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="persistent-storage-csi-group-snapshots-create_{context}"]
+= Creating a volume group snapshot
+
+When you create a `VolumeGroupSnapshot` object, {product-title} creates a volume group snapshot.
+
+.Prerequisites
+* Logged in to a running {product-title} cluster.
+* Enabled this feature using feature gates. For information about how to use feature gates, see _Enabling features sets by using feature gates_.
+* The persistent volume claims (PVCs) that you want to group for the snapshot have been created using a CSI driver that supports `VolumeGroupSnapshot` objects.
+* A storage class to provision the storage back end.
+* Administrator has created the `VolumeGroupSnapshotClass` object.
+
+.Procedure
+
+To create a volume group snapshot:
+
+. Locate (or create) the PVCs that you want to include in the volume group snapshot:
++
+[source, terminal]
+----
+$ oc get pvc
+----
++
+.Example command output
++
+[source, terminal]
+----
+NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
+pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
+pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48S
+----
++
+This example uses two PVCs
+
+. Label the PVCs to belong to a snapshot group:
+.. Label PVC pvc-0 by running the following command:
++
+[source, terminal]
+----
+$ oc label pvc pvc-0 group=myGroup
+----
++
+.Example output
+[source, terminal]
+----
+persistentvolumeclaim/pvc-0 labeled
+----
+.. Label PVC pvc-1 by running the following command:
++
+[source, terminal]
+----
+$ oc label pvc pvc-1 group=myGroup
+----
++
+.Example output
+[source, terminal]
+----
+persistentvolumeclaim/pvc-1 labeled
+----
++
+In this example, you are labeling PVC "pvc-0" and "pvc-1" to belong to group "myGroup".
+
+. Create a `VolumeGroupSnapshot` object to specify your volume group snapshot:
+.. Create a `VolumeGroupSnapshot` object YAML file with the following example file:
++
+.Example VolumeGroupSnapshot YAML file
+[source, yaml]
+----
+apiVersion: groupsnapshot.storage.k8s.io/v1beta1
+kind: VolumeGroupSnapshot <1>
+metadata:
+  name: <volume-group-snapshot-name> <2>
+  namespace: <namespace> <3>
+spec:
+  volumeGroupSnapshotClassName: <volume-group-snapshot-class-name> <4>
+  source:
+    selector:
+      matchLabels:
+        group: myGroup <5>
+----
+<1> The `VolumeGroupSnapshot` object requests creation of a volume group snapshot for multiple PVCs.
+<2> Name of the volume group snapshot.
+<3> Namespace for the volume group snapshot.
+<4> The `VolumeGroupSnapshotClass` name. This object is created by the administrator and describes how volume group snapshots should be created.
+<5> The name of the label used to group the desired PVCs for the snapshot. In this example, it is "myGroup".
+
+.. Create the `VolumeGroupSnapshot` object by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <volume-group-snapshot-filename>.yaml
+----
+
+.Results
+Individual volume snapshots are created according to how many PVCs were specified as part of the volume group snapshot.
+
+These individual volume snapshots are named with the following format: <hash of VolumeGroupSnaphotContentUUID+volumeHandle>:
+
+.Example individual volume snapshot
+[source, yaml]
+----
+apiVersion: snapshot.storage.k8s.io/v1
+kind: VolumeSnapshot
+metadata:
+  name: snapshot-4dc1c53a29538b36e85003503a4bcac5dbde4cff59e81f1e3bb80b6c18c3fd03
+  namespace: default
+  ownerReferences:
+  - apiVersion: groupsnapshot.storage.k8s.io/v1beta1
+    kind: VolumeGroupSnapshot
+    name: my-groupsnapshot
+    uid: ba2d60c5-5082-4279-80c2-daa85f0af354
+  resourceVersion: "124503"
+  uid: c0137282-f161-4e86-92c1-c41d36c6d04c 
+spec:
+  source:
+    persistentVolumeClaimName:pvc-1
+status:
+  volumeGroupSnapshotName: volume-group-snapshot-name
+----
+
+In the preceding example, two individual volume snapshots are created as part of the volume group snapshot.
+
+[source, terminal]
+----
+snapshot-4dc1c53a29538b36e85003503a4bcac5dbde4cff59e81f1e3bb80b6c18c3fd03
+snapshot-fbfe59eff570171765df664280910c3bf1a4d56e233a5364cd8cb0152a35965b
+----
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-group-snapshots-limitations.adoc b/modules/persistent-storage-csi-group-snapshots-limitations.adoc
new file mode 100644
index 000000000000..b9df79c62869
--- /dev/null
+++ b/modules/persistent-storage-csi-group-snapshots-limitations.adoc
@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="persistent-storage-csi-group-snapshots-limitations_{context}"]
+= CSI volume group snapshots limitations
+
+Volume group snapshots has the following limitations:
+
+* Does not support reverting an existing persistent volume claim (PVC) to an earlier state represented by a snapshot It only supports provisioning a new volume from a snapshot.
+
+* No guarantees of application consistency, for example, crash consistency, are provided beyond those provided by the storage system. For more information about application consistency, see link:https://github.com/kubernetes/community/blob/master/wg-data-protection/data-protection-workflows-white-paper.md#quiesce-and-unquiesce-hooks[Quiesce and Unquiesce Hooks].
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-group-snapshots-overview.adoc b/modules/persistent-storage-csi-group-snapshots-overview.adoc
new file mode 100644
index 000000000000..da8eec60735e
--- /dev/null
+++ b/modules/persistent-storage-csi-group-snapshots-overview.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="persistent-storage-csi-group-snapshots-overview_{context}"]
+= Overview of CSI volume group snapshots
+
+A _snapshot_ represents the state of the storage volume in a cluster at a particular point in time. Volume snapshots can be used to provision a new volume. 
+
+A _volume group snapshot_ uses a label selector to group multiple persistent volume claims for snapshotting. A volume group snapshot represents copies from multiple volumes that are taken at the same point-in-time. This can be useful for applications that contain multiple volumes.
+
+Container Storage Interface (CSI) volume group snapshots needs to be supported by the CSI driver. {rh-storage} supports volume group snapshots.
+
+Volume group snapshots provide three new API objects for managing snapshots:
+
+`VolumeGroupSnapshot`::
+Requests creation of a volume group snapshot for multiple persistent volume claims. It contains information about the volume group snapshot operation, such as the timestamp when the volume group snapshot was taken, and whether it is ready to use. 
+
+`VolumeGroupSnapshotContent`::
+Created by the snapshot controller for a dynamically created volumeGroupSnapshot. It contains information about the volume group snapshot including the volume group snapshot ID. This object represents a provisioned resource on the cluster (a group snapshot). The `VolumeGroupSnapshotContent` object binds to the volume group snapshot for which it was created with a one-to-one mapping.
+
+`VolumeGroupSnapshotClass`::
+Created by cluster administrators to describe how volume group snapshots should be created, including the driver information, the deletion policy, etc.
+
+These three API kinds are defined as `CustomResourceDefinitions` (CRDs). These CRDs must be installed in a {product-title} cluster for a CSI driver to support volume group snapshots.
\ No newline at end of file
diff --git a/modules/persistent-storage-csi-group-snapshots-restore.adoc b/modules/persistent-storage-csi-group-snapshots-restore.adoc
new file mode 100644
index 000000000000..0437ce6e1be0
--- /dev/null
+++ b/modules/persistent-storage-csi-group-snapshots-restore.adoc
@@ -0,0 +1,68 @@
+// Module included in the following assemblies:
+//
+// * storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="persistent-storage-csi-group-snapshots-restore_{context}"]
+= Restoring a volume group snapshot
+
+You can use the `VolumeGroupSnapshot` custom resource definition (CRD) content to restore the existing volumes to a previous state.
+
+To restore existing volumes, you can request a new persistent volume claim (PVC) to be created from a `VolumeSnapshot` object that is part of a `VolumeGroupSnapshot`. This triggers provisioning of a new volume that is populated with data from the specified snapshot. Repeat this process until all volumes are created from all the snapshots that are part of a volume group snapshot.
+
+.Prerequisites
+* Logged in to a running {product-title} cluster.
+* PVC has been created using a Container Storage Interface (CSI) driver that supports volume group snapshots.
+* A storage class to provision the storage back end.
+* A volume group snapshot has been created and is ready to use.
+
+.Procedure
+
+To restore existing volumes to a previous state from a volume group snapshot:
+
+. Specify a `VolumeSnapshot` data source from a volume group snapshot for a PVC as shown in the following example:
++
+.Example restore PVC YAML file
+[source, yaml]
+----
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: <pvc-restore-name> <1>
+  namespace: <namespace> <2>
+spec:
+  storageClassName: csi-hostpath-sc
+  dataSource:
+    name: snapshot-fbfe59eff570171765df664280910c3bf1a4d56e233a5364cd8cb0152a35965b <3>
+    kind: VolumeSnapshot <4>
+    apiGroup: snapshot.storage.k8s.io <5>
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+----
+<1> Name of the restore PVC.
+<2> Name of the namespace.
+<3> Name of an individual volume snapshot that is part of the volume group snapshot to use as source.
+<4> Must be set to the `VolumeSnapshot` value.
+<5> Must be set to the `snapshot.storage.k8s.io` value
+
+. Create the PVC by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <pvc-restore-filename>.yaml <1>
+----
+<1> Name of the PVC restore file specified in the preceding step.
+
+. Verify that the restored PVC has been created by running the following command:
++
+[source,terminal]
+----
+$ oc get pvc
+----
++
+A new PVC with the name you specified in the first step appears.
+
+. Repeat the procedure as needed until all volumes are created from all the snapshots that are part of a volume group snapshot.
diff --git a/modules/persistent-storage-csi-manila-dynamic-provisioning.adoc b/modules/persistent-storage-csi-manila-dynamic-provisioning.adoc
index b01a8a51ab35..228c429034c9 100644
--- a/modules/persistent-storage-csi-manila-dynamic-provisioning.adoc
+++ b/modules/persistent-storage-csi-manila-dynamic-provisioning.adoc
@@ -12,6 +12,11 @@ The YAML files that are created are completely decoupled from Manila and from it
 
 You can use the same pod and persistent volume claim (PVC) definitions on-premise that you use with {product-title} on AWS, GCP, Azure, and other platforms, with the exception of the storage class reference in the PVC definition.
 
+[IMPORTANT]
+====
+By default the access-rule assigned to a volume is set to 0.0.0.0/0. To limit the clients that can mount the persistent volume (PV), create a new storage class with an IP or a subnet mask in the `nfs-shareClient` storage class parameter.
+====
+
 [NOTE]
 ====
 Manila service is optional. If the service is not enabled in {rh-openstack-first}, the Manila CSI driver is not installed and the storage classes for Manila are not created.
@@ -39,12 +44,12 @@ To dynamically create a Manila CSI volume using the web console:
 +
 [IMPORTANT]
 ====
-Use RWX if you want the persistent volume (PV) that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.
+Use RWX if you want the PV that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.
 ====
 
 . Define the size of the storage claim.
 
-. Click *Create* to create the persistent volume claim and generate a persistent volume.
+. Click *Create* to create the PVC and generate a PV.
 
 .Procedure (CLI)
 
@@ -69,9 +74,9 @@ spec:
   storageClassName: csi-manila-gold <2>
 ----
 +
-<1> Use RWX if you want the persistent volume (PV) that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.
+<1> Use RWX if you want the PV that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.
 <2> The name of the storage class that provisions the storage back end. Manila storage classes are provisioned by the Operator and have the `csi-manila-` prefix.
-+
+
 . Create the object you saved in the previous step by running the following command:
 +
 [source,terminal]
diff --git a/modules/persistent-storage-csi-snapshots-delete.adoc b/modules/persistent-storage-csi-snapshots-delete.adoc
index 836be28a71a8..5e34a7ee562f 100644
--- a/modules/persistent-storage-csi-snapshots-delete.adoc
+++ b/modules/persistent-storage-csi-snapshots-delete.adoc
@@ -22,7 +22,7 @@ kind: VolumeSnapshotClass
 metadata:
   name: csi-hostpath-snap
 driver: hostpath.csi.k8s.io
-deletionPolicy: Delete <1>
+deletionPolicy: Delete # <1>
 ----
 [.small]
 <1> When deleting the volume snapshot, if the `Delete` value is set, the underlying snapshot is deleted along with the `VolumeSnapshotContent` object. If the `Retain` value is set, both the underlying snapshot and `VolumeSnapshotContent` object remain.
@@ -33,8 +33,9 @@ If the `Retain` value is set and the `VolumeSnapshot` object is deleted without
 +
 [source,terminal]
 ----
-$ oc delete volumesnapshot <volumesnapshot_name>
+$ oc delete volumesnapshot <volumesnapshot_name> # <1>
 ----
+<1> Replace _<volumesnapshot_name>_ with the name of the volume snapshot you want to delete.
 +
 .Example output
 +
@@ -47,8 +48,9 @@ volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted
 +
 [source,terminal]
 ----
-$ oc delete volumesnapshotcontent <volumesnapshotcontent_name>
+$ oc delete volumesnapshotcontent <volumesnapshotcontent_name> # <1>
 ----
+<1> Replace _<volumesnapshotcontent_name>_ with the content you want to delete.
 +
 . Optional: If the `VolumeSnapshot` object is not successfully deleted, enter the following command to remove any finalizers for the leftover resource so that the delete operation can continue:
 +
diff --git a/modules/persistent-storage-csi-vol-detach-non-graceful-shutdown-procedure.adoc b/modules/persistent-storage-csi-vol-detach-non-graceful-shutdown-procedure.adoc
index 03afaca85c98..da0a8fdad1d1 100644
--- a/modules/persistent-storage-csi-vol-detach-non-graceful-shutdown-procedure.adoc
+++ b/modules/persistent-storage-csi-vol-detach-non-graceful-shutdown-procedure.adoc
@@ -32,6 +32,12 @@ If the node is not completely shut down, do not proceed with tainting the node.
 +
 . Taint the corresponding node object by running the following command:
 +
+[IMPORTANT]
+====
+Tainting a node this way deletes all pods on that node. This also causes any pods that are backed by 
+statefulsets to be evicted, and replacement pods to be created on a different node.
+====
++
 [source,terminal]
 ----
 oc adm taint node <node name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute <1>
diff --git a/modules/persistent-storage-local-removing-devices.adoc b/modules/persistent-storage-local-removing-devices.adoc
index d10a613d34fa..3876c9541739 100644
--- a/modules/persistent-storage-local-removing-devices.adoc
+++ b/modules/persistent-storage-local-removing-devices.adoc
@@ -6,16 +6,11 @@
 [id="local-removing-device_{context}"]
 = Removing a local volume or local volume set
 
-Occasionally, local volumes and local volume sets must be deleted. While removing the entry in the resource and deleting the persistent volume is typically enough, if you want to reuse the same device path or have it managed by a different storage class, then additional steps are needed.
-
-[NOTE]
-====
-The following procedure outlines an example for removing a local volume. The same procedure can also be used to remove symlinks for a local volume set custom resource.
-====
+Occasionally, you need to delete local volumes (LVs) and local volume sets (LVSs). 
 
 .Prerequisites
 
-* The persistent volume must be in a `Released` or `Available` state.
+* The persistent volume (PV) must be in a `Released` or `Available` state.
 +
 [WARNING]
 ====
@@ -24,33 +19,84 @@ Deleting a persistent volume that is still in use can result in data loss or cor
 
 .Procedure
 
-. Edit the previously created local volume to remove any unwanted disks.
+To delete LVs or LVSs, complete the following steps:
+
+. If there are any bound PVs owned by the LV or LVS that is being deleted, delete the corresponding persistent volume claims (PVCs) to release the PVs:
 
-.. Edit the cluster resource:
+.. To find bound PVs owned by a particular LV or LVS, run the following command:
 +
+[source, terminal]
+----
+$ oc get pv --selector storage.openshift.com/owner-name=<LV_LVS_name> <1>
+----
+<1> `<LV_LVS_name>` is the name of the LV or LVS.
++
+.Example output
 [source,terminal]
 ----
-$ oc edit localvolume <name> -n openshift-local-storage
+NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                 STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
+local-pv-3fa1c73    5Gi        RWO            Delete           Available                         slow           <unset>                          28s
+local-pv-1cec77cf   30Gi       RWX            Retain           Bound       openshift/storage     my-sc          <unset>                          168d
 ----
++
+Bound PVs have a status of `Bound` and their corresponding PVCs appear in the `CLAIM` column. In the preceding example, PV `local-pv-1cec77cf` is bound, and its PVC is `openshift/storage`.
 
-.. Navigate to the lines under `devicePaths`, and delete any representing unwanted disks.
+.. Delete corresponding PVCs of bound PVs owned by the LV or LVS being deleted by running the following command:
++
+[source, terminal]
+----
+$ oc delete pvc <name>
+----
++ 
+In this example, you would delete PVC `openshift/storage`.
 
-. Delete any persistent volumes created.
+. Delete the LVs or LVSs by running the applicable following command:
++
+.Command for deleting LV
 +
 [source,terminal]
 ----
-$ oc delete pv <pv-name>
+$ oc delete lv <name>
+----
++
+or
++
+.Command for deleting LVS
+[source,terminal]
+----
+$ oc delete lvs <name>
 ----
 
-. Delete directory and included symlinks on the node.
+. If any PV owned by the LV or LVS has a `Retain` reclaim policy, back up any important data, and then delete the PV:
 +
-[WARNING]
+[NOTE]
 ====
-The following step involves accessing a node as the root user. Modifying the state of the node beyond the steps in this procedure could result in cluster instability.
+PVs with a `Delete` policy are automatically deleted when you delete the LVs or LVS.
 ====
 +
+.. To find PVs with `Retain` reclaim policy, run the following command:
++
+[source,terminal]
+----
+$ oc get pv
+----
++
+.Example output
 [source,terminal]
 ----
-$ oc debug node/<node-name> -- chroot /host rm -rf /mnt/local-storage/<sc-name> <1>
+NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS   REASON   AGE
+local-pv-1cec77cf   30Gi       RWX            Retain           Available                        my-sc                   168d
 ----
-<1> The name of the storage class used to create the local volumes.
++
+In this example,  PV `local-pv-1cec77cf` has a `Retain` reclaim policy and needs to be manually deleted.
+
+.. Back up any important data on this volume.
+
+.. Delete the PV by running the following command:
++
+[source,terminal]
+----
+$ oc delete pv <name>
+----
++
+In this example, delete PV `local-pv-1cec77cf`.
\ No newline at end of file
diff --git a/modules/persistent-storage-local-uninstall-operator.adoc b/modules/persistent-storage-local-uninstall-operator.adoc
index ffd786b30b56..abd7e3c69e85 100644
--- a/modules/persistent-storage-local-uninstall-operator.adoc
+++ b/modules/persistent-storage-local-uninstall-operator.adoc
@@ -20,12 +20,20 @@ there might be indeterminate behavior if the Operator is uninstalled and reinsta
 
 .Procedure
 
-. Delete any local volume resources installed in the project, such as `localvolume`, `localvolumeset`, and `localvolumediscovery`:
+. Delete any local volume resources installed in the project, such as `localvolume`, `localvolumeset`, and `localvolumediscovery` by running the following commands:
 +
 [source,terminal]
 ----
 $ oc delete localvolume --all --all-namespaces
+----
++
+[source,terminal]
+----
 $ oc delete localvolumeset --all --all-namespaces
+----
++
+[source,terminal]
+----
 $ oc delete localvolumediscovery --all --all-namespaces
 ----
 
@@ -50,7 +58,7 @@ $ oc delete localvolumediscovery --all --all-namespaces
 $ oc delete pv <pv-name>
 ----
 
-. Delete the `openshift-local-storage` project:
+. Delete the `openshift-local-storage` project by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/policy-shared-responsibility.adoc b/modules/policy-shared-responsibility.adoc
index 9ed5746a59b4..bc89617bf108 100644
--- a/modules/policy-shared-responsibility.adoc
+++ b/modules/policy-shared-responsibility.adoc
@@ -73,7 +73,7 @@ Red Hat is responsible for enabling changes to the cluster infrastructure and se
 
 |Virtual networking
 |* Set up and configure virtual networking components required to provision the cluster, including virtual private cloud, subnets, load balancers, internet gateways, NAT gateways, etc.
-* Provide the ability for the customer to manage VPN connectivity with on-premises resources, VPC to VPC connectivity, and Direct connectivity as required through {cluster-manager}.
+* Provide the ability for the customer to manage VPN connectivity with on-premise resources, VPC to VPC connectivity, and Direct connectivity as required through {cluster-manager}.
 * Setup and configure PSC attachments. ^[1]^
 * Enable customers to create and deploy public cloud load balancers for use with service load balancers.
 |* Set up and maintain optional public cloud networking components, such as VPC to VPC connection, VPN connection, or Direct connection.
@@ -172,4 +172,4 @@ Disaster recovery includes data and configuration backup, replicating data and c
 |* Configure virtual networking connections with more than one tunnel where possible for protection against outages as recommended by the public cloud provider.
 * Maintain failover DNS and load balancing if using a global load balancer with multiple clusters.
 
-|===
\ No newline at end of file
+|===
diff --git a/modules/post-installation-configuring-nutanix-failure-domains.adoc b/modules/post-installation-configuring-nutanix-failure-domains.adoc
index 7a3b8c45eaf5..c3a031220341 100644
--- a/modules/post-installation-configuring-nutanix-failure-domains.adoc
+++ b/modules/post-installation-configuring-nutanix-failure-domains.adoc
@@ -10,7 +10,7 @@ You add failure domains to an existing Nutanix cluster by modifying its Infrastr
 
 [TIP]
 ====
-It is recommended that you configure three failure domains to ensure high-availability.
+To ensure high-availability, configure three failure domains.
 ====
 
 .Procedure
@@ -62,6 +62,16 @@ where:
 
 `<uuid>`:: Specifies the universally unique identifier (UUID) of the Prism Element.
 `<failure_domain_name>`:: Specifies a unique name for the failure domain. The name is limited to 64 or fewer characters, which can include lower-case letters, digits, and a dash (`-`). The dash cannot be in the leading or ending position of the name.
-`<network_uuid>`:: Specifies the UUID of the Prism Element subnet object. The subnet's IP address prefix (CIDR) should contain the virtual IP addresses that the {product-title} cluster uses. Only one subnet per failure domain (Prism Element) in an {product-title} cluster is supported.
+`<network_uuid>`:: Specifies one or more UUID for the Prism Element subnet object. 
+The CIDR IP address prefix for one of the specified subnets must contain the virtual IP addresses that the {product-title} cluster uses.
++
+--
+:FeatureName: Configuring multiple subnets
+include::snippets/technology-preview.adoc[]
+--
++
+To configure multiple subnets in the Infrastructure CR, you must enable the `NutanixMultiSubnets` feature gate.
+A maximum of 32 subnets for each failure domain (Prism Element) in an {product-title} cluster is supported.
+All subnet UUID values must be unique.
 
 . Save the CR to apply the changes.
diff --git a/modules/power-monitoring-fips-support.adoc b/modules/power-monitoring-fips-support.adoc
new file mode 100644
index 000000000000..962af3761fc2
--- /dev/null
+++ b/modules/power-monitoring-fips-support.adoc
@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * power_monitoring/power-monitoring-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="power-monitoring-fips-support_{context}"]
+= About FIPS compliance for {PM-operator}
+
+Starting with version 0.4, {PM-operator} for Red{nbsp}Hat OpenShift is FIPS compliant. When deployed on an {product-title} cluster in FIPS mode, it uses {op-system-base-full} cryptographic libraries validated by National Institute of Standards and Technology (NIST).
+
+For details on the NIST validation program, see link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic module validation program]. For the latest NIST status of {op-system-base} cryptographic libraries, see link:https://access.redhat.com/en/compliance[Compliance activities and government standards].
+
+To enable FIPS mode, you must install {PM-operator} for Red{nbsp}Hat OpenShift on an {product-title} cluster. For more information, see "Do you need extra security for your cluster?".
\ No newline at end of file
diff --git a/modules/powering-off-bare-metal-hosts-web-console.adoc b/modules/powering-off-bare-metal-hosts-web-console.adoc
new file mode 100644
index 000000000000..cdc757ae7540
--- /dev/null
+++ b/modules/powering-off-bare-metal-hosts-web-console.adoc
@@ -0,0 +1,83 @@
+// Module included in the following assemblies:
+//
+// scalability_and_performance/managing-bare-metal-hosts.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="powering-off-bare-metal-hosts-web-console_{context}"]
+= Powering off bare-metal hosts
+
+You can power off bare-metal cluster hosts in the web console or by applying a patch in the cluster by using the OpenShift CLI (`oc`).
+Before you power off a host, you should mark the node as unschedulable and drain all pods and workloads from the node.
+
+.Prerequisites
+* You have installed a {op-system} compute machine on bare-metal infrastructure for use in the cluster.
+* You have logged in as a user with `cluster-admin` privileges.
+* You have configured the host to be managed and have added BMC credentials for the cluster host.
+You can add BMC credentials by applying a `Secret` custom resource (CR) in the cluster or by logging in to the web console and configuring the bare-metal host to be managed.
+
+.Procedure
+. In the web console, mark the node that you want to power off as unschedulable. Perform the following steps:
+
+.. Navigate to *Nodes* and select the node that you want to power off. Expand the *Actions* menu and select *Mark as unschedulable*.
+
+.. Manually delete or relocate running pods on the node by adjusting the pod deployments or scaling down workloads on the node to zero.
+Wait for the drain process to complete.
+
+.. Navigate to *Compute* -> *Bare Metal Hosts*.
+
+.. Expand the *Options menu* for the bare-metal host that you want to power off, and select *Power Off*.
+Select *Immediate power off*.
+
+. Alternatively, you can patch the `BareMetalHost` resource for the host that you want to power off by using `oc`.
+
+.. Get the name of the managed bare-metal host.
+Run the following command:
++
+[source,terminal]
+----
+$ oc get baremetalhosts -n openshift-machine-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.provisioning.state}{"\n"}{end}'
+----
++
+.Example output
+[source,terminal]
+----
+master-0.example.com  managed
+master-1.example.com  managed
+master-2.example.com  managed
+worker-0.example.com  managed
+worker-1.example.com  managed
+worker-2.example.com  managed
+----
+
+.. Mark the node as unschedulable:
++
+[source,terminal]
+----
+$ oc adm cordon <bare_metal_host> <1>
+----
+<1> `<bare_metal_host>` is the host that you want to shut down, for example, `worker-2.example.com`.
+
+.. Drain all pods on the node:
++
+[source,terminal]
+----
+$ oc adm drain <bare_metal_host> --force=true
+----
++
+Pods that are backed by replication controllers are rescheduled to other available nodes in the cluster.
+
+.. Safely power off the bare-metal host.
+Run the following command:
++
+[source,terminal]
+----
+$ oc patch <bare_metal_host> --type json -p '[{"op": "replace", "path": "/spec/online", "value": false}]'
+----
+
+.. After you power on the host, make the node schedulable for workloads.
+Run the following command:
++
+[source,terminal]
+----
+$ oc adm uncordon <bare_metal_host>
+----
diff --git a/modules/preferred-installation-requirements-ibm-z.adoc b/modules/preferred-installation-requirements-ibm-z.adoc
index 9a222546356c..884d3a076daf 100644
--- a/modules/preferred-installation-requirements-ibm-z.adoc
+++ b/modules/preferred-installation-requirements-ibm-z.adoc
@@ -47,13 +47,13 @@ When installing in a z/VM environment, you can also bridge HiperSockets with one
 
 |{product-title} control plane machines
 |Three guest virtual machines
-|Three guest virtual machines
 |Three LPARs
+|Three guest virtual machines
 
 |{product-title} compute machines
 |Six guest virtual machines
-|Six guest virtual machines
 |Six LPARs
+|Six guest virtual machines
 
 |Temporary {product-title} bootstrap machine
 |One machine
diff --git a/modules/private-clusters-setting-api-private.adoc b/modules/private-clusters-setting-api-private.adoc
index b3ef08476051..55c20a50066a 100644
--- a/modules/private-clusters-setting-api-private.adoc
+++ b/modules/private-clusters-setting-api-private.adoc
@@ -31,48 +31,6 @@ you can reconfigure the API server to use only the private zone.
 
 .Procedure
 
-. In the web portal or console for your cloud provider, take the following actions:
-
-.. Locate and delete the appropriate load balancer component:
-ifndef::cpmso-using-azure[]
-*** For AWS, delete the external load balancer. The API DNS entry in the private zone already points to the internal load balancer, which uses an identical configuration, so you do not need to modify the internal load balancer.
-endif::cpmso-using-azure[]
-ifndef::cpmso-using-aws[]
-*** For Azure, delete the `api-internal-v4` rule for the public load balancer.
-
-.. For Azure, configure the Ingress Controller endpoint publishing scope to `Internal`.
-For more information, see "Configuring the Ingress Controller endpoint publishing scope to Internal".
-
-.. For the Azure public load balancer, if you configure the Ingress Controller endpoint publishing scope to `Internal` and there are no existing inbound rules in the public load balancer, you must create an outbound rule explicitly to provide outbound traffic for the backend address pool.
-For more information, see the Microsoft Azure documentation about adding outbound rules.
-endif::cpmso-using-aws[]
-
-.. Delete the
-ifdef::cpmso-using-aws[`api.$clustername.$yourdomain`]
-ifdef::post-install[`api.$clustername.$yourdomain` or]
-ifndef::cpmso-using-aws[`api.$clustername`]
-DNS entry in the public zone.
-
-ifdef::cpmso-using-aws[]
-. Remove the external load balancers by deleting the following indicated lines in the control plane machine set custom resource:
-+
-[source,yaml]
-----
-# ...
-providerSpec:
-  value:
-# ...
-    loadBalancers:
-    - name: lk4pj-ext # <1>
-      type: network # <2>
-    - name: lk4pj-int
-      type: network
-# ...
-----
-<1> Delete the `name` value for the external load balancer, which ends in `-ext`.
-<2> Delete the `type` value for the external load balancer.
-endif::cpmso-using-aws[]
-
 ifdef::post-install[]
 . AWS clusters: Remove the external load balancers:
 +
@@ -155,6 +113,48 @@ providerSpec:
 .... Repeat this process for each of the control plane machines.
 endif::post-install[]
 
+. In the web portal or console for your cloud provider, take the following actions:
+
+.. Locate and delete the appropriate load balancer component:
+ifndef::cpmso-using-azure[]
+*** For AWS, delete the external load balancer. The API DNS entry in the private zone already points to the internal load balancer, which uses an identical configuration, so you do not need to modify the internal load balancer.
+endif::cpmso-using-azure[]
+ifndef::cpmso-using-aws[]
+*** For Azure, delete the `api-internal-v4` rule for the public load balancer.
+
+.. For Azure, configure the Ingress Controller endpoint publishing scope to `Internal`.
+For more information, see "Configuring the Ingress Controller endpoint publishing scope to Internal".
+
+.. For the Azure public load balancer, if you configure the Ingress Controller endpoint publishing scope to `Internal` and there are no existing inbound rules in the public load balancer, you must create an outbound rule explicitly to provide outbound traffic for the backend address pool.
+For more information, see the Microsoft Azure documentation about adding outbound rules.
+endif::cpmso-using-aws[]
+
+.. Delete the
+ifdef::cpmso-using-aws[`api.$clustername.$yourdomain`]
+ifdef::post-install[`api.$clustername.$yourdomain` or]
+ifndef::cpmso-using-aws[`api.$clustername`]
+DNS entry in the public zone.
+
+ifdef::cpmso-using-aws[]
+. Remove the external load balancers by deleting the following indicated lines in the control plane machine set custom resource:
++
+[source,yaml]
+----
+# ...
+providerSpec:
+  value:
+# ...
+    loadBalancers:
+    - name: lk4pj-ext # <1>
+      type: network # <2>
+    - name: lk4pj-int
+      type: network
+# ...
+----
+<1> Delete the `name` value for the external load balancer, which ends in `-ext`.
+<2> Delete the `type` value for the external load balancer.
+endif::cpmso-using-aws[]
+
 ifeval::["{context}" == "configuring-private-cluster"]
 :!post-install:
 endif::[]
diff --git a/modules/ptp-events-consumer-application-v2.adoc b/modules/ptp-events-consumer-application-v2.adoc
index 3288fa9ca171..e67791640668 100644
--- a/modules/ptp-events-consumer-application-v2.adoc
+++ b/modules/ptp-events-consumer-application-v2.adoc
@@ -32,9 +32,8 @@ func getEvent(w http.ResponseWriter, req *http.Request) {
   if e != "" {
     processEvent(bodyBytes)
     log.Infof("received event %s", string(bodyBytes))
-  } else {
-    w.WriteHeader(http.StatusNoContent)
   }
+  w.WriteHeader(http.StatusNoContent)
 }
 ----
 
@@ -58,7 +57,7 @@ s5,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/clock-class"
 func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) {
   var status int
   apiPath := "/api/ocloudNotifications/v2/"
-  localAPIAddr := "localhost:8989" // vDU service API address
+  localAPIAddr := "consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" // vDU service API address
   apiAddr := "ptp-event-publisher-service-<node_name>.openshift-ptp.svc.cluster.local:9043" // <1>
   apiVersion := "2.0"
 
diff --git a/modules/ptp-reference-deployment-and-service-crs-v2.adoc b/modules/ptp-reference-deployment-and-service-crs-v2.adoc
index 1419d4cd5ca5..1399f1afcf92 100644
--- a/modules/ptp-reference-deployment-and-service-crs-v2.adoc
+++ b/modules/ptp-reference-deployment-and-service-crs-v2.adoc
@@ -58,8 +58,6 @@ spec:
           args:
             - "--local-api-addr=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
             - "--api-path=/api/ocloudNotifications/v2/"
-            - "--api-addr=127.0.0.1:8089"
-            - "--api-version=2.0"
             - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
           env:
             - name: NODE_NAME
diff --git a/modules/querying-cluster-node-journal-logs.adoc b/modules/querying-cluster-node-journal-logs.adoc
index 2528c2064a55..e09bcacada84 100644
--- a/modules/querying-cluster-node-journal-logs.adoc
+++ b/modules/querying-cluster-node-journal-logs.adoc
@@ -21,21 +21,32 @@ In {product-title} deployments, customers who are not using the Customer Cloud S
 +
 endif::openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have SSH access to your hosts.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
+ifndef::openshift-rosa-hcp[]
 . Query `kubelet` `journald` unit logs from {product-title} cluster nodes. The following example queries control plane nodes only:
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* Query `kubelet` `journald` unit logs from {product-title} cluster nodes. The following example queries worker nodes only:
+endif::openshift-rosa-hcp[]
 +
 [source,terminal]
 ----
+ifndef::openshift-rosa-hcp[]
 $ oc adm node-logs --role=master -u kubelet  <1>
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+$ oc adm node-logs --role=worker -u kubelet  <1>
+endif::openshift-rosa-hcp[]
 ----
 <1> Replace `kubelet` as appropriate to query other unit logs.
 
+ifndef::openshift-rosa-hcp[]
 . Collect logs from specific subdirectories under `/var/log/` on cluster nodes.
 .. Retrieve a list of logs contained within a `/var/log/` subdirectory. The following example lists files in `/var/log/openshift-apiserver/` on all control plane nodes:
 +
@@ -50,8 +61,9 @@ $ oc adm node-logs --role=master --path=openshift-apiserver
 ----
 $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
 ----
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
-ifndef::openshift-rosa,openshift-dedicated[]
 .. If the API is not functional, review the logs on each node using SSH instead. The following example tails `/var/log/openshift-apiserver/audit.log`:
 +
 [source,terminal]
@@ -63,4 +75,4 @@ $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/open
 ====
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes by using SSH is not recommended. Before attempting to collect diagnostic data over SSH, review whether the data collected by running `oc adm must gather` and other `oc` commands is sufficient instead. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>`.
 ====
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/modules/querying-operator-pod-status.adoc b/modules/querying-operator-pod-status.adoc
index d0c0f8e73c4d..ce32a1aa7639 100644
--- a/modules/querying-operator-pod-status.adoc
+++ b/modules/querying-operator-pod-status.adoc
@@ -10,12 +10,12 @@ You can list Operator pods within a cluster and their status. You can also colle
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 
@@ -42,7 +42,7 @@ $ oc get pod -n <operator_namespace>
 $ oc describe pod <operator_pod_name> -n <operator_namespace>
 ----
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 . If an Operator issue is node-specific, query Operator container status on that node.
 .. Start a debug pod for the node:
 +
@@ -78,4 +78,4 @@ $ oc debug node/my-node
 ----
 +
 .. Exit from the debug shell.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/modules/rbac-creating-local-role.adoc b/modules/rbac-creating-local-role.adoc
index 10f919adf453..e97ed89f7d1e 100644
--- a/modules/rbac-creating-local-role.adoc
+++ b/modules/rbac-creating-local-role.adoc
@@ -4,7 +4,7 @@
 // * post_installation_configuration/preparing-for-users.adoc
 
 :_mod-docs-content-type: PROCEDURE
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [id="creating-local-role_{context}"]
 = Creating a local role
 
diff --git a/modules/rbac-overview.adoc b/modules/rbac-overview.adoc
index 344f226f9002..ac87676996df 100644
--- a/modules/rbac-overview.adoc
+++ b/modules/rbac-overview.adoc
@@ -13,9 +13,9 @@ perform a given action within a project.
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 Cluster administrators
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can use the cluster roles and bindings to control who has various access levels to the {product-title} platform itself and all projects.
 
 Developers can use local roles and bindings to control who has access
@@ -38,7 +38,7 @@ to multiple roles.
 |Bindings |Associations between users and/or groups with a role.
 |===
 
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 There are two levels of RBAC roles and bindings that control authorization:
 
 [cols="1,4",options="header"]
@@ -171,7 +171,7 @@ apply to the user or their groups.
 . If no matching rule is found, the action is then denied by default.
 
 
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [TIP]
 ====
@@ -180,13 +180,13 @@ roles at the same time.
 ====
 
 Project administrators can use the CLI to
-endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 view local roles and bindings,
-endif::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+endif::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 including a matrix of the verbs and resources each are associated with.
 
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 The cluster role bound to the project administrator is limited in a project
@@ -195,9 +195,9 @@ through a local binding. It is not bound cluster-wide like the cluster roles gra
 Cluster roles are roles defined at the cluster level but can be bound either at
 the cluster level or at the project level.
 ====
-endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
+endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [id="cluster-role-aggregations_{context}"]
 === Cluster role aggregation
 The default admin, edit, view, and cluster-reader cluster roles support
diff --git a/modules/rbac-projects-namespaces.adoc b/modules/rbac-projects-namespaces.adoc
index 9bfbfb7de2bc..ade42d4e324e 100644
--- a/modules/rbac-projects-namespaces.adoc
+++ b/modules/rbac-projects-namespaces.adoc
@@ -54,19 +54,19 @@ Each project scopes its own set of:
 
 |===
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can create projects and delegate administrative rights for the project to any member of the user community.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can also allow developers to create their own projects.
 
 Developers and administrators can interact with projects by using the CLI or the
diff --git a/modules/rbac-viewing-cluster-roles.adoc b/modules/rbac-viewing-cluster-roles.adoc
index b52243c7e038..a744f184d961 100644
--- a/modules/rbac-viewing-cluster-roles.adoc
+++ b/modules/rbac-viewing-cluster-roles.adoc
@@ -24,7 +24,7 @@ endif::[]
 
 . To view the cluster roles and their associated rule sets:
 +
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [source,terminal]
 ----
 $ oc describe clusterrole.rbac
@@ -224,7 +224,7 @@ endif::[]
 . To view the current set of cluster role bindings, which shows the users and
 groups that are bound to various roles:
 +
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [source,terminal]
 ----
 $ oc describe clusterrolebinding.rbac
diff --git a/modules/recommended-etcd-practices.adoc b/modules/recommended-etcd-practices.adoc
index f9840844bb87..e600f05226fa 100644
--- a/modules/recommended-etcd-practices.adoc
+++ b/modules/recommended-etcd-practices.adoc
@@ -10,7 +10,7 @@ Because etcd writes data to disk and persists proposals on disk, its performance
 
 Those latencies can cause etcd to miss heartbeats, not commit new proposals to the disk on time, and ultimately experience request timeouts and temporary leader loss. High write latencies also lead to an OpenShift API slowness, which affects cluster performance. Because of these reasons, avoid colocating other workloads on the control-plane nodes that are I/O sensitive or intensive and share the same underlying I/O infrastructure.
 
-Run etcd on a block device that can write at least 50 IOPS of 8KB sequentially, including fdatasync, in under 10ms. For heavy loaded clusters, sequential 500 IOPS of 8000 bytes (2 ms) are recommended. To measure those numbers, you can use a benchmarking tool, such as fio.
+Run etcd on a block device that can write at least 50 IOPS of 8KB sequentially, including fdatasync, in under 10ms. For heavy loaded clusters, sequential 500 IOPS of 8000 bytes (2 ms) are recommended. To measure those numbers, you can use a benchmarking tool, such as the `fio` command.
 
 To achieve such performance, run etcd on machines that are backed by SSD or NVMe disks with low latency and high throughput. Consider single-level cell (SLC) solid-state drives (SSDs), which provide 1 bit per memory cell, are durable and reliable, and are ideal for write-intensive workloads.
 
@@ -28,7 +28,7 @@ The following hard drive practices provide optimal etcd performance:
 * Use solid state drives as a minimum selection. Prefer NVMe drives for production environments.
 * Use server-grade hardware for increased reliability.
 * Avoid NAS or SAN setups and spinning drives. Ceph Rados Block Device (RBD) and other types of network-attached storage can result in unpredictable network latency. To provide fast storage to etcd nodes at scale, use PCI passthrough to pass NVM devices directly to the nodes.
-* Always benchmark by using utilities such as fio. You can use such utilities to continuously monitor the cluster performance as it increases.
+* Always benchmark by using utilities such as `fio`. You can use such utilities to continuously monitor the cluster performance as it increases.
 * Avoid using the Network File System (NFS) protocol or other network based file systems.
 
 Some key metrics to monitor on a deployed {product-title} cluster are p99 of etcd disk write ahead log duration and the number of etcd leader changes. Use Prometheus to track these metrics.
diff --git a/modules/references-regions-zones-infrastructure-vsphere.adoc b/modules/references-regions-zones-infrastructure-vsphere.adoc
index c1179edac36a..762b17bffc38 100644
--- a/modules/references-regions-zones-infrastructure-vsphere.adoc
+++ b/modules/references-regions-zones-infrastructure-vsphere.adoc
@@ -13,7 +13,7 @@ The following table lists mandatory parameters for defining multiple regions and
 |===
 |Parameter | Description
 
-|`vcenters` | The vCenter servers for your {product-title} cluster. You can specify either a single vCenter, or up to 3 vCenters, which is currently a Technology Preview feature.
+|`vcenters` | The vCenter servers for your {product-title} cluster. You can specify either a single vCenter, or up to 3 vCenters.
 |`datacenters` | vCenter data centers where VMs associated with the {product-title} cluster will be created or presently exist.
 |`port` | The TCP port of the vCenter server.
 |`server` | The fully qualified domain name (FQDN) of the vCenter server.
diff --git a/modules/refreshing-service-ids-ibm-cloud.adoc b/modules/refreshing-service-ids-ibm-cloud.adoc
index 9a4dd815bd28..cb1a1c2c2d4b 100644
--- a/modules/refreshing-service-ids-ibm-cloud.adoc
+++ b/modules/refreshing-service-ids-ibm-cloud.adoc
@@ -1,27 +1,27 @@
 // Module included in the following assemblies:
 //
-// * post_installation_configuration/cluster-tasks.adoc
+// * post_installation_configuration/changing-cloud-credentials-configuration.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="refreshing-service-ids-ibm-cloud_{context}"]
-= Rotating API keys
+= Rotating {ibm-cloud-title} credentials
 
 You can rotate API keys for your existing service IDs and update the corresponding secrets.
 
 .Prerequisites
 
-* You have configured the `ccoctl` binary.
+* You have configured the `ccoctl` utility.
 * You have existing service IDs in a live {product-title} cluster installed.
 
 .Procedure
 
-* Use the `ccoctl` utility to rotate your API keys for the service IDs and update the secrets:
+* Use the `ccoctl` utility to rotate your API keys for the service IDs and update the secrets by running the following command:
 +
 [source,terminal]
 ----
-$ ccoctl <provider_name> refresh-keys \ <1>
-    --kubeconfig <openshift_kubeconfig_file> \ <2>
-    --credentials-requests-dir <path_to_credential_requests_directory> \ <3>
+$ ccoctl <provider_name> refresh-keys \// <1>
+    --kubeconfig <openshift_kubeconfig_file> \// <2>
+    --credentials-requests-dir <path_to_credential_requests_directory> \// <3>
     --name <name> <4>
 ----
 <1> The name of the provider. For example: `ibmcloud` or `powervs`.
@@ -34,4 +34,4 @@ $ ccoctl <provider_name> refresh-keys \ <1>
 ====
 If your cluster uses Technology Preview features that are enabled by the `TechPreviewNoUpgrade` feature set, you must include the `--enable-tech-preview` parameter.
 ====
---
+--
\ No newline at end of file
diff --git a/modules/registry-configuring-registry-storage-rhodf-cephfs.adoc b/modules/registry-configuring-registry-storage-rhodf-cephfs.adoc
index 82bf8891ae10..a94e87671acb 100644
--- a/modules/registry-configuring-registry-storage-rhodf-cephfs.adoc
+++ b/modules/registry-configuring-registry-storage-rhodf-cephfs.adoc
@@ -12,7 +12,7 @@
 
 {rh-storage-first} integrates multiple storage types that you can use with the {product-registry}:
 
-* Ceph, a shared and distributed file system and on-premises object storage
+* Ceph, a shared and distributed file system and on-premise object storage
 * NooBaa, providing a Multicloud Object Gateway
 
 This document outlines the procedure to configure the image registry to use CephFS storage.
@@ -27,7 +27,7 @@ CephFS uses persistent volume claim (PVC) storage. It is not recommended to use
 * You have access to the cluster as a user with the `cluster-admin` role.
 * You have access to the {product-title} web console.
 * You installed the `oc` CLI.
-* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17[{rh-storage} Operator] to provide object storage and CephFS file storage.
+* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18[{rh-storage} Operator] to provide object storage and CephFS file storage.
 
 
 .Procedure
diff --git a/modules/registry-configuring-registry-storage-rhodf-cephrgw.adoc b/modules/registry-configuring-registry-storage-rhodf-cephrgw.adoc
index 72f72339a3ac..d499bb85125f 100644
--- a/modules/registry-configuring-registry-storage-rhodf-cephrgw.adoc
+++ b/modules/registry-configuring-registry-storage-rhodf-cephrgw.adoc
@@ -12,7 +12,7 @@
 
 {rh-storage-first} integrates multiple storage types that you can use with the {product-registry}:
 
-* Ceph, a shared and distributed file system and on-premises object storage
+* Ceph, a shared and distributed file system and on-premise object storage
 * NooBaa, providing a Multicloud Object Gateway
 
 This document outlines the procedure to configure the image registry to use Ceph RGW storage.
@@ -23,7 +23,7 @@ This document outlines the procedure to configure the image registry to use Ceph
 * You have access to the cluster as a user with the `cluster-admin` role.
 * You have access to the {product-title} web console.
 * You installed the `oc` CLI.
-* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17[{rh-storage} Operator] to provide object storage and Ceph RGW object storage.
+* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18[{rh-storage} Operator] to provide object storage and Ceph RGW object storage.
 
 .Procedure
 
diff --git a/modules/registry-configuring-registry-storage-rhodf-nooba.adoc b/modules/registry-configuring-registry-storage-rhodf-nooba.adoc
index ac233ff0b4a0..63cccb13175b 100644
--- a/modules/registry-configuring-registry-storage-rhodf-nooba.adoc
+++ b/modules/registry-configuring-registry-storage-rhodf-nooba.adoc
@@ -12,7 +12,7 @@
 
 {rh-storage-first} integrates multiple storage types that you can use with the {product-registry}:
 
-* Ceph, a shared and distributed file system and on-premises object storage
+* Ceph, a shared and distributed file system and on-premise object storage
 * NooBaa, providing a Multicloud Object Gateway
 
 This document outlines the procedure to configure the image registry to use Noobaa storage.
@@ -22,7 +22,7 @@ This document outlines the procedure to configure the image registry to use Noob
 * You have access to the cluster as a user with the `cluster-admin` role.
 * You have access to the {product-title} web console.
 * You installed the `oc` CLI.
-* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17[{rh-storage} Operator] to provide object storage and Noobaa object storage.
+* You installed the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18[{rh-storage} Operator] to provide object storage and Noobaa object storage.
 
 .Procedure
 
diff --git a/modules/registry-exposing-default-registry-manually.adoc b/modules/registry-exposing-default-registry-manually.adoc
index 284c330deddf..d229198a4a36 100644
--- a/modules/registry-exposing-default-registry-manually.adoc
+++ b/modules/registry-exposing-default-registry-manually.adoc
@@ -17,35 +17,42 @@ You can expose the route by using the `defaultRoute` parameter in the `configs.i
 
 To expose the registry using the `defaultRoute`:
 
-. Set `defaultRoute` to `true`:
+. Set `defaultRoute` to `true` by running the following command:
 +
 [source,terminal]
 ----
 $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
 ----
 +
-. Get the default registry route:
+. Get the default registry route by running the following command:
 +
 [source,terminal]
 ----
 $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
 ----
 
-. Get the certificate of the Ingress Operator:
+. Get the certificate of the Ingress Operator by running the following command:
 +
 [source,terminal]
 ----
 $ oc extract secret/$(oc get ingresscontroller -n openshift-ingress-operator default -o json | jq '.spec.defaultCertificate.name // "router-certs-default"' -r) -n openshift-ingress --confirm
 ----
 
-. Enable the cluster's default certificate to trust the route using the following commands:
+. Move the extracted certificate to the system's trusted CA directory by running the following command:
++
+[source,terminal]
+----
+$ sudo mv tls.crt /etc/pki/ca-trust/source/anchors/
+----
+
+. Enable the cluster's default certificate to trust the route by running the following command:
 +
 [source,terminal]
 ----
 $ sudo update-ca-trust enable
 ----
 
-. Log in with podman using the default route:
+. Log in with podman using the default route by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/removing-bare-metal-hosts-from-provisioner.adoc b/modules/removing-bare-metal-hosts-from-provisioner.adoc
index d87f3341f480..f06af3e7d9b5 100644
--- a/modules/removing-bare-metal-hosts-from-provisioner.adoc
+++ b/modules/removing-bare-metal-hosts-from-provisioner.adoc
@@ -42,4 +42,4 @@ When you use a `BareMetalHost` object to create a machine in the cluster and lab
 [source,terminal]
 ----
 $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'
-----
\ No newline at end of file
+----
diff --git a/modules/restore-replace-stopped-etcd-member.adoc b/modules/restore-replace-stopped-etcd-member.adoc
index 5cbdf6fc83ab..814bee245974 100644
--- a/modules/restore-replace-stopped-etcd-member.adoc
+++ b/modules/restore-replace-stopped-etcd-member.adoc
@@ -28,14 +28,14 @@ You must wait if you power off other control plane nodes. The control plane node
 +
 [IMPORTANT]
 ====
-It is important to take an etcd backup before performing this procedure, so that you can restore your cluster if you experience any issues.
+Before you perform this procedure, take an etcd backup so that you can restore your cluster if you experience any issues.
 ====
 
 .Procedure
 
 . Remove the unhealthy member.
 
-.. Choose a pod that is _not_ on the affected node:
+.. Choose a pod that is not on the affected node:
 +
 In a terminal that has access to the cluster as a `cluster-admin` user, run the following command:
 +
@@ -80,7 +80,7 @@ sh-4.2# etcdctl member list -w table
 +------------------+---------+------------------------------+---------------------------+---------------------------+
 ----
 +
-Take note of the ID and the name of the unhealthy etcd member, because these values are needed later in the procedure. The `$ etcdctl endpoint health` command will list the removed member until the procedure of replacement is finished and a new member is added.
+Take note of the ID and the name of the unhealthy etcd member because these values are needed later in the procedure. The `$ etcdctl endpoint health` command will list the removed member until the procedure of replacement is finished and a new member is added.
 
 .. Remove the unhealthy etcd member by providing the ID to the `etcdctl member remove` command:
 +
@@ -190,9 +190,16 @@ $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
 $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
 ----
 
-. Delete and re-create the control plane machine. After this machine is re-created, a new revision is forced and etcd scales up automatically. See "Replacing an unhealthy etcd member whose machine is not running or whose node is not ready" for more information.
+. Check whether a control plane machine set exists by entering the following command:
 +
-If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps. Otherwise, you must create the new master using the same method that was used to originally create it.
+[source,terminal]
+----
+$ oc -n openshift-machine-api get controlplanemachineset
+----
+
+* If the control plane machine set exists, delete and re-create the control plane machine. After this machine is re-created, a new revision is forced and etcd scales up automatically. For more information, see "Replacing an unhealthy etcd member whose machine is not running or whose node is not ready".
++
+If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps. Otherwise, you must create the new control plane by using the same method that was used to originally create it.
 
 .. Obtain the machine for the unhealthy member.
 +
@@ -226,7 +233,7 @@ $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 <1>
 +
 A new machine is automatically provisioned after deleting the machine of the unhealthy member.
 
-.. Verify that a new machine has been created:
+.. Verify that a new machine was created:
 +
 [source,terminal]
 ----
@@ -246,7 +253,161 @@ clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1
 ----
 <1> The new machine, `clustername-8qw5l-master-3` is being created and is ready once the phase changes from `Provisioning` to `Running`.
 +
-It might take a few minutes for the new machine to be created. The etcd cluster Operator will automatically sync when the machine or node returns to a healthy state.
+It might take a few minutes for the new machine to be created. The etcd cluster Operator automatically syncs when the machine or node returns to a healthy state.
++
+[NOTE]
+====
+Verify the subnet IDs that you are using for your machine sets to ensure that they end up in the correct availability zone.
+====
+
+* If the control plane machine set does not exist, delete and re-create the control plane machine. After this machine is re-created, a new revision is forced and etcd scales up automatically.
++
+If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps. Otherwise, you must create the new control plane by using the same method that was used to originally create it.
+
+.. Obtain the machine for the unhealthy member.
++
+In a terminal that has access to the cluster as a `cluster-admin` user, run the following command:
++
+[source,terminal]
+----
+$ oc get machines -n openshift-machine-api -o wide
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
+clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped <1>
+clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
+clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
+clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
+clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
+clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
+----
+<1> This is the control plane machine for the unhealthy node, `ip-10-0-131-183.ec2.internal`.
+
+.. Save the machine configuration to a file on your file system:
++
+[source,terminal]
+----
+$ oc get machine clustername-8qw5l-master-0 \ <1>
+    -n openshift-machine-api \
+    -o yaml \
+    > new-master-machine.yaml
+----
+<1> Specify the name of the control plane machine for the unhealthy node.
+
+.. Edit the `new-master-machine.yaml` file that was created in the previous step to assign a new name and remove unnecessary fields.
+
+... Remove the entire `status` section:
++
+[source,yaml]
+----
+status:
+  addresses:
+  - address: 10.0.131.183
+    type: InternalIP
+  - address: ip-10-0-131-183.ec2.internal
+    type: InternalDNS
+  - address: ip-10-0-131-183.ec2.internal
+    type: Hostname
+  lastUpdated: "2020-04-20T17:44:29Z"
+  nodeRef:
+    kind: Node
+    name: ip-10-0-131-183.ec2.internal
+    uid: acca4411-af0d-4387-b73e-52b2484295ad
+  phase: Running
+  providerStatus:
+    apiVersion: awsproviderconfig.openshift.io/v1beta1
+    conditions:
+    - lastProbeTime: "2020-04-20T16:53:50Z"
+      lastTransitionTime: "2020-04-20T16:53:50Z"
+      message: machine successfully created
+      reason: MachineCreationSucceeded
+      status: "True"
+      type: MachineCreation
+    instanceId: i-0fdb85790d76d0c3f
+    instanceState: stopped
+    kind: AWSMachineProviderStatus
+----
+
+... Change the `metadata.name` field to a new name.
++
+Keep the same base name as the old machine and change the ending number to the next available number. In this example, `clustername-8qw5l-master-0` is changed to `clustername-8qw5l-master-3`.
++
+For example:
++
+[source,yaml]
+----
+apiVersion: machine.openshift.io/v1beta1
+kind: Machine
+metadata:
+  ...
+  name: clustername-8qw5l-master-3
+  ...
+----
+
+... Remove the `spec.providerID` field:
++
+[source,yaml]
+----
+  providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
+----
+
+.. Delete the machine of the unhealthy member:
++
+[source,terminal]
+----
+$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 <1>
+----
+<1> Specify the name of the control plane machine for the unhealthy node.
+
+.. Verify that the machine was deleted:
++
+[source,terminal]
+----
+$ oc get machines -n openshift-machine-api -o wide
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
+clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
+clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
+clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
+clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
+clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
+----
+
+.. Create the new machine by using the `new-master-machine.yaml` file:
++
+[source,terminal]
+----
+$ oc apply -f new-master-machine.yaml
+----
+
+.. Verify that the new machine was created:
++
+[source,terminal]
+----
+$ oc get machines -n openshift-machine-api -o wide
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
+clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
+clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
+clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running <1>
+clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
+clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
+clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
+----
+<1> The new machine, `clustername-8qw5l-master-3` is being created and is ready once the phase changes from `Provisioning` to `Running`.
++
+It might take a few minutes for the new machine to be created. The etcd cluster Operator automatically syncs when the machine or node returns to a healthy state.
 
 . Turn the quorum guard back on by entering the following command:
 +
@@ -332,4 +493,4 @@ If the output from the previous command lists more than three etcd members, you
 [WARNING]
 ====
 Be sure to remove the correct etcd member; removing a good etcd member might lead to quorum loss.
-====
+====
\ No newline at end of file
diff --git a/modules/restoring-the-backend-redis-database.adoc b/modules/restoring-the-backend-redis-database.adoc
new file mode 100644
index 000000000000..623d7272d0be
--- /dev/null
+++ b/modules/restoring-the-backend-redis-database.adoc
@@ -0,0 +1,84 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="restoring-the-backend-redis-database_{context}"]
+= Restoring the back-end Redis database
+
+You can restore the back-end Redis database by deleting the deployment and specifying which resources you do not want to restore.
+
+.Prerequisites
+
+* You restored the Secret and APIManager custom resources.
+* You restored the `mysql` database.
+
+.Procedure
+
+. Delete the `backend-redis` deployment by running the following command:
++
+[source,terminal]
+----
+$ oc delete deployment backend-redis -n threescale
+----
++
+.Example output:
++
+[source,terminal]
+----
+Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
+
+deployment.apps.openshift.io "backend-redis" deleted
+----
+
+. Create a YAML file with the following configuration to restore the Redis database:
++
+.Example `restore-backend.yaml` file
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: restore-backend
+  namespace: openshift-adp
+spec:
+  backupName: redis-backup
+  excludedResources:
+    - nodes
+    - events
+    - events.events.k8s.io
+    - backups.velero.io
+    - restores.velero.io
+    - resticrepositories.velero.io
+    - csinodes.storage.k8s.io
+    - volumeattachments.storage.k8s.io
+    - backuprepositories.velero.io
+  itemOperationTimeout: 1h0m0s
+  restorePVs: true
+----
+
+. Restore the Redis database by running the following command:
++
+[source,terminal]
+----
+$ oc create -f restore-backend.yaml
+----
+
+.Verification 
+
+* Verify that the `PodVolumeRestore` restore is completed by running the following command:
++
+[source,terminal]
+----
+$ oc get podvolumerestores.velero.io -n openshift-adp
+----
+.Example output:
++
+[source,terminal]
+----
+NAME                    NAMESPACE    POD                     UPLOADER TYPE   VOLUME                  STATUS      TOTALBYTES   BYTESDONE   AGE
+restore-backend-jmrwx   threescale   backend-redis-1-bsfmv   kopia           backend-redis-storage   Completed   76123        76123       21m
+----
+
+.Next steps
+
+* Scale the 3scale Operator and deployment.
\ No newline at end of file
diff --git a/modules/restoring-the-mysql-database.adoc b/modules/restoring-the-mysql-database.adoc
new file mode 100644
index 000000000000..7dabb625656b
--- /dev/null
+++ b/modules/restoring-the-mysql-database.adoc
@@ -0,0 +1,183 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="restoring-the-mysql-database_{context}"]
+= Restoring the mysql database
+
+Restoring the `mysql` database re-creates the following resources:
+
+* The `Pod`, `ReplicationController`, and `Deployment` objects.
+* The additional persistent volumes (PVs) and associated persistent volume claims (PVCs). 
+* The `mysql` dump, which the `example-claim` PVC contains.
+
+[WARNING]
+====
+Do not delete the default PV and PVC associated with the database. If you do, your backups are deleted.
+====
+
+.Prerequisites
+
+* You restored the Secret and APIManager custom resources (CR).
+
+.Procedure
+
+. Scale down the 3scale Operator by running the following command:
++
+[source,terminal]
+----
+$ oc scale deployment threescale-operator-controller-manager-v2 --replicas=0 -n threescale
+----
++
+.Example output:
+[source,terminal]
+----
+deployment.apps/threescale-operator-controller-manager-v2 scaled
+----
+
+. Create the following script to scale down the 3scale operator:
++
+[source,terminal]
+----
+$ vi ./scaledowndeployment.sh
+----
++
+.Example output:
+[source,terminal]
+----
+for deployment in apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-searchd system-sidekiq zync zync-database zync-que; do
+    oc scale deployment/$deployment --replicas=0 -n threescale
+done
+----
+
+. Scale down all the deployment 3scale components by running the following script:
++
+[source,terminal]
+----
+$ ./scaledowndeployment.sh 
+----
++
+.Example output:
+[source,terminal]
+----
+deployment.apps.openshift.io/apicast-production scaled
+deployment.apps.openshift.io/apicast-staging scaled
+deployment.apps.openshift.io/backend-cron scaled
+deployment.apps.openshift.io/backend-listener scaled
+deployment.apps.openshift.io/backend-redis scaled
+deployment.apps.openshift.io/backend-worker scaled
+deployment.apps.openshift.io/system-app scaled
+deployment.apps.openshift.io/system-memcache scaled
+deployment.apps.openshift.io/system-mysql scaled
+deployment.apps.openshift.io/system-redis scaled
+deployment.apps.openshift.io/system-searchd scaled
+deployment.apps.openshift.io/system-sidekiq scaled
+deployment.apps.openshift.io/zync scaled
+deployment.apps.openshift.io/zync-database scaled
+deployment.apps.openshift.io/zync-que scaled
+----
+
+. Delete the `system-mysql` `Deployment` object by running the following command:
++
+[source,terminal]
+----
+$ oc delete deployment system-mysql -n threescale
+----
++
+.Example output:
+[source,terminal]
+----
+Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
+deployment.apps.openshift.io "system-mysql" deleted
+----
+
+. Create the following YAML file to restore the `mysql` database:
++
+.Example `restore-mysql.yaml` file
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: restore-mysql
+  namespace: openshift-adp
+spec:
+  backupName: mysql-backup
+  excludedResources:
+    - nodes
+    - events
+    - events.events.k8s.io
+    - backups.velero.io
+    - restores.velero.io
+    - csinodes.storage.k8s.io
+    - volumeattachments.storage.k8s.io
+    - backuprepositories.velero.io
+    - resticrepositories.velero.io
+  hooks:
+    resources:
+      - name: restoreDB
+        postHooks:
+          - exec:
+              command:
+                - /bin/sh
+                - '-c'
+                - >
+                  sleep 30
+                  
+                  mysql -h 127.0.0.1 -D system -u root
+                  --password=$MYSQL_ROOT_PASSWORD <
+                  /var/lib/mysqldump/data/dump.sql <1>
+              container: system-mysql
+              execTimeout: 80s
+              onError: Fail
+              waitTimeout: 5m
+  itemOperationTimeout: 1h0m0s
+  restorePVs: true
+----
+<1> A path where the data is restored from.
+
+. Restore the `mysql` database by running the following command:
++
+[source,terminal]
+----
+$ oc create -f restore-mysql.yaml
+----
+
+.Verification 
+
+. Verify that the `PodVolumeRestore` restore is completed by running the following command:
++
+[source,terminal]
+----
+$ oc get podvolumerestores.velero.io -n openshift-adp
+----
++
+.Example output:
+[source,terminal]
+----
+NAME                    NAMESPACE    POD                     UPLOADER TYPE   VOLUME                  STATUS      TOTALBYTES   BYTESDONE   AGE
+restore-mysql-rbzvm     threescale   system-mysql-2-kjkhl    kopia           mysql-storage           Completed   771879108    771879108   40m
+restore-mysql-z7x7l     threescale   system-mysql-2-kjkhl    kopia           example-claim           Completed   380415       380415      40m
+----
+
+. Verify that the additional PVC has been restored by running the following command:
++
+[source,terminal]
+----
+$ oc get pvc -n threescale
+----
++
+.Example output:
+[source,terminal]
+----
+NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
+backend-redis-storage   Bound    pvc-3dca410d-3b9f-49d4-aebf-75f47152e09d   1Gi        RWO            gp3-csi        <unset>                 68m
+example-claim           Bound    pvc-cbaa49b0-06cd-4b1a-9e90-0ef755c67a54   1Gi        RWO            gp3-csi        <unset>                 57m
+mysql-storage           Bound    pvc-4549649f-b9ad-44f7-8f67-dd6b9dbb3896   1Gi        RWO            gp3-csi        <unset>                 68m
+system-redis-storage    Bound    pvc-04dadafd-8a3e-4d00-8381-6041800a24fc   1Gi        RWO            gp3-csi        <unset>                 68m
+system-searchd          Bound    pvc-afbf606c-d4a8-4041-8ec6-54c5baf1a3b9   1Gi        RWO            gp3-csi        <unset>                 68m
+----
+
+.Next steps
+
+* Restore the back-end Redis database.
\ No newline at end of file
diff --git a/modules/restoring-the-secrets-and-apimanager.adoc b/modules/restoring-the-secrets-and-apimanager.adoc
new file mode 100644
index 000000000000..a67eef2fa470
--- /dev/null
+++ b/modules/restoring-the-secrets-and-apimanager.adoc
@@ -0,0 +1,174 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+
+[id="restoring-the-secrets-and-apimanager_{context}"]
+= Restoring the secrets and APIManager
+
+You can restore the Secrets and APIManager by using the following procedure.
+
+.Prerequisites
+
+* You backed up the 3scale Operator.
+* You backed up `mysql` and Redis databases.
+* You are restoring the database on the same cluster, where it was backed up. 
++
+If it is on a different cluster, install and configure {oadp-short} with `nodeAgent` enabled on the destination cluster as it was on the source cluster.
+
+.Procedure
+
+. Delete the 3scale Operator custom resource definitions (CRDs) along with the `threescale` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc delete project threescale
+----
++
+.Example output
++
+[source,terminal]
+----
+"threescale" project deleted successfully
+----
+
+. Create a YAML file with the following configuration to restore the 3scale Operator:
++
+.Example `restore.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: operator-installation-restore
+  namespace: openshift-adp
+spec:
+  backupName: operator-install-backup
+  excludedResources:
+  - nodes
+  - events
+  - events.events.k8s.io
+  - backups.velero.io
+  - restores.velero.io
+  - resticrepositories.velero.io
+  - csinodes.storage.k8s.io
+  - volumeattachments.storage.k8s.io
+  - backuprepositories.velero.io
+  itemOperationTimeout: 4h0m0s
+----
+
+. Restore the 3scale Operator by running the following command:
++
+[source,terminal]
+----
+$ oc create -f restore.yaml
+----
+
+. Manually create the `s3-credentials` Secret object by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+---
+apiVersion: v1
+kind: Secret
+metadata:
+      name: s3-credentials
+      namespace: threescale
+stringData:
+  AWS_ACCESS_KEY_ID: <ID_123456> <1>
+  AWS_SECRET_ACCESS_KEY: <ID_98765544> <2>
+  AWS_BUCKET: <mybucket.example.com> <3>
+  AWS_REGION: <us-east-1> <4>
+type: Opaque
+EOF
+----
+<1> Replace <ID_123456> with your AWS credentials ID.
+<2> Replace <ID_98765544> with your AWS credentials KEY.
+<3> Replace <mybucket.example.com> with your target bucket name.
+<4> Replace <us-east-1> with the AWS region of your bucket.
+
+. Scale down the 3scale Operator by running the following command:
++
+[source,terminal]
+----
+$ oc scale deployment threescale-operator-controller-manager-v2 --replicas=0 -n threescale
+----
+
+. Create a YAML file with the following configuration to restore the Secrets:
++
+.Example `restore-secret.yaml` file
++
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: operator-resources-secrets
+  namespace: openshift-adp
+spec:
+  backupName: operator-resources-secrets
+  excludedResources:
+  - nodes
+  - events
+  - events.events.k8s.io
+  - backups.velero.io
+  - restores.velero.io
+  - resticrepositories.velero.io
+  - csinodes.storage.k8s.io
+  - volumeattachments.storage.k8s.io
+  - backuprepositories.velero.io
+  itemOperationTimeout: 4h0m0s
+----
+
+. Restore the Secrets by running the following command:
++
+[source,terminal]
+----
+$ oc create -f restore-secrets.yaml
+----
+
+. Create a YAML file with the following configuration to restore APIManager:
++
+.Example `restore-apimanager.yaml` file
+[source,yaml]
+----
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: operator-resources-apim
+  namespace: openshift-adp
+spec:
+  backupName: operator-resources-apim
+  excludedResources: <1>
+  - nodes
+  - events
+  - events.events.k8s.io
+  - backups.velero.io
+  - restores.velero.io
+  - resticrepositories.velero.io
+  - csinodes.storage.k8s.io
+  - volumeattachments.storage.k8s.io
+  - backuprepositories.velero.io
+  itemOperationTimeout: 4h0m0s
+----
+<1> The resources that you do not want to restore.
+
+. Restore the APIManager by running the following command:
++
+[source,terminal]
+----
+$ oc create -f restore-apimanager.yaml
+----
+
+. Scale up the 3scale Operator by running the following command:
++
+[source,terminal]
+----
+$ oc scale deployment threescale-operator-controller-manager-v2 --replicas=1 -n threescale
+----
+
+.Next steps
+
+* Restore the `mysql` database.
\ No newline at end of file
diff --git a/modules/restrictions-on-ip-assignment.adoc b/modules/restrictions-on-ip-assignment.adoc
new file mode 100644
index 000000000000..d663dac185b5
--- /dev/null
+++ b/modules/restrictions-on-ip-assignment.adoc
@@ -0,0 +1,31 @@
+// Module included in the following assemblies:
+//
+// * networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="restrictions-on-ip-assignment_{context}"]
+= Restrictions on the assignment of an external IP address
+
+As a cluster administrator, you can specify IP address blocks to allow and to reject IP addresses for a service. Restrictions apply only to users without `cluster-admin` privileges. A cluster administrator can always set the service `spec.externalIPs[]` field to any IP address.
+
+You configure an IP address policy by specifying Classless Inter-Domain Routing (CIDR) address blocks for the `spec.ExternalIP.policy` parameter in the `policy` object. 
+
+.Example in JSON form of a `policy` object and its CIDR parameters
+[source,json]
+----
+{
+  "policy": {
+    "allowedCIDRs": [],
+    "rejectedCIDRs": []
+  }
+}
+----
+
+When configuring policy restrictions, the following rules apply:
+
+- If `policy` is set to `{}`, creating a `Service` object with `spec.ExternalIPs[]` results in a failed service. This setting is the default for {product-title}. The same behavior exists for `policy: null`.
+- If `policy` is set and either `policy.allowedCIDRs[]` or `policy.rejectedCIDRs[]` is set, the following rules apply:
+
+* If `allowedCIDRs[]` and `rejectedCIDRs[]` are both set, `rejectedCIDRs[]` has precedence over `allowedCIDRs[]`.
+* If `allowedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` succeeds only if the specified IP addresses are allowed.
+* If `rejectedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` succeeds only if the specified IP addresses are not rejected.
diff --git a/modules/reviewing-node-status-usage-and-configuration.adoc b/modules/reviewing-node-status-usage-and-configuration.adoc
index 3f0a26f5d0d0..fb37331cecb3 100644
--- a/modules/reviewing-node-status-usage-and-configuration.adoc
+++ b/modules/reviewing-node-status-usage-and-configuration.adoc
@@ -10,12 +10,12 @@ Review cluster node health status, resource consumption statistics, and node log
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/reviewing-pod-status.adoc b/modules/reviewing-pod-status.adoc
index c6185abb5fd5..adaf100a3357 100644
--- a/modules/reviewing-pod-status.adoc
+++ b/modules/reviewing-pod-status.adoc
@@ -10,12 +10,12 @@ You can query pod status and error states. You can also query a pod's associated
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
 * `skopeo` is installed.
 
diff --git a/modules/rhcos-add-extensions.adoc b/modules/rhcos-add-extensions.adoc
index 23a9afdff8ac..e060e1841dc9 100644
--- a/modules/rhcos-add-extensions.adoc
+++ b/modules/rhcos-add-extensions.adoc
@@ -6,13 +6,24 @@
 [id="rhcos-add-extensions_{context}"]
 
 = Adding extensions to {op-system}
-{op-system} is a minimal container-oriented RHEL operating system, designed to provide a common set of capabilities to {product-title} clusters across all platforms. While adding software packages to {op-system} systems is generally discouraged, the MCO provides an `extensions` feature you can use to add a minimal set of features to {op-system} nodes.
+
+{op-system} is a minimal container-oriented RHEL operating system, designed to provide a common set of capabilities to {product-title} clusters across all platforms. Although adding software packages to {op-system} systems is generally discouraged, the MCO provides an `extensions` feature you can use to add a minimal set of features to {op-system} nodes.
 
 Currently, the following extensions are available:
 
-* **usbguard**: Adding the `usbguard` extension protects {op-system} systems from attacks from intrusive USB devices. See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#usbguard_protecting-systems-against-intrusive-usb-devices[USBGuard] for details.
+* **usbguard**: The `usbguard` extension protects {op-system} systems from attacks by intrusive USB devices. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#usbguard_protecting-systems-against-intrusive-usb-devices[USBGuard] for details.
+
+* **kerberos**: The `kerberos` extension provides a mechanism that allows both users and machines to identify themselves to the network to receive defined, limited access to the areas and services that an administrator has configured. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/using_kerberos[Using Kerberos] for details, including how to set up a Kerberos client and mount a Kerberized NFS share.
+
+* **sandboxed-containers**: The `sandboxed-containers` extension contains RPMs for Kata, QEMU, and its dependencies. For more information, see https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/latest[OpenShift Sandboxed Containers].
+
+* **ipsec**: The `ipsec` extension contains RPMs for libreswan and NetworkManager-libreswan.
+
+* **wasm**: The `wasm` extension enables Developer Preview functionality in {product-title} for users who want to use WASM-supported workloads.   
+
+* **sysstat**: Adding the `sysstat` extension provides additional performance monitoring for {product-title} nodes, including the system activity reporter (`sar`) command for collecting and reporting information.
 
-* **kerberos**: Adding the `kerberos` extension provides a mechanism that allows both users and machines to identify themselves to the network to receive defined, limited access to the areas and services that an administrator has configured. See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/using_kerberos[Using Kerberos] for details, including how to set up a Kerberos client and mount a Kerberized NFS share.
+* **kernel-devel**: The `kernel-devel` extension provides kernel headers and makefiles sufficient to build modules against the kernel package.
 
 The following procedure describes how to use a machine config to add one or more extensions to your {op-system} nodes.
 
@@ -36,7 +47,7 @@ metadata:
 spec:
   config:
     ignition:
-      version: 3.2.0
+      version: 3.4.0
   extensions:
     - usbguard
 EOF
@@ -63,7 +74,7 @@ $ oc get machineconfig 80-worker-extensions
 [source,terminal]
 ----
 NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
-80-worker-extensions                       3.2.0           57s
+80-worker-extensions                       3.4.0           57s
 ----
 
 . Check that the new machine config is now applied and that the nodes are not in a degraded state. It may take a few minutes. The worker pool will show the updates in progress, as each machine successfully has the new machine config applied:
diff --git a/modules/rhcos-enabling-multipath-day-2.adoc b/modules/rhcos-enabling-multipath-day-2.adoc
index f967ad2df34c..1789109f0e2c 100644
--- a/modules/rhcos-enabling-multipath-day-2.adoc
+++ b/modules/rhcos-enabling-multipath-day-2.adoc
@@ -8,7 +8,7 @@
 
 [IMPORTANT]
 ====
-Enabling multipathing during installation is supported and recommended for nodes provisioned in {product-title} 4.8 or later versions. In setups where any I/O to non-optimized paths results in I/O system errors, you must enable multipathing at installation time. For more information about enabling multipathing during installation time, see "Enabling multipathing post installation" in the _Installing on bare metal_ documentation.
+Enabling multipathing during installation is supported and recommended for nodes provisioned in {product-title}. In setups where any I/O to non-optimized paths results in I/O system errors, you must enable multipathing at installation time. For more information about enabling multipathing during installation time, see "Enabling multipathing post installation" in the _Installing on bare metal_ documentation.
 ====
 
 {op-system-first} supports multipathing on the primary disk, allowing stronger resilience to hardware failure to achieve higher host availability. Postinstallation support is available by activating multipathing via the machine config.
@@ -21,11 +21,11 @@ On {ibm-z-name} and {ibm-linuxone-name}, you can enable multipathing only if you
 
 [IMPORTANT]
 ====
-When a {product-title} {product-version} cluster is installed or configured as a post-installation activity on a single VIOS host with "vSCSI" storage on {ibm-power-name} with multipath configured, the CoreOS nodes with multipath enabled fail to boot. This behavior is expected, as only one path is available to the Node.
+When an {product-title} cluster is installed or configured as a postinstallation activity on a single VIOS host with "vSCSI" storage on {ibm-power-name} with multipath configured, the CoreOS nodes with multipath enabled fail to boot. This behavior is expected, as only one path is available to the node.
 ====
 
 .Prerequisites
-* You have a running {product-title} cluster that uses version 4.7 or later.
+* You have a running {product-title} cluster.
 * You are logged in to the cluster as a user with administrative privileges.
 * You have confirmed that the disk is enabled for multipathing. Multipathing is only supported on hosts that are connected to a SAN via an HBA adapter.
 
@@ -85,19 +85,19 @@ $ oc get MachineConfig
 [source,terminal]
 ----
 NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
-00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 99-master-ssh                                                                                 3.2.0             40m
-99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
+99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             105s
 99-worker-ssh                                                                                 3.2.0             40m
-rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
-rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
+rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
+rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.4.0             33m
 ----
 
 . Check the nodes:
diff --git a/modules/rhcos-validate-live-media.adoc b/modules/rhcos-validate-live-media.adoc
new file mode 100644
index 000000000000..6742548b4276
--- /dev/null
+++ b/modules/rhcos-validate-live-media.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * installing/validation_and_troubleshooting/valiadting-an-installation.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="rhcos-validate-live-media_{context}"]
+
+= Validating {op-system} live media
+
+The {product-title} installation program contains pinned versions of {op-system} bootimages. Fully automated installations use these pinned artifacts by default. The mirror registry where you downloaded the installation program contains a `sha256sum` encrypted with the Red{nbsp}Hat product key.
+
+For user-provisioned infrastructure installations, you can access information and use the {product-title} installer to indirectly validate {op-system} bootimage artifacts using their SHA-256 checksums.
+
+.Procedure
+
+* Run the following command to print the metadata for any bootimage artifact:
++
+[source,terminal]
+----
+$ openshift-install coreos print-stream-json | jq <bootimage> <1>
+----
+<1> The query for the bootimage you want to obtain information on. For validation purposes, the bootimage artifact must have a generated `sha256sum`. This can include OVA, VHD, QCOW2 and others. For example, to get information on an `x86_64` architecture `iso` file for bare metal platforms, this value would be `.architectures.x86_64.artifacts.metal.formats.iso`.
++
+.Example output
+[source,text]
+----
+{
+  "disk": {
+    "location": "<url>/art/storage/prod/streams/<release>/builds/rhcos-<release>-live.<architecture>.<artifact>",
+    "sha256": "abc2add9746eb7be82e6919ec13aad8e9eae8cf073d8da6126d7c95ea0dee962"
+  }
+}
+----
diff --git a/modules/rhel-compute-requirements.adoc b/modules/rhel-compute-requirements.adoc
index 98ff174d7284..976e56716a42 100644
--- a/modules/rhel-compute-requirements.adoc
+++ b/modules/rhel-compute-requirements.adoc
@@ -42,7 +42,7 @@ endif::[]
 ** Minimum 15 GB hard disk space for the file system containing `/var/`.
 ** Minimum 1 GB hard disk space for the file system containing `/usr/local/bin/`.
 ** Minimum 1 GB hard disk space for the file system containing its temporary directory. The temporary system directory is determined according to the rules defined in the tempfile module in the Python standard library.
-* Each system must meet any additional requirements for your system provider. For example, if you installed your cluster on VMware vSphere, your disks must be configured according to its link:https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/index.html[storage guidelines] and the `disk.enableUUID=true` attribute must be set.
+* Each system must meet any additional requirements for your system provider. For example, if you installed your cluster on VMware vSphere, your disks must be configured according to its link:https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/master/documentation/prerequisites.md[storage guidelines] and the `disk.enableUUID=TRUE` attribute must be set.
 
 * Each system must be able to access the cluster's API endpoints by using DNS-resolvable hostnames. Any network security access control that is in place must allow system access to the cluster's API service endpoints.
 
diff --git a/modules/rhel-compute-updating.adoc b/modules/rhel-compute-updating.adoc
index eb1f170f5e28..50edd046d5e8 100644
--- a/modules/rhel-compute-updating.adoc
+++ b/modules/rhel-compute-updating.adoc
@@ -52,7 +52,7 @@ By default, the base OS RHEL with "Minimal" installation option enables firewall
 +
 [source,terminal,subs="attributes+"]
 ----
-# subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
+# subscription-manager repos --disable=rhocp-4.17-for-rhel-8-x86_64-rpms \
                              --enable=rhocp-{product-version}-for-rhel-8-x86_64-rpms
 ----
 +
@@ -72,7 +72,7 @@ As of {product-title} 4.11, the Ansible playbooks are provided only for {op-syst
 +
 [source,terminal,subs="attributes+"]
 ----
-# subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
+# subscription-manager repos --disable=rhocp-4.17-for-rhel-8-x86_64-rpms \
                              --enable=rhocp-{product-version}-for-rhel-8-x86_64-rpms
 ----
 
diff --git a/modules/rhel-images-aws.adoc b/modules/rhel-images-aws.adoc
index 24e0609a0444..481ef8d074f1 100644
--- a/modules/rhel-images-aws.adoc
+++ b/modules/rhel-images-aws.adoc
@@ -15,14 +15,14 @@ AMI IDs correspond to native boot images for AWS. Because an AMI must exist befo
 
 .Procedure
 
-* Use this command to list {op-system-base} 8.4 Amazon Machine Images (AMI):
+* Use this command to list {op-system-base} 8.8 Amazon Machine Images (AMI):
 +
 --
 [source,terminal]
 ----
 $ aws ec2 describe-images --owners 309956199498 \ <1>
 --query 'sort_by(Images, &CreationDate)[*].[CreationDate,Name,ImageId]' \ <2>
---filters "Name=name,Values=RHEL-8.4*" \ <3>
+--filters "Name=name,Values=RHEL-8.8*" \ <3>
 --region us-east-1 \ <4>
 --output table <5>
 ----
@@ -33,14 +33,14 @@ $ aws ec2 describe-images --owners 309956199498 \ <1>
 This account ID is required to display AMI IDs for images that are provided by Red Hat.
 ====
 <2> The `--query` command option sets how the images are sorted with the parameters `'sort_by(Images, &CreationDate)[*].[CreationDate,Name,ImageId]'`. In this case, the images are sorted by the creation date, and the table is structured to show the creation date, the name of the image, and the AMI IDs.
-<3> The `--filter` command option sets which version of {op-system-base} is shown. In this example, since the filter is set by `"Name=name,Values=RHEL-8.4*"`, then {op-system-base} 8.4 AMIs are shown.
+<3> The `--filter` command option sets which version of {op-system-base} is shown. In this example, since the filter is set by `"Name=name,Values=RHEL-8.8*"`, then {op-system-base} 8.8 AMIs are shown.
 <4> The `--region` command option sets where the region where an AMI is stored.
 <5> The `--output` command option sets how the results are displayed.
 --
 
 [NOTE]
 ====
-When creating a {op-system-base} compute machine for AWS, ensure that the AMI is {op-system-base} 8.4 or 8.5.
+When creating a {op-system-base} compute machine for AWS, ensure that the AMI is {op-system-base} 8.8 or a later version of RHEL 8.
 ====
 
 .Example output
@@ -49,9 +49,9 @@ When creating a {op-system-base} compute machine for AWS, ensure that the AMI is
 ------------------------------------------------------------------------------------------------------------
 |                                              DescribeImages                                              |
 +---------------------------+-----------------------------------------------------+------------------------+
-|  2021-03-18T14:23:11.000Z |  RHEL-8.4.0_HVM_BETA-20210309-x86_64-1-Hourly2-GP2  |  ami-07eeb4db5f7e5a8fb |
-|  2021-03-18T14:38:28.000Z |  RHEL-8.4.0_HVM_BETA-20210309-arm64-1-Hourly2-GP2   |  ami-069d22ec49577d4bf |
-|  2021-05-18T19:06:34.000Z |  RHEL-8.4.0_HVM-20210504-arm64-2-Hourly2-GP2        |  ami-01fc429821bf1f4b4 |
-|  2021-05-18T20:09:47.000Z |  RHEL-8.4.0_HVM-20210504-x86_64-2-Hourly2-GP2       |  ami-0b0af3577fe5e3532 |
+|  2021-03-18T14:23:11.000Z |  RHEL-8.8.0_HVM_BETA-20210309-x86_64-1-Hourly2-GP2  |  ami-07eeb4db5f7e5a8fb |
+|  2021-03-18T14:38:28.000Z |  RHEL-8.8.0_HVM_BETA-20210309-arm64-1-Hourly2-GP2   |  ami-069d22ec49577d4bf |
+|  2021-05-18T19:06:34.000Z |  RHEL-8.8.0_HVM-20210504-arm64-2-Hourly2-GP2        |  ami-01fc429821bf1f4b4 |
+|  2021-05-18T20:09:47.000Z |  RHEL-8.8.0_HVM-20210504-x86_64-2-Hourly2-GP2       |  ami-0b0af3577fe5e3532 |
 +---------------------------+-----------------------------------------------------+------------------------+
 ----
diff --git a/modules/risks-setting-higher-process-id-limits.adoc b/modules/risks-setting-higher-process-id-limits.adoc
index 2842ba96d7a4..19665a91ebf1 100644
--- a/modules/risks-setting-higher-process-id-limits.adoc
+++ b/modules/risks-setting-higher-process-id-limits.adoc
@@ -14,7 +14,15 @@ If you are running a large number of pods per node, and you have a high `podPids
 
 To find the maximum number of pods that you can run simultaneously on a single node without exceeding the PID maximum for the node, divide 3,650,000 by your `podPidsLimit` value. For example, if your `podPidsLimit` value is 16,384, and you expect the pods to use close to that number of process IDs, you can safely run 222 pods on a single node.
 
+ifdef::openshift-enterprise,openshift-origin[]
+[NOTE]
+====
+Memory, CPU, and available storage can also limit the maximum number of pods that can run simultaneously, even when the `podPidsLimit` value is set appropriately.
+====
+endif::openshift-enterprise,openshift-origin[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 Memory, CPU, and available storage can also limit the maximum number of pods that can run simultaneously, even when the `podPidsLimit` value is set appropriately. For more information, see "Planning your environment" and "Limits and scalability".
 ====
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/modules/rodoo-about.adoc b/modules/rodoo-about.adoc
index 567bd59e424a..7e39616dde12 100644
--- a/modules/rodoo-about.adoc
+++ b/modules/rodoo-about.adoc
@@ -13,3 +13,8 @@ Cluster administrators can use the {run-once-operator} to force a limit on the t
 To apply the run-once duration override from the {run-once-operator} to run-once pods, you must enable it on each applicable namespace.
 
 If both the run-once pod and the {run-once-operator} have their `activeDeadlineSeconds` value set, the lower of the two values is used.
+
+[NOTE]
+====
+You cannot install the {run-once-operator} on clusters managed by the HyperShift Operator.
+====
\ No newline at end of file
diff --git a/modules/rosa-aws-provisioned.adoc b/modules/rosa-aws-provisioned.adoc
index 6fb292fb2c75..ecc1373d8653 100644
--- a/modules/rosa-aws-provisioned.adoc
+++ b/modules/rosa-aws-provisioned.adoc
@@ -6,58 +6,96 @@
 [id="rosa-aws-policy-provisioned_{context}"]
 = Provisioned AWS Infrastructure
 
-
-This is an overview of the provisioned Amazon Web Services (AWS) components on a deployed {product-title} (ROSA) cluster. For a more detailed listing of all provisioned AWS components, see the link:https://access.redhat.com/documentation/en-us/openshift_container_platform/[OpenShift Container Platform documentation].
+This is an overview of the provisioned {AWS} components on a deployed {product-title} (ROSA) cluster.
 
 [id="rosa-ec2-instances_{context}"]
 == EC2 instances
 
-AWS EC2 instances are required for deploying the control plane and data plane functions of ROSA in the AWS public cloud.
+AWS EC2 instances are required to deploy
+ifndef::openshift-rosa-hcp[]
+the control plane and data plane functions for
+endif::openshift-rosa-hcp[]
+{product-title}.
+
+ifndef::openshift-rosa-hcp[]
+Instance types can vary for control plane and infrastructure nodes, depending on the worker node count.
+
+At a minimum, the following EC2 instances are deployed:
+
+* Three `m5.2xlarge` control plane nodes
+* Two `r5.xlarge` infrastructure nodes
+* Two `m5.xlarge` worker nodes
+endif::openshift-rosa-hcp[]
 
-Instance types can vary for control plane and infrastructure nodes, depending on the worker node count. At a minimum, the following EC2 instances will be deployed:
+ifdef::openshift-rosa-hcp[]
+At a minimum, two `m5.xlarge` EC2 instances are deployed for use as worker nodes.
+endif::openshift-rosa-hcp[]
 
-- Three `m5.2xlarge` control plane nodes
-- Two `r5.xlarge` infrastructure nodes
-- Two `m5.xlarge` customizable worker nodes
+The instance type shown for worker nodes is the default value, but you can customize the instance type for worker nodes according to the needs of your workload.
 
+ifndef::openshift-rosa-hcp[]
 For further guidance on worker node counts, see the information about initial planning considerations in the "Limits and scalability" topic listed in the "Additional resources" section of this page.
+endif::openshift-rosa-hcp[]
 
 [id="rosa-ebs-storage_{context}"]
 == Amazon Elastic Block Store storage
 
-Amazon Elastic Block Store (Amazon EBS) block storage is used for both local node storage and persistent volume storage.
+Amazon Elastic Block Store (Amazon EBS) block storage is used for both local node storage and persistent volume storage. The following values are the default size of the local, ephemeral storage provisioned for each EC2 instance.
 
 Volume requirements for each EC2 instance:
 
-- Control Plane Volume
-* Size: 350GB
-* Type: gp3
-* Input/Output Operations Per Second: 1000
+ifndef::openshift-rosa-hcp[]
 
-- Infrastructure Volume
-* Size: 300GB
-* Type: gp3
-* Input/Output Operations Per Second: 900
+* Control Plane Volume
+** Size: 350GB
+** Type: gp3
+** Input/Output Operations Per Second: 1000
 
-- Worker Volume
-* Size: 300GB
-* Type: gp3
-* Input/Output Operations Per Second: 900
+* Infrastructure Volume
+** Size: 300GB
+** Type: gp3
+** Input/Output Operations Per Second: 900
 
+endif::openshift-rosa-hcp[]
+
+* Worker Volume
+** Default size: 300GB
+ifndef::openshift-rosa-hcp[]
+** Minimum size: 128GB
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+** Minimum size: 75GB
+endif::openshift-rosa-hcp[]
+** Type: gp3
+** Input/Output Operations Per Second: 900
+
+ifndef::openshift-rosa-hcp[]
 [NOTE]
 ====
 Clusters deployed before the release of {OCP} 4.11 use gp2 type storage by default.
 ====
+endif::openshift-rosa-hcp[]
 
 [id="rosa-elastic-load-balancers_{context}"]
 == Elastic Load Balancing
+ifndef::openshift-rosa-hcp[]
+Each cluster can use up to two Classic Load Balancers for application router and up to two Network Load Balancers for API.
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+By default, one Network Load Balancer is created for use by the default ingress controller. You can create additional load balancers of the following types according to the needs of your workload:
+
+* Classic Load Balancers
+* Network Load Balancers
+* Application Load Balancers
 
-Up to two Network Load Balancers for API and up to two Classic Load Balancers for application router. For more information, see the link:https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products[ELB documentation for AWS].
+endif::openshift-rosa-hcp[]
+For more information, see the link:https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products[ELB documentation for AWS].
 
 [id="rosa-s3-storage_{context}"]
 == S3 storage
-The image registry is backed by AWS S3 storage. Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
+The image registry is backed by AWS S3 storage. Resources Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
 
+//TODO OSDOCS-11789: Confirm that this is still valid
 [NOTE]
 ====
 Two buckets are required with a typical size of 2TB each.
@@ -65,29 +103,38 @@ Two buckets are required with a typical size of 2TB each.
 
 [id="rosa-vpc_{context}"]
 == VPC
-Customers should expect to see one VPC per cluster. Additionally, the VPC will need the following configurations:
+
+Configure your VPC according to the following requirements:
 
 * *Subnets*: Two subnets for a cluster with a single availability zone, or six subnets for a cluster with multiple availability zones.
 +
+Red{nbsp}Hat strongly recommends using unique subnets for each cluster. Sharing subnets between multiple clusters is not recommended.
++
 [NOTE]
 ====
 A *public subnet* connects directly to the internet through an internet gateway. A *private subnet* connects to the internet through a network address translation (NAT) gateway.
 ====
-+ 
+
 * *Route tables*: One route table per private subnet, and one additional table per cluster.
 
 * *Internet gateways*: One Internet Gateway per cluster.
 
 * *NAT gateways*: One NAT Gateway per public subnet.
 
+//TODO OSDOCS-11789: This diagram needs to be confirmed for HCP before it is included
+ifndef::openshift-rosa-hcp[]
 .Sample VPC Architecture
 image::VPC-Diagram.png[VPC Reference Architecture]
+endif::openshift-rosa-hcp[]
 
 [id="rosa-security-groups_{context}"]
 == Security groups
 
-AWS security groups provide security at the protocol and port access level; they are associated with EC2 instances and Elastic Load Balancing (ELB) load balancers. Each security group contains a set of rules that filter traffic coming in and out of one or more EC2 instances. You must ensure the ports required for the OpenShift installation are open on your network and configured to allow access between hosts.
+AWS security groups provide security at the protocol and port access level; they are associated with EC2 instances and Elastic Load Balancing (ELB) load balancers. Each security group contains a set of rules that filter traffic coming in and out of one or more EC2 instances.
 
+Ensure that the ports required for cluster installation and operation are open on your network and configured to allow access between hosts. The requirements for the default security groups are listed in xref:required-secgroup-ports_{context}[Required ports for default security groups].
+
+[id="required-secgroup-ports_{context}"]
 .Required ports for default security groups
 [cols="2a,2a,2a,2a",options="header"]
 |===
@@ -97,7 +144,7 @@ AWS security groups provide security at the protocol and port access level; they
 |IP Protocol
 |Port range
 
-
+ifndef::openshift-rosa-hcp[]
 .4+|MasterSecurityGroup
 .4+|`AWS::EC2::SecurityGroup`
 |`icmp`
@@ -111,6 +158,7 @@ AWS security groups provide security at the protocol and port access level; they
 
 |`tcp`
 |`22623`
+endif::openshift-rosa-hcp[]
 
 .2+|WorkerSecurityGroup
 .2+|`AWS::EC2::SecurityGroup`
@@ -120,7 +168,7 @@ AWS security groups provide security at the protocol and port access level; they
 |`tcp`
 |`22`
 
-
+ifndef::openshift-rosa-hcp[]
 .2+|BootstrapSecurityGroup
 .2+|`AWS::EC2::SecurityGroup`
 
@@ -129,12 +177,19 @@ AWS security groups provide security at the protocol and port access level; they
 
 |`tcp`
 |`19531`
+endif::openshift-rosa-hcp[]
 
 |===
 
 [id="rosa-security-groups-custom_{context}"]
 === Additional custom security groups
-When you create a cluster using an existing non-managed VPC, you can add additional custom security groups during cluster creation. Custom security groups are subject to the following limitations:
+ifndef::openshift-rosa-hcp[]
+When you create a cluster using an existing non-managed VPC, you
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+You
+endif::openshift-rosa-hcp[]
+can add additional custom security groups during cluster creation. Custom security groups are subject to the following limitations:
 
 * You must create the custom security groups in AWS before you create the cluster. For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html[Amazon EC2 security groups for Linux instances].
 * You must associate the custom security groups with the VPC that the cluster will be installed into. Your custom security groups cannot be associated with another VPC.
diff --git a/modules/rosa-cluster-autoscaler-cli-after.adoc b/modules/rosa-cluster-autoscaler-cli-after.adoc
index 040021c7df82..9a0b9ff083a6 100644
--- a/modules/rosa-cluster-autoscaler-cli-after.adoc
+++ b/modules/rosa-cluster-autoscaler-cli-after.adoc
@@ -6,16 +6,18 @@
 [id="rosa-enable-cluster-autoscale-cli-after_{context}"]
 = Enable autoscaling after cluster creation with the ROSA CLI
 
+////
 [IMPORTANT]
 ====
 The following procedure is only supported for ROSA Classic clusters. To enable autoscaling after cluster creation for ROSA with HCP clusters, see link:https://docs.openshift.com/rosa/rosa_cluster_admin/rosa_nodes/rosa-nodes-about-autoscaling-nodes.html#nodes-enabling-autoscaling-nodes[Enabling autoscaling nodes on a cluster].
 ====
+////
 
 You can use the ROSA CLI (`rosa`) to set cluster-wide autoscaling after cluster creation.
 
 .Procedure
-
-- After you have created a cluster, create the autoscaler:
+ 
+* After you have created a cluster, create the autoscaler:
 +
 .Example
 [source,terminal]
@@ -23,7 +25,7 @@ You can use the ROSA CLI (`rosa`) to set cluster-wide autoscaling after cluster
 $ rosa create autoscaler --cluster=<mycluster>
 ----
 +
-.. You can also create the autoscaler with specific parameters using the following command:
+** You can also create the autoscaler with specific parameters using the following command:
 +
 .Example
 [source,terminal]
diff --git a/modules/rosa-cluster-autoscaler-cli-delete.adoc b/modules/rosa-cluster-autoscaler-cli-delete.adoc
index 1b9a3b2329c1..3c03b2e3570f 100644
--- a/modules/rosa-cluster-autoscaler-cli-delete.adoc
+++ b/modules/rosa-cluster-autoscaler-cli-delete.adoc
@@ -8,7 +8,9 @@
 
 You can delete the cluster autoscaler if you no longer want to use it.
 
-- To delete the cluster autoscaler, run the following command:
+.Procedure
+
+* To delete the cluster autoscaler, run the following command:
 +
 .Example
 [source,terminal]
diff --git a/modules/rosa-cluster-autoscaler-cli-describe.adoc b/modules/rosa-cluster-autoscaler-cli-describe.adoc
new file mode 100644
index 000000000000..20f4c997d2e1
--- /dev/null
+++ b/modules/rosa-cluster-autoscaler-cli-describe.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-autoscaling.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="rosa-cluster-autoscaler-cli-describe_{context}"]
+= View autoscaler configurations with the ROSA CLI
+
+You can view your cluster autoscaler configurations using the `rosa describe autoscaler` command.
+
+//ROSA HCP procedure
+ifdef::openshift-rosa-hcp[]
+.Procedure
+
+* To view cluster autoscaler configurations, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa describe autoscaler -h --cluster=<mycluster>
+----
+endif::openshift-rosa-hcp[]
+
+//ROSA Classic procedure
+ifdef::openshift-rosa[]
+.Procedure
+
+* To view cluster autoscaler configurations, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa describe autoscaler --cluster=<mycluster>
+----
+endif::openshift-rosa[]
\ No newline at end of file
diff --git a/modules/rosa-cluster-autoscaler-cli-edit.adoc b/modules/rosa-cluster-autoscaler-cli-edit.adoc
index cec127cdaecc..bd76f40cb4b8 100644
--- a/modules/rosa-cluster-autoscaler-cli-edit.adoc
+++ b/modules/rosa-cluster-autoscaler-cli-edit.adoc
@@ -8,7 +8,30 @@
 
 You can edit any specific parameters of the cluster autoscaler after creating the autoscaler.
 
-- To edit the cluster autoscaler, run the following command:
+.Procedure
+
+//ROSA HCP procedure
+ifdef::openshift-rosa-hcp[]
+* To edit the cluster autoscaler, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa edit autoscaler -h --cluster=<mycluster>
+----
++
+** To edit a specific parameter, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa edit autoscaler -h --cluster=<mycluster> <parameter>
+----
+endif::openshift-rosa-hcp[]
+
+//ROSA Classic procedure
+ifdef::openshift-rosa[]
+* To edit the cluster autoscaler, run the following command:
 +
 .Example
 [source,terminal]
@@ -16,10 +39,11 @@ You can edit any specific parameters of the cluster autoscaler after creating th
 $ rosa edit autoscaler --cluster=<mycluster>
 ----
 +
-.. To edit a specific parameter, run the following command:
+** To edit a specific parameter, run the following command:
 +
 .Example
 [source,terminal]
 ----
 $ rosa edit autoscaler --cluster=<mycluster> <parameter>
 ----
+endif::openshift-rosa[]
diff --git a/modules/rosa-cluster-autoscaler-cli-settings.adoc b/modules/rosa-cluster-autoscaler-cli-settings.adoc
index 114b5c7e17a5..42de5a0c0614 100644
--- a/modules/rosa-cluster-autoscaler-cli-settings.adoc
+++ b/modules/rosa-cluster-autoscaler-cli-settings.adoc
@@ -17,6 +17,8 @@ You can add the following parameters to the cluster creation command to configur
 |Type or Range
 |Example/Instruction
 
+ifdef::openshift-rosa[]
+//Classic only
 |`--autoscaler-balance-similar-node-groups`
 |Identify node groups with the same instance type and label set, and try to balance respective sizes of those node groups.
 |`boolean`
@@ -31,17 +33,22 @@ You can add the following parameters to the cluster creation command to configur
 |Autoscaler log level. Replace _int_ in the command with the number you want to use.
 |`integer`
 |`--autoscaler-log-verbosity 4`
+endif::openshift-rosa[]
 
+//Both Classic and HCP
 |`--autoscaler-max-pod-grace-period _int_`
 |Gives pods graceful termination time before scaling down, measured in seconds. Replace _int_ in the command with the number of seconds you want to use.
 |`integer`
 |`--autoscaler-max-pod-grace-period 0`
 
+//Both Classic and HCP
 |`--autoscaler-pod-priority-threshold _int_`
 |The priority that a pod must exceed to cause the cluster autoscaler to deploy additional nodes. Replace _int_ in the command with the number you want to use, can be negative.
 |`integer`
 |`--autoscaler-pod-priority-threshold -10`
 
+ifdef::openshift-rosa[]
+//Classic only
 |`--autoscaler-gpu-limit _stringArray_`
 |Minimum and maximum number of different GPUs in cluster. Cluster autoscaler does not scale the cluster less than or greater than these numbers. The format must be a comma-separated list of "<gpu_type>,<min>,<max>".
 |`array`
@@ -51,22 +58,30 @@ You can add the following parameters to the cluster creation command to configur
 |If set, the cluster-autoscaler ignores daemon set pods when calculating resource utilization for scaling down.
 |`boolean`
 |Add it to set to true, omit the option to set to false.
+endif::openshift-rosa[]
 
+//Both Classic and HCP
 |`--autoscaler-max-node-provision-time _string_`
 |Maximum time that the cluster autoscaler waits for a node to be provisioned. Replace _string_ in the command with an integer and time unit (ns,us,µs,ms,s,m,h).
 |`string`
 |`--autoscaler-max-node-provision-time 35m`
 
+ifdef::openshift-rosa[]
+//Classic only
 |`--autoscaler-balancing-ignored-labels _strings_`
 |A comma-separated list of label keys that the cluster autoscaler should ignore when comparing node groups for similarity. Replace _strings_ in the command with the relevant labels..
 |`string`
 |`--autoscaler-balancing-ignored-labels topology.ebs.csi.aws.com/zone,alpha.eksctl.io/instance-id`
+endif::openshift-rosa[]
 
+//Both Classic and HCP
 |`--autoscaler-max-nodes-total _int_`
 |Maximum amount of nodes in the cluster, including the autoscaled nodes. Replace _int_ in the command with the number you want to use.
 |`integer`
 |`--autoscaler-max-nodes-total 180`
 
+ifdef::openshift-rosa[]
+//Classic only
 |`--autoscaler-min-cores _int_`
 |Minimum number of cores to deploy in the cluster. Replace _int_ in the command with the number you want to use.
 |`integer`
@@ -116,5 +131,6 @@ You can add the following parameters to the cluster creation command to configur
 |How long after scale down failure that scale down evaluation resumes. Replace _string_ in the command with an integer and time unit (ns,us,µs,ms,s,m,h).
 |`string`
 |`--autoscaler-scale-down-delay-after-failure 1h`
+endif::openshift-rosa[]
 
 |===
diff --git a/modules/rosa-configure.adoc b/modules/rosa-configure.adoc
index fb4f33bda139..d7b43d5a1ddf 100644
--- a/modules/rosa-configure.adoc
+++ b/modules/rosa-configure.adoc
@@ -10,22 +10,116 @@ Use the following commands to configure the {product-title} (ROSA) CLI, `rosa`.
 
 [id="rosa-login_{context}"]
 == login
+There are several methods you can use to log into your Red{nbsp}Hat account using the {product-title} (ROSA) CLI (`rosa`). These methods are described in detail below.
+
+[IMPORTANT]
+====
+An offline authentication token is long-lived, stored on your operating system, and cannot be revoked. These factors increase overall security risks and the likelihood of unauthorized access to your account. Alternatively, the Red{nbsp}Hat secure browser-based single sign-on (SSO) method automatically sends your CLI instance a refresh token that is valid for 10 hours. Because this authorization code is unique and temporary, it is more secure and is the Red{nbsp}Hat recommended method of authentication.
+====
+
+// Furthermore, offline authentication tokens are usually stored on your device by your operating system, which means other apps on your machine can access a token if the token is not properly secured. These offline tokens are long-lived and cannot be revoked. Users must copy and paste them manually which creates a security risk. Because of these factors, Red{nbsp}Hat recommends using the single sign-on method when logging into your account with the ROSA CLI (`rosa`). This method is more secure than logging in with an offline token.
+// ====
 
-Log in to your Red{nbsp}Hat account, saving the credentials to the `rosa` configuration file. You must provide a token when logging in. You can copy your token from link:https://console.redhat.com/openshift/token/rosa[the ROSA token page].
 
-The ROSA CLI (`rosa`) looks for a token in the following priority order:
+[id="rosa-login-sso_{context}"]
+=== login with single sign-on (SSO) authorization code
 
-. Command-line arguments
-. The `ROSA_TOKEN` environment variable
-. The `rosa` configuration file
-. Interactively from a command-line prompt
+If your system supports a web-based browser, you can log in to the ROSA CLI (`rosa`) with a Red{nbsp}Hat single sign-on (SSO) authorization code.
+
+[NOTE]
+====
+Single sign-on authorization is supported with ROSA CLI (`rosa`) version 1.2.36 or later.
+====
 
+. To log into the ROSA CLI (`rosa`) with a Red{nbsp}Hat single sign-on authorization code, run the following command:
+
++
 .Syntax
 [source,terminal]
 ----
-$ rosa login [arguments]
+$ rosa login --use-auth-code
+----
++
+Running this command will redirect you to the Red{nbsp}Hat SSO login. Log in with your Red{nbsp}Hat login or email.
++
+.Optional arguments inherited from parent commands
+[cols="30,70"]
+|===
+|Option |Definition
+
+|--help
+|Shows help for this command.
+
+|--debug
+|Enables debug mode.
+
+|===
++
+To switch accounts, logout from link:https://sso.redhat.com[https://sso.redhat.com] and run the `rosa logout` command in your terminal before attempting to login again.
+
+[id="rosa-login-sso-device_{context}"]
+=== login with a single sign-on device code
+If you are working with containers, remote hosts, and other environments without a web browser, you can use a Red{nbsp}Hat single sign-on (SSO) device code for secure authentication. To do this, you must use a second device that has a web browser to approve the login.
+[NOTE]
+====
+Single sign-on authorization is supported with ROSA CLI (`rosa`) version 1.2.36 or later.
+====
+. To log in to ROSA CLI (`rosa`) with a Red Hat single sign-on device code, run the following command:
+
++
+.Syntax
+[source,terminal]
 ----
+$ rosa login --use-device-code
+----
++
+Running this command will redirect you to the Red Hat SSO login and provide a log in code.
++
+.Optional arguments inherited from parent commands
+[cols="30,70"]
+|===
+|Option |Definition
+
+|--help
+|Shows help for this command.
+
+|--debug
+|Enables debug mode.
+
+|===
++
+To switch accounts, logout from link:https://sso.redhat.com[https://sso.redhat.com] and run the `rosa logout` command in your terminal before attempting to login again.
+
+
+[id="rosa-login-token_{context}"]
+=== login with an offline token
 
+Log in to your Red{nbsp}Hat account, saving the credentials to the `rosa` configuration file.
+
+To use offline tokens for automation purposes, you can download the OpenShift Cluster Manager API token from the link:https://console.redhat.com/openshift/token/rosa[OpenShift Cluster Manager API Token] page.
+
+To use service accounts for automation purposes, see the link:https://console.redhat.com/iam/service-accounts[Service Accounts] page.
+
+[NOTE]
+====
+Red{nbsp}Hat recommends using service accounts for automation purposes.
+====
+
+// The ROSA CLI (`rosa`) looks for a token in the following priority order:
+
+// . Command-line arguments
+// . The `ROSA_TOKEN` environment variable
+// . The `rosa` configuration file
+// . Interactively from a command-line prompt
+
+. To log in to ROSA CLI (`rosa`) with a Red{nbsp}Hat offline token, run the following command:
++
+.Syntax
+[source,terminal]
+----
+$ rosa login [arguments]
+----
++
 .Arguments
 [cols="30,70"]
 |===
@@ -49,7 +143,7 @@ $ rosa login [arguments]
 |--token-url
 |The OpenID token URL (string). Default: `\https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token`
 |===
-
++
 .Optional arguments inherited from parent commands
 [cols="30,70"]
 |===
diff --git a/modules/rosa-create-objects.adoc b/modules/rosa-create-objects.adoc
index 27a601be76f0..07c82fbc43f6 100644
--- a/modules/rosa-create-objects.adoc
+++ b/modules/rosa-create-objects.adoc
@@ -235,6 +235,9 @@ If the argument is not supplied, an autogenerated value is created that depends
 |--etcd-encryption-kms-arn
 |Enables encryption of ETCD storage using the customer-managed key managed in AWS Key Management Service.
 
+|--external-id <arn_string>
+|An optional unique identifier that might be required when you assume a role in another account.
+
 |--host-prefix <subnet>
 |The subnet prefix length to assign to each individual node, as an integer. For example, if host prefix is set to `23`, then each node is assigned a `/23` subnet out of the given CIDR.
 
@@ -314,7 +317,7 @@ Tags that are added by Red{nbsp}Hat are required for clusters to stay in complia
 ====
 
 |--version string
-|The version of ROSA that will be used to install the cluster or cluster resources. For `cluster` use an `X.Y.Z` format, for example, `4.17.0`. For `account-role` use an `X.Y` format, for example, `4.17`.
+|The version of ROSA that will be used to install the cluster or cluster resources. For `cluster` use an `X.Y.Z` format, for example, `4.18.0`. For `account-role` use an `X.Y` format, for example, `4.18`.
 
 |--worker-iam-role string
 |The ARN of the IAM role that will be attached to compute instances.
@@ -666,14 +669,13 @@ $ rosa create ingress --cluster=mycluster --label-match=foo=bar,bar=baz
 [id="rosa-create-kubeletconfig_{context}"]
 == create kubeletconfig
 
-Create a custom `KubeletConfig` object to allow custom configuration of nodes in a machine pool. For {product-title} clusters, these settings are cluster-wide. For {hcp-title-first} clusters, each machine pool can be configured differently.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// cluster.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// machine pool.
-// endif::openshift-rosa-hcp[]
+Create a custom `KubeletConfig` object to allow custom configuration of nodes in a 
+ifdef::temp-ifdef[]
+cluster.
+endif::[]
+ifdef::temp-ifdef[]
+machine pool.
+endif::[]
 
 .Syntax
 [source,terminal]
@@ -687,27 +689,26 @@ $ rosa create kubeletconfig --cluster=<cluster_name|cluster_id> --name=<kubeletc
 |Option |Definition
 
 |--pod-pids-limit <number>
-a|Required. The maximum number of PIDs for each node in the machine pool associated with the `KubeletConfig` object.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// cluster.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// machine pool associated with the `KubeletConfig` object.
-// endif::openshift-rosa-hcp[]
+a|Required. The maximum number of PIDs for each node in the
+ifdef::temp-ifdef[]
+cluster.
+endif::[]
+ifdef::temp-ifdef[]
+machine pool associated with the `KubeletConfig` object.
+endif::[]
 
 a|-c, --cluster <cluster_name>\|<cluster_id>
 |Required. The name or ID of the cluster in which to create the `KubeletConfig` object.
 
 |--name
-a| Required for {hcp-title-first} clusters. Optional for {product-title}, as there is only one `KubeletConfig` for the cluster. Specifies a name for the `KubeletConfig` object.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// Optional.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// Required.
-// endif::openshift-rosa-hcp[]
+a|
+ifdef::temp-ifdef[]
+Optional.
+endif::[]
+ifdef::temp-ifdef[]
+Required.
+endif::[]
+Specifies a name for the `KubeletConfig` object.
 
 |-i, --interactive
 |Enable interactive mode.
@@ -755,10 +756,10 @@ For {hcp-title} clusters, the minimum disk size is 75 GiB, and the maximum is 16
 |The instance type (string) that should be used. Default: `m5.xlarge`
 
 //TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-//ifdef::openshift-rosa-hcp[]
+//ifdef::temp-ifdef[]
 a|--kubelet-configs <kubeletconfig_name>
 | For {hcp-title-first} clusters, the names of any `KubeletConfig` objects to apply to nodes in a machine pool.
-//endif::openshift-rosa-hcp[]
+//endif::[]
 
 |--labels
 |The labels (string) for the machine pool. The format must be a comma-delimited list of key=value pairs. This list overwrites any modifications made to node labels on an ongoing basis.
@@ -770,7 +771,7 @@ a|--kubelet-configs <kubeletconfig_name>
 |Specifies the minimum number of compute nodes when enabling autoscaling.
 
 //OSDOCS-11160: HCP only, but need to wait on separate HCP publishing
-//ifdef::openshift-rosa-hcp[]
+//ifdef::temp-ifdef[]
 |--max-surge
 a| For {hcp-title-first} clusters, the `max-surge` parameter defines the number of new nodes that can be provisioned in excess of the desired number of replicas for the machine pool, as configured using the `--replicas` parameter, or as determined by the autoscaler when autoscaling is enabled. This can be an absolute number (for example, `2`) or a percentage of the machine pool size (for example, `20%`), but must use the same unit as the `max-unavailable` parameter.
 
@@ -781,7 +782,7 @@ a|For {hcp-title-first} clusters, the `max-unavailable` parameter defines the nu
 
 The default value is `0`, meaning that no outdated nodes are removed before new nodes are provisioned. The valid range for this value is from `0` to the current machine pool size, or from `0%` to `100%`. The total number of nodes that can be upgraded simultaneously during an upgrade is `max-surge` plus `max-unavailable`.
 
-//endif::openshift-rosa-hcp[]
+//endif::[]
 // end OSDOCS-11160: HCP only, when separate docs are available
 
 |--name
@@ -873,7 +874,7 @@ Running this command creates resources within your AWS account.
 
 [NOTE]
 ====
-For custom or advanced configuration, it is highly recommended to use the AWS CLI directly using the `aws cloudformation` command or create a new custom template with the required configurations.
+For custom or advanced configurations, it is highly recommended to use the AWS CLI directly using the `aws cloudformation` command or create a new custom template with the required configurations. If you use a custom CloudFormation template with the ROSA CLI, the minimum required version is 1.2.47 or later.
 ====
 
 .Syntax
@@ -892,7 +893,7 @@ $ rosa create network [flags]
 
 |===
 
-.Default template YAML
+.Default CloudFormation template
 [source,yaml]
 ----
 include::https://raw.githubusercontent.com/openshift/rosa/refs/heads/master/cmd/create/network/templates/rosa-quickstart-default-vpc/cloudformation.yaml[]
diff --git a/modules/rosa-delete-objects.adoc b/modules/rosa-delete-objects.adoc
index e070bd940f0f..bc50123f832d 100644
--- a/modules/rosa-delete-objects.adoc
+++ b/modules/rosa-delete-objects.adoc
@@ -286,14 +286,14 @@ a|-c, --cluster <cluster_name>\|<cluster_id>
 |Shows help for this command.
 
 |--name
-a| Required for {hcp-title-first} clusters. Optional for {product-title}, as there is only one `KubeletConfig` for the cluster. Specifies a name for the `KubeletConfig` object.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// Optional.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// Required.
-// endif::openshift-rosa-hcp[]
+a| 
+ifdef::temp-ifdef[]
+Optional.
+endif::[]
+ifdef::temp-ifdef[]
+Required.
+endif::[]
+Specifies a name for the `KubeletConfig` object.
 
 |-y, --yes
 |Automatically answers `yes` to confirm the operation.
diff --git a/modules/rosa-deleting-account-wide-iam-roles-and-policies.adoc b/modules/rosa-deleting-account-wide-iam-roles-and-policies.adoc
index f51e21902fe6..30442bb12ca8 100644
--- a/modules/rosa-deleting-account-wide-iam-roles-and-policies.adoc
+++ b/modules/rosa-deleting-account-wide-iam-roles-and-policies.adoc
@@ -75,9 +75,9 @@ ifdef::hcp[]
 ----
 I: Fetching account roles
 ROLE NAME                                 ROLE TYPE      ROLE ARN                                                                 OPENSHIFT VERSION  AWS Managed
-ManagedOpenShift-HCP-ROSA-Installer-Role  Installer      arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role  4.17               Yes
-ManagedOpenShift-HCP-ROSA-Support-Role    Support        arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role    4.17               Yes
-ManagedOpenShift-HCP-ROSA-Worker-Role     Worker         arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role     4.17               Yes
+ManagedOpenShift-HCP-ROSA-Installer-Role  Installer      arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role  4.18               Yes
+ManagedOpenShift-HCP-ROSA-Support-Role    Support        arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role    4.18               Yes
+ManagedOpenShift-HCP-ROSA-Worker-Role     Worker         arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role     4.18               Yes
 ----
 endif::hcp[]
 .. Delete the account-wide roles:
diff --git a/modules/rosa-edit-objects.adoc b/modules/rosa-edit-objects.adoc
index 6d6f64284881..c46dae85d563 100644
--- a/modules/rosa-edit-objects.adoc
+++ b/modules/rosa-edit-objects.adoc
@@ -178,14 +178,13 @@ $ rosa edit ingress --lb-type=nlb --cluster=mycluster apps2
 [id="rosa-edit-kubeletconfig_{context}"]
 == edit kubeletconfig
 
-Edit a custom `KubeletConfig` object in a machine pool.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// cluster.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// machine pool.
-// endif::openshift-rosa-hcp[]
+Edit a custom `KubeletConfig` object in a
+ifdef::temp-ifdef[]
+cluster.
+endif::[]
+ifdef::temp-ifdef[]
+machine pool.
+endif::[]
 
 .Syntax
 [source,terminal]
@@ -205,24 +204,23 @@ a|-c, --cluster <cluster_name>\|<cluster_id>
 |Enable interactive mode.
 
 |--pod-pids-limit <number>
-a|Required. The maximum number of PIDs for each node in the machine pool associated with the `KubeletConfig` object.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// cluster.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// machine pool associated with the `KubeletConfig` object.
-// endif::openshift-rosa-hcp[]
+a|Required. The maximum number of PIDs for each node in the 
+ifdef::temp-ifdef[]
+cluster.
+endif::[]
+ifdef::temp-ifdef[]
+machine pool associated with the `KubeletConfig` object.
+endif::[]
 
 |--name
-a| Required for {hcp-title-first} clusters. Optional for {product-title}, as there is only one `KubeletConfig` for the cluster. Specifies a name for the `KubeletConfig` object.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// Optional.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// Required.
-// endif::openshift-rosa-hcp[]
+a| 
+ifdef::temp-ifdef[]
+Optional.
+endif::[]
+ifdef::temp-ifdef[]
+Required.
+endif::[]
+Specifies a name for the `KubeletConfig` object.
 
 |-h, --help
 |Shows help for this command.
@@ -256,10 +254,10 @@ $ rosa edit machinepool --cluster=<cluster_name_or_id> <machinepool_name> [argum
 |The labels (string) for the machine pool. The format must be a comma-delimited list of key=value pairs. Editing this value only affects newly created nodes of the machine pool, which are created by increasing the node number, and does not affect the existing nodes. This list overwrites any modifications made to node labels on an ongoing basis.
 
 //TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-//ifdef::openshift-rosa-hcp[]
+//ifdef::temp-ifdef[]
 a|--kubelet-configs <kubeletconfig_name>
 | For {hcp-title-first} clusters, the names of any `KubeletConfig` objects to apply to nodes in a machine pool.
-//endif::openshift-rosa-hcp[]
+//endif::[]
 
 |--max-replicas
 |Specifies the maximum number of compute nodes when enabling autoscaling.
@@ -268,7 +266,7 @@ a|--kubelet-configs <kubeletconfig_name>
 |Specifies the minimum number of compute nodes when enabling autoscaling.
 
 //OSDOCS-11160: HCP only, but need to wait on separate HCP publishing
-//ifdef::openshift-rosa-hcp[]
+//ifdef::temp-ifdef[]
 |--max-surge
 a| For {hcp-title-first} clusters, the `max-surge` parameter defines the number of new nodes that can be provisioned in excess of the desired number of replicas for the machine pool, as configured using the `--replicas` parameter, or as determined by the autoscaler when autoscaling is enabled. This can be an absolute number (for example, `2`) or a percentage of the machine pool size (for example, `20%`), but must use the same unit as the `max-unavailable` parameter.
 
@@ -278,7 +276,7 @@ The default value is `1`, meaning that the maximum number of nodes in the machin
 a|For {hcp-title-first} clusters, the `max-unavailable` parameter defines the number of nodes that can be made unavailable in a machine pool during an upgrade, before new nodes are provisioned. This can be an absolute number (for example, `2`) or a percentage of the current replica count in the machine pool (for example, `20%`), but must use the same unit as the `max-surge` parameter.
 
 The default value is `0`, meaning that no outdated nodes are removed before new nodes are provisioned. The valid range for this value is from `0` to the current machine pool size, or from `0%` to `100%`. The total number of nodes that can be upgraded simultaneously during an upgrade is `max-surge` plus `max-unavailable`.
-//endif::openshift-rosa-hcp[]
+//endif::[]
 // end OSDOCS-11160: HCP only, when separate docs are available
 
 |--node-drain-grace-period
diff --git a/modules/rosa-getting-started-install-configure-cli-tools.adoc b/modules/rosa-getting-started-install-configure-cli-tools.adoc
index 3324e3b8514c..3a6f6f210a59 100644
--- a/modules/rosa-getting-started-install-configure-cli-tools.adoc
+++ b/modules/rosa-getting-started-install-configure-cli-tools.adoc
@@ -7,40 +7,23 @@
 [id="rosa-getting-started-install-configure-cli-tools_{context}"]
 = Installing and configuring the required CLI tools
 
-ifeval::["{context}" == "rosa-getting-started"]
-:getting-started:
-endif::[]
-ifeval::["{context}" == "rosa-quickstart"]
-:quickstart:
-endif::[]
+Several command line interface (CLI) tools are required to deploy and work with your cluster.
 
-Use the following steps to install and configure
-ifdef::quickstart[]
-the AWS and {product-title} (ROSA) CLI tools
-endif::[]
-ifdef::getting-started[]
-AWS, {product-title} (ROSA), and OpenShift CLI tools
-endif::[]
-on your workstation.
-
-ifdef::getting-started[]
 .Prerequisites
 
 * You have an AWS account.
-* You created a Red{nbsp}Hat account.
-+
-[NOTE]
-====
-You can create a Red{nbsp}Hat account by navigating to link:https://console.redhat.com[console.redhat.com] and selecting *Register for a Red{nbsp}Hat account*.
-====
-endif::[]
+* You have a Red{nbsp}Hat account.
 
 .Procedure
 
+. Log in to your Red{nbsp}Hat and AWS accounts to access the download page for each required tool.
+.. Log in to your Red{nbsp}Hat account at link:https://console.redhat.com[console.redhat.com].
+.. Log in to your AWS account at link:https://aws.amazon.com[aws.amazon.com].
+
+//This should be a separate module
 . Install and configure the latest AWS CLI (`aws`).
-.. Follow the link:https://aws.amazon.com/cli/[AWS Command Line Interface] documentation to install and configure the AWS CLI for your operating system.
-+
-Specify your `aws_access_key_id`, `aws_secret_access_key`, and `region` in the `.aws/credentials` file. See link:https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html[AWS Configuration basics] in the AWS documentation.
+.. Install the AWS CLI by following the link:https://aws.amazon.com/cli/[AWS Command Line Interface] documentation appropriate for your workstation.
+.. Configure the AWS CLI by specifying your `aws_access_key_id`, `aws_secret_access_key`, and `region` in the `.aws/credentials` file. For more information, see link:https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html[AWS Configuration basics] in the AWS documentation.
 +
 [NOTE]
 ====
@@ -59,21 +42,25 @@ $ aws sts get-caller-identity  --output text
 <aws_account_id>    arn:aws:iam::<aws_account_id>:user/<username>  <aws_user_id>
 ----
 
+//This should be a separate module
 . Install and configure the latest ROSA CLI (`rosa`).
-.. Download the latest version of the ROSA CLI for your operating system from the link:https://console.redhat.com/openshift/downloads[*Downloads*] page on the {cluster-manager-first} {hybrid-console-second}.
+.. Navigate to link:https://console.redhat.com/openshift/downloads[*Downloads*].
+.. Find *Red Hat OpenShift Service on AWS command line interface (`rosa)* in the list of tools and click *Download*.
++
+The `rosa-linux.tar.gz` file is downloaded to your default download location.
 .. Extract the `rosa` binary file from the downloaded archive. The following example extracts the binary from a Linux tar archive:
 +
 [source,terminal]
 ----
 $ tar xvf rosa-linux.tar.gz
 ----
-.. Add `rosa` to your path. In the following example, the `/usr/local/bin` directory is included in the path of the user:
+.. Move the `rosa` binary file to a directory in your execution path. In the following example, the `/usr/local/bin` directory is included in the path of the user:
 +
 [source,terminal]
 ----
 $ sudo mv rosa /usr/local/bin/rosa
 ----
-.. Verify if the ROSA CLI is installed correctly by querying the `rosa` version:
+.. Verify that the ROSA CLI is installed correctly by querying the `rosa` version:
 +
 [source,terminal]
 ----
@@ -83,28 +70,32 @@ $ rosa version
 .Example output
 [source,terminal]
 ----
-1.2.15
+1.2.47
 Your ROSA CLI is up to date.
 ----
-ifdef::getting-started[]
-+
-.. Optional: Enable tab completion for the ROSA CLI. With tab completion enabled, you can press the `Tab` key twice to automatically complete subcommands and receive command suggestions.
-+
-`rosa` tab completion is available for different shell types. The following example enables persistent tab completion for Bash on a Linux host. The command generates a `rosa` tab completion configuration file for Bash and saves it to the `/etc/bash_completion.d/` directory:
-+
-[source,terminal]
-----
-# rosa completion bash > /etc/bash_completion.d/rosa
-----
-+
-You must open a new terminal to activate the configuration.
-+
-[NOTE]
-====
-For steps to configure `rosa` tab completion for different shell types, see the help menu by running `rosa completion --help`.
-====
-endif::[]
-.. Log in to your Red{nbsp}Hat account by using the ROSA CLI:
+// OSDOCS-11789: PM recommended removing this step since it isn't required.
+// ifdef::getting-started[]
+// +
+// .. Optional: Enable tab completion for the ROSA CLI. With tab completion enabled, you can press the `Tab` key twice to automatically complete subcommands and receive command suggestions.
+// +
+// `rosa` tab completion is available for different shell types. The following example enables persistent tab completion for Bash on a Linux host. The command generates a `rosa` tab completion configuration file for Bash and saves it to the `/etc/bash_completion.d/` directory:
+// +
+// [source,terminal]
+// ----
+// # rosa completion bash > /etc/bash_completion.d/rosa
+// ----
+// +
+// You must open a new terminal to activate the configuration.
+// +
+// [NOTE]
+// ====
+// For steps to configure `rosa` tab completion for different shell types, see the help menu by running `rosa completion --help`.
+// ====
+// endif::[]
+
+//The following should probably also be a separate module
+. Log in to the ROSA CLI using an offline access token.
+.. Run the login command:
 +
 [source,terminal]
 ----
@@ -117,14 +108,21 @@ $ rosa login
 To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
 ? Copy the token and paste it here:
 ----
+.. Navigate to the URL listed in the command output to view your offline access token.
+.. Enter the offline access token at the command line prompt to log in.
 +
-Go to the URL listed in the command output to obtain an offline access token. Specify the token at the CLI prompt to log in.
+[source,terminal]
+----
+? Copy the token and paste it here: *******************
+[full token length omitted]
+----
 +
 [NOTE]
 ====
-You can subsequently specify the offline access token by using the `--token="<offline_access_token>"` argument when you run the `rosa login` command.
+In the future you can specify the offline access token by using the `--token="<offline_access_token>"` argument when you run the `rosa login` command.
 ====
-.. Verify if you are logged in successfully and check your credentials:
+
+.. Verify that you are logged in and confirm that your credentials are correct before proceeding:
 +
 [source,terminal]
 ----
@@ -146,12 +144,12 @@ OCM Organization ID:          <org_id>
 OCM Organization Name:        Your organization
 OCM Organization External ID: <external_org_id>
 ----
-+
-Check that the information in the output is correct before proceeding.
 
-ifdef::getting-started[]
+//This should be a separate module
 . Install and configure the latest OpenShift CLI (`oc`).
-.. Use the ROSA CLI to download the latest version of the `oc` CLI:
+.. Use the ROSA CLI to download the `oc` CLI.
++
+The following command downloads the latest version of the CLI to the current working directory:
 +
 [source,terminal]
 ----
@@ -163,13 +161,13 @@ $ rosa download openshift-client
 ----
 $ tar xvf openshift-client-linux.tar.gz
 ----
-.. Add the `oc` binary to your path. In the following example, the `/usr/local/bin` directory is included in the path of the user:
+.. Move the `oc` binary to a directory in your execution path. In the following example, the `/usr/local/bin` directory is included in the path of the user:
 +
 [source,terminal]
 ----
 $ sudo mv oc /usr/local/bin/oc
 ----
-.. Verify if the `oc` CLI is installed correctly:
+.. Verify that the `oc` CLI is installed correctly:
 +
 [source,terminal]
 ----
@@ -180,14 +178,5 @@ $ rosa verify openshift-client
 [source,terminal]
 ----
 I: Verifying whether OpenShift command-line tool is available...
-I: Current OpenShift Client Version: 4.9.12
-----
-endif::[]
-
-
-ifeval::["{context}" == "rosa-getting-started"]
-:getting-started:
-endif::[]
-ifeval::["{context}" == "rosa-quickstart"]
-:quickstart:
-endif::[]
\ No newline at end of file
+I: Current OpenShift Client Version: 4.17.3
+----
\ No newline at end of file
diff --git a/_unused_topics/rosa-hcp-aws-private-security-groups.adoc b/modules/rosa-hcp-aws-private-security-groups.adoc
similarity index 56%
rename from _unused_topics/rosa-hcp-aws-private-security-groups.adoc
rename to modules/rosa-hcp-aws-private-security-groups.adoc
index 1183b3bf9f5f..10a23586b294 100644
--- a/_unused_topics/rosa-hcp-aws-private-security-groups.adoc
+++ b/modules/rosa-hcp-aws-private-security-groups.adoc
@@ -1,11 +1,17 @@
 // Module included in the following assemblies:
 //
+// * rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc
 
 [id="rosa-hcp-aws-private-security-groups_{context}"]
 :_mod-docs-content-type: PROCEDURE
-= Configuring AWS security groups to access the API
+= Adding additional AWS security groups to the AWS PrivateLink endpoint
 
-With {hcp-title} private clusters, the AWS PrivateLink endpoint exposed in the customer's VPC has a default security group. This security group has access to the PrivateLink endpoint that is limited to only those resources that exist within the VPC or resources that are present with an IP address associated with the VPC CIDR range. In order to grant access to any entities outside of the VPC, through VPC peering and transit gateway, you must create and attach another security group to the PrivateLink endpoint to grant the necessary access.
+With {hcp-title} clusters, the AWS PrivateLink endpoint exposed in the customer's VPC has a security group that limits access to requests that originate from within the cluster's Machine CIDR range. In order to grant access to the cluster's API to any entities outside of the VPC, through VPC peering, transit gateways, or other network connectivity, you must create and attach another security group to the PrivateLink endpoint to grant the necessary access.
+
+[IMPORTANT]
+====
+Adding additional AWS security groups to the AWS PrivateLink endpoint is only supported on {hcp-title} version 4.17.2 and later. 
+====
 
 .Prerequisites
 
@@ -41,20 +47,26 @@ hcp-private
 ----
 $ read -r VPCE_ID VPC_ID <<< $(aws ec2 describe-vpc-endpoints --filters "Name=tag:api.openshift.com/id,Values=$(rosa describe cluster -c ${CLUSTER_NAME} -o yaml | grep '^id: ' | cut -d' ' -f2)" --query 'VpcEndpoints[].[VpcEndpointId,VpcId]' --output text)
 ----
-
-. Create your security group by running the following command:
++
+[WARNING]
+====
+Modifying or removing the default AWS PrivateLink endpoint security group is not supported and might result in unexpected behavior.
+====
++
+. Create an additional security group by running the following command:
 +
 [source,terminal]
 ----
 $ export SG_ID=$(aws ec2 create-security-group --description "Granting API access to ${CLUSTER_NAME} from outside of VPC" --group-name "${CLUSTER_NAME}-api-sg" --vpc-id $VPC_ID --output text)
 ----
 
-. Add an ingress rule to the security group by running the following command:
+. Add an inbound (ingress) rule to the security group by running the following command:
 +
 [source,terminal]
 ----
-$ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions FromPort=443,ToPort=443,IpProtocol=tcp,IpRanges=[{CidrIp=0.0.0.0/0}]
+$ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions FromPort=443,ToPort=443,IpProtocol=tcp,IpRanges=[{CidrIp=<cidr-to-allow>}] <.> 
 ----
+<.> Specify the CIDR block you want to allow access from.
 
 . Add the new security group to the VPCE by running the following command:
 +
@@ -63,4 +75,4 @@ $ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions Fr
 $ aws ec2 modify-vpc-endpoint --vpc-endpoint-id $VPCE_ID --add-security-group-ids $SG_ID
 ----
 
-You now can access the API with your {hcp-title} private cluster.
+You now can access the API of your {hcp-title} private cluster from the specified CIDR block.
diff --git a/modules/rosa-hcp-creating-account-wide-sts-roles-and-policies.adoc b/modules/rosa-hcp-creating-account-wide-sts-roles-and-policies.adoc
index a07fd86fe24d..f6dd002f74b5 100644
--- a/modules/rosa-hcp-creating-account-wide-sts-roles-and-policies.adoc
+++ b/modules/rosa-hcp-creating-account-wide-sts-roles-and-policies.adoc
@@ -1,3 +1,5 @@
+// Module included in the following assemblies:
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 // * rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc
 
 
diff --git a/modules/rosa-hcp-deleting-cluster.adoc b/modules/rosa-hcp-deleting-cluster.adoc
index a703405accb2..f1908b1c4383 100644
--- a/modules/rosa-hcp-deleting-cluster.adoc
+++ b/modules/rosa-hcp-deleting-cluster.adoc
@@ -40,7 +40,7 @@ Display Name:               test_cluster
 ID:                         <cluster_id> <1>
 External ID:                <external_id>
 Control Plane:              ROSA Service Hosted
-OpenShift Version:          4.17.0
+OpenShift Version:          4.18.0
 Channel Group:              stable
 DNS:                        test_cluster.l3cn.p3.openshiftapps.com
 AWS Account:                <AWS_id>
diff --git a/modules/rosa-hcp-firewall-prerequisites.adoc b/modules/rosa-hcp-firewall-prerequisites.adoc
index 87a97806bec3..4a5268c6cfdb 100644
--- a/modules/rosa-hcp-firewall-prerequisites.adoc
+++ b/modules/rosa-hcp-firewall-prerequisites.adoc
@@ -1,34 +1,19 @@
 // Module included in the following assemblies:
 //
 // * rosa_planning/rosa-sts-aws-prereqs.adoc
-// * rosa_planning/rosa-hcp-prereqs.adoc
+// * rosa_planning/rosa-hcp-prereqs.adoc <-- this is a symlink
 
-ifeval::["{context}" == "rosa-sts-aws-prereqs"]
-:rosa-classic-sts:
-endif::[]
-ifeval::["{context}" == "rosa-hcp-aws-prereqs"]
-:hcp:
-endif::[]
+//TODO OSDOCS-11789: Why is this a procedure and not a reference?
 
 [id="rosa-hcp-firewall-prerequisites_{context}"]
-// Conditionals are to change the title when displayed on the rosa-sts-aws-prereqs page
-ifdef::rosa-classic-sts[]
-= {hcp-title}
-endif::rosa-classic-sts[]
-ifndef::rosa-classic-sts[]
-= AWS firewall prerequisites
+= Firewall prerequisites for {hcp-title}
 
-If you are using a firewall to control egress traffic from {product-title}, you must configure your firewall to grant access to the certain domain and port combinations below. {product-title} requires this access to provide a fully managed OpenShift service.
-endif::rosa-classic-sts[]
+* If you are using a firewall to control egress traffic from {hcp-title-first}, your Virtual Private Cloud (VPC) must be able to complete requests from the cluster to the Amazon S3 service, for example, via an Amazon S3 gateway.
 
-.Prerequisites
+* You must also configure your firewall to grant access to the following domain and port combinations.
+//TODO OSDOCS-11789: From your deploy machine? From your cluster?
 
-* You have configured an Amazon S3 gateway endpoint in your AWS Virtual Private Cloud (VPC). This endpoint is required to complete requests from the cluster to the Amazon S3 service. 
-
-.Procedure
-
-. Allowlist the following URLs that are used to download and install packages and tools:
-+
+== Domains for installation packages and tools
 [cols="6,1,6",options="header"]
 |===
 |Domain | Port | Function
@@ -48,6 +33,18 @@ endif::rosa-classic-sts[]
 |443
 |Provides core container images.
 
+|`cdn04.quay.io`
+|443
+|Provides core container images.
+
+|`cdn05.quay.io`
+|443
+|Provides core container images.
+
+|`cdn06.quay.io`
+|443
+|Provides core container images.
+
 |`quayio-production-s3.s3.amazonaws.com`
 |443
 |Provides core container images.
@@ -72,9 +69,8 @@ endif::rosa-classic-sts[]
 |443
 |Required. Used to access mirrored installation content and images. This site is also a source of release image signatures, although the Cluster Version Operator (CVO) needs only a single functioning source.
 |===
-+
-. Allowlist the following telemetry URLs:
-+
+
+== Domains for telemetry
 [cols="6,1,6",options="header"]
 |===
 |Domain | Port | Function
@@ -90,12 +86,11 @@ endif::rosa-classic-sts[]
 |443
 |Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.redhat.com` to download the pull secret and use Red{nbsp}Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, etc.
 |===
-+
+
 Managed clusters require enabling telemetry to allow Red{nbsp}Hat to react more quickly to problems, better support the customers, and better understand how product upgrades impact clusters.
-For more information about how remote health monitoring data is used by Red{nbsp}Hat, see _About remote health monitoring_ in the _Additional resources_ section.
+For more information about how remote health monitoring data is used by Red{nbsp}Hat, see _About remote health monitoring_.
 
-. Allowlist the following Amazon Web Services (AWS) API URls:
-+
+== Domains for Amazon Web Services (AWS) APIs
 [cols="6,1,6",options="header"]
 |===
 |Domain | Port | Function
@@ -103,21 +98,21 @@ For more information about how remote health monitoring data is used by Red{nbsp
 |`sts.<aws_region>.amazonaws.com` ^[1]^
 |443
 |Required. Used to access the AWS Secure Token Service (STS) regional endpoint. Ensure that you replace `<aws-region>` with the region that your cluster is deployed in.
-
-|`sts.amazonaws.com` ^[2]^
-|443
-|See footnote. Used to access the AWS Secure Token Service (STS) global endpoint.
 |===
-+
+
 [.small]
 --
 1. This can also be accomplished by configuring a private interface endpoint in your AWS Virtual Private Cloud (VPC) to the regional AWS STS endpoint.
-2. The AWS STS global endpoint is only required to be allowed if you are running a version of OpenShift before 4.14.18 or 4.15.4. ROSA HCP version 4.14.18+, 4.15.4+, and 4.16.0+ use the AWS STS regional endpoint.
 --
-+
+ 
+== Domains for your workload
+
+Your workload may require access to other sites that provide resources for programming languages or frameworks.
+
+* Allow access to sites that provide resources required by your builds.
+* Allow access to outbound URLs required for your workload, for example, link:https://access.redhat.com/solutions/2998411[OpenShift Outbound URLs to Allow].
 
-. Allowlist the following URLs for optional third-party content:
-+
+== Optional domains to enable third-party content
 [cols="6,1,6",options="header"]
 |===
 |Domain | Port | Function
@@ -133,13 +128,3 @@ For more information about how remote health monitoring data is used by Red{nbsp
 | 443
 | Optional. Required for Sonatype Nexus, F5 Big IP operators.
 |===
-
-. Allowlist any site that provides resources for a language or framework that your builds require.
-. Allowlist any outbound URLs that depend on the languages and frameworks used in OpenShift. See link:https://access.redhat.com/solutions/2998411[OpenShift Outbound URLs to Allow] for a list of recommended URLs to be allowed on the firewall or proxy.
-
-ifeval::["{context}" == "rosa-sts-aws-prereqs"]
-:!rosa-classic-sts:
-endif::[]
-ifeval::["{context}" == "rosa-hcp-aws-prereqs"]
-:!hcp:
-endif::[]
diff --git a/modules/rosa-hcp-no-console-access.adoc b/modules/rosa-hcp-no-console-access.adoc
new file mode 100644
index 000000000000..56fd169d8cea
--- /dev/null
+++ b/modules/rosa-hcp-no-console-access.adoc
@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * support/rosa-troubleshooting-installations-hcp .adoc
+:_mod-docs-content-type: PROCEDURE
+[id="rosa-hcp-no-console-access_{context}"]
+= Troubleshooting access to {hybrid-console}
+
+In {hcp-title} clusters, the {product-title} OAuth server is hosted in the Red Hat service's AWS account while the web console service is published using the cluster's default ingress controller in the cluster's AWS account. If you can log in to your cluster using the OpenShift CLI (oc) but cannot access the {product-title} web console, verify the following criteria are met:
+
+* The console workloads are running.
+* The default ingress controller's load balancer is active.
+* You are accessing the console from a machine that has network connectivity to the cluster's VPC network.
+
diff --git a/modules/rosa-hcp-private-ready-no-console-access.adoc b/modules/rosa-hcp-private-ready-no-console-access.adoc
new file mode 100644
index 000000000000..ea68871978f5
--- /dev/null
+++ b/modules/rosa-hcp-private-ready-no-console-access.adoc
@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * support/rosa-troubleshooting-installations-hcp .adoc
+:_mod-docs-content-type: PROCEDURE
+[id="rosa-hcp-private-ready-no-console-access_{context}"]
+= Verifying access to {hybrid-console} for private {hcp-title} clusters
+
+The console of the private cluster is private by default. During cluster installation, the default Ingress Controller managed by OpenShift's Ingress Operator is configured with an internal AWS Network Load Balancer (NLB).
+
+If your private {hcp-title} cluster shows a `ready` status but you cannot access the {product-title} web console for the cluster, try accessing the cluster console from either within the cluster VPC or from a network that is connected to the VPC.
+
+
diff --git a/modules/rosa-hcp-ready-no-console-access.adoc b/modules/rosa-hcp-ready-no-console-access.adoc
new file mode 100644
index 000000000000..c7a3b2dfff64
--- /dev/null
+++ b/modules/rosa-hcp-ready-no-console-access.adoc
@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * support/rosa-troubleshooting-installations-hcp .adoc
+:_mod-docs-content-type: PROCEDURE
+[id="rosa-hcp-ready-no-console-access_{context}"]
+= Verifying access to {product-title} web console for {hcp-title} cluster in ready state
+
+{hcp-title} clusters return a `ready` status when the control plane hosted in the {product-title} service account becomes ready. Cluster console workloads are deployed on the cluster's worker nodes. The {product-title} web console will not be available and accessible until the worker nodes have joined the cluster and console workloads are running.
+
+If your {hcp-title} cluster is ready but you are unable to access the {product-title} web console for the cluster, wait for the worker nodes to join the cluster and retry accessing the console.
+
+You can either log in to the {hcp-title} cluster or use the `rosa describe machinepool` command in the `rosa` CLI watch the nodes.
diff --git a/modules/rosa-hcp-sts-creating-a-cluster-cli.adoc b/modules/rosa-hcp-sts-creating-a-cluster-cli.adoc
index 190fddc238d1..66663f37bd0f 100644
--- a/modules/rosa-hcp-sts-creating-a-cluster-cli.adoc
+++ b/modules/rosa-hcp-sts-creating-a-cluster-cli.adoc
@@ -39,12 +39,15 @@ When creating a {hcp-title} cluster, the default machine Classless Inter-Domain
 +
 [source,terminal]
 ----
-$ rosa create cluster --cluster-name=<cluster_name> \ <.>
-    --mode=auto --hosted-cp [--private] \ <.> 
-    --operator-roles-prefix <operator-role-prefix> \ <.>
+$ rosa create cluster --cluster-name=<cluster_name> \ <1>
+    --mode=auto --hosted-cp [--private] \ <2> 
+    --operator-roles-prefix <operator-role-prefix> \ <3>
+    --external-id <external-id> \ <4>
     --oidc-config-id <id-of-oidc-configuration> \ 
     --subnet-ids=<public-subnet-id>,<private-subnet-id>
 ----
++
+--
 <.> Specify the name of your cluster. If your cluster name is longer than 15 characters, it will contain an autogenerated domain prefix as a subdomain for your provisioned cluster on openshiftapps.com. To customize the subdomain, use the `--domain-prefix` flag. The domain prefix cannot be longer than 15 characters, must be unique, and cannot be changed after cluster creation.
 <.> Optional: The `--private` argument is used to create private {hcp-title} clusters. If you use this argument, ensure that you only use your private subnet ID for `--subnet-ids`.
 <.> By default, the cluster-specific Operator role names are prefixed with the cluster name and a random 4-digit hash. You can optionally specify a custom prefix to replace `<cluster_name>-<hash>` in the role names. The prefix is applied when you create the cluster-specific Operator IAM roles. For information about the prefix, see _About custom Operator IAM role prefixes_.
@@ -53,7 +56,9 @@ $ rosa create cluster --cluster-name=<cluster_name> \ <.>
 ====
 If you specified custom ARN paths when you created the associated account-wide roles, the custom path is automatically detected. The custom path is applied to the cluster-specific Operator roles when you create them in a later step.
 ====
-+
+<.> Optional: A unique identifier that might be required when you assume a role in another account.
+--
+
 * If you set the environmental variables, create a cluster with a single, initial machine pool, using either a publicly or privately available API, and a publicly or privately available Ingress by running the following command:
 +
 [source,terminal]
diff --git a/modules/rosa-hcp-sts-creating-a-cluster-external-auth-cluster-cli.adoc b/modules/rosa-hcp-sts-creating-a-cluster-external-auth-cluster-cli.adoc
index 8fa3f5706a46..e8935e5e511f 100644
--- a/modules/rosa-hcp-sts-creating-a-cluster-external-auth-cluster-cli.adoc
+++ b/modules/rosa-hcp-sts-creating-a-cluster-external-auth-cluster-cli.adoc
@@ -56,7 +56,7 @@ Display Name:               rosa-ext-test
 ID:                         <cluster_id>
 External ID:                <cluster_ext_id>
 Control Plane:              ROSA Service Hosted
-OpenShift Version:          4.17.0
+OpenShift Version:          4.18.0
 Channel Group:              stable
 DNS:                        <dns>
 AWS Account:                <AWS_id>
diff --git a/modules/rosa-hcp-vpc-manual.adoc b/modules/rosa-hcp-vpc-manual.adoc
index 65ef6d1681bf..1ef7872d0960 100644
--- a/modules/rosa-hcp-vpc-manual.adoc
+++ b/modules/rosa-hcp-vpc-manual.adoc
@@ -6,28 +6,6 @@
 [id="rosa-hcp-vpc-manual_{context}"]
 = Creating a Virtual Private Cloud manually
 
-If you choose to manually create your Virtual Private Cloud (VPC) instead of using Terraform, go to link:https://us-east-1.console.aws.amazon.com/vpc/[the VPC page in the AWS console]. Your VPC must meet the requirements shown in the following table.
+If you choose to manually create your Virtual Private Cloud (VPC) instead of using Terraform, go to link:https://us-east-1.console.aws.amazon.com/vpc/[the VPC page in the AWS console].
 
-.Requirements for your VPC
-[options="header",cols="50,50"]
-|===
-| Requirement | Details
-
-| VPC name
-| You need to have the specific VPC name and ID when creating your cluster.
-
-| CIDR range
-| Your VPC CIDR range should match your machine CIDR.
-
-| Availability zone
-| You need one availability zone for a single zone, and you need three for availability zones for multi-zone.
-
-| Public subnet
-| You must have one public subnet with an internet gateway for public clusters.
-
-| Private subnet
-| You must have exactly one private subnet in each availability zone (AZ) for installing machine pools in ROSA HCP clusters. A NAT gateway may be associated with this subnet to allow outbound internet access for the instances. Private clusters do not need a public subnet.
-
-| DNS hostname and resolution
-| You must ensure that the DNS hostname and resolution are enabled.
-|===
+include::snippets/rosa-existing-vpc-requirements.adoc[leveloffset=+0]
diff --git a/modules/rosa-hcp-vpc-terraform.adoc b/modules/rosa-hcp-vpc-terraform.adoc
index 4c34b10fd6fc..3c766d831a3c 100644
--- a/modules/rosa-hcp-vpc-terraform.adoc
+++ b/modules/rosa-hcp-vpc-terraform.adoc
@@ -64,6 +64,12 @@ $ terraform plan -out rosa-zero-egress.tfplan -var region=<aws_region> \ <1>
 +
 --
 <1> Enter your AWS region.
++
+[IMPORTANT]
+====
+You can only use egress lockdown on clusters that use the `us-west-1, us-west-2, us-east-1, us-east-2, ap-northeast-1, ap-northeast-2, ap-northeast-3, ap-south-1, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-north-1, eu-west-1, eu-west-2, eu-west-3`, and `sa-east-1` AWS regions.
+====
+
 <2> Enter the availability zones for the VPC. For example, for a VPC that uses `ap-southeast-1`, you would use the following as availability zones: `["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]`.
 <3> Enter the CIDR block for your VPC.
 <4> Enter each of the subnets that are created for the VPC.
diff --git a/modules/rosa-how-upgrades-work.adoc b/modules/rosa-how-upgrades-work.adoc
index 94a3808442ad..1d1330d58fc9 100644
--- a/modules/rosa-how-upgrades-work.adoc
+++ b/modules/rosa-how-upgrades-work.adoc
@@ -37,7 +37,7 @@ The following are the high-level steps that occur during the ROSA (classic archi
 ** Identifying any Pod Disruption Budgets (PDBs) that can potentially block or delay the update of the nodes.
 ** Ensuring cluster Operators are available and healthy.
 ** Ensuring cluster critical alerts are not firing.
-. A temporary compute node is created in the cluster to allow for the scheduling of drained pods during the update.
+. A temporary compute node is created in each availability zone (AZ) in the cluster to allow for the scheduling of drained pods during the update.
 +
 [NOTE]
 ====
diff --git a/modules/rosa-list-objects.adoc b/modules/rosa-list-objects.adoc
index cb8888710d64..810be5a7bacd 100644
--- a/modules/rosa-list-objects.adoc
+++ b/modules/rosa-list-objects.adoc
@@ -681,6 +681,9 @@ $ rosa describe cluster --cluster=<cluster_name> | <cluster_id> [arguments]
 |--debug
 |Enables debug mode.
 
+|--external-id <arn_string>
+|An optional unique identifier that might be required when you assume a role in another account.
+
 |--profile
 |Specifies an AWS profile (string) from your credentials file.
 
@@ -719,14 +722,14 @@ a|-c, --cluster <cluster_name>\|<cluster_id>
 |Shows help for this command.
 
 |--name
-a| Optional. Specifies the name of the `KubeletConfig` object to describe.
-//TODO OSDOCS-10439: Add conditions back when HCP and Classic are published separately
-// ifdef::openshift-rosa-classic[]
-// Optional.
-// endif::openshift-rosa-classic[]
-// ifdef::openshift-rosa-hcp[]
-// Required.
-// endif::openshift-rosa-hcp[]
+a| 
+ifdef::openshift-rosa[]
+Optional.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+Required.
+endif::openshift-rosa-hcp[]
+Specifies the name of the `KubeletConfig` object to describe.
 
 |-o, --output string
 
diff --git a/modules/rosa-oidc-understanding.adoc b/modules/rosa-oidc-understanding.adoc
index 3b4d26285ccd..72e2a1a80ab1 100644
--- a/modules/rosa-oidc-understanding.adoc
+++ b/modules/rosa-oidc-understanding.adoc
@@ -7,11 +7,13 @@
 [id=rosa-oidc-understanding_{context}]
 = Understanding the OIDC verification options
 
-There are three options for OIDC verification:
+You can configure the following types of OIDC verification:
 
+ifndef::openshift-rosa-hcp[]
 * Unregistered, managed OIDC configuration
 +
 An unregistered, managed OIDC configuration is created for you during the cluster installation process. The configuration is hosted under Red{nbsp}Hat's AWS account. This option does not give you the ID that links to the OIDC configuration, so you can only use this type of OIDC configuration on a single cluster.
+endif::openshift-rosa-hcp[]
 
 * Registered, managed OIDC configuration
 +
@@ -23,9 +25,11 @@ You can create a registered, unmanaged OIDC configuration before you start creat
 
 The registered options can be used to create the required IAM resources before you start creating a cluster. This option results in faster install times since there is a waiting period during cluster creation where the installation pauses until you create an OIDC provider and Operator roles.
 
+ifndef::openshift-rosa-hcp[]
 For ROSA Classic, you may use any of the OIDC configuration options. If you are using {hcp-title}, you must create registered OIDC configuration, either as managed or unmanaged. You can share the registered OIDC configurations with other clusters. This ability to share the configuration also allows you to share the provider and Operator roles.
+endif::openshift-rosa-hcp[]
 
 [NOTE]
 ====
-Reusing the OIDC configurations, OIDC provider, and Operator roles between clusters is not recommended for production clusters since the authentication verification is used throughout all of these clusters. Red{nbsp}Hat advises to only reuse resources on non-production test environments.
+Reusing the OIDC configurations, OIDC provider, and Operator roles between clusters is not recommended for production clusters since the authentication verification is used throughout all of these clusters. Red{nbsp}Hat recommends only reusing resources between non-production test environments.
 ====
\ No newline at end of file
diff --git a/modules/rosa-planning-environment-cluster-max.adoc b/modules/rosa-planning-environment-cluster-max.adoc
index 88945a2a1ab1..ed60b0b25a6e 100644
--- a/modules/rosa-planning-environment-cluster-max.adoc
+++ b/modules/rosa-planning-environment-cluster-max.adoc
@@ -7,7 +7,7 @@
 
 This document describes how to plan your {product-title} environment based on the tested cluster maximums.
 
-Oversubscribing the physical resources on a node affects resource guarantees the Kubernetes scheduler makes during pod placement. Learn what measures you can take to avoid memory swapping.
+Oversubscribing the physical resources on a node affects the resource guarantees that the Kubernetes scheduler makes during pod placement. Learn what measures you can take to avoid memory swapping.
 
 Some of the tested maximums are stretched only in a single dimension. They will vary when many objects are running on the cluster.
 
diff --git a/modules/rosa-policy-change-management.adoc b/modules/rosa-policy-change-management.adoc
index c6b0898f345a..1fccae595cb1 100644
--- a/modules/rosa-policy-change-management.adoc
+++ b/modules/rosa-policy-change-management.adoc
@@ -126,7 +126,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
 - Set up and configure Amazon VPC components required to provision the cluster, such as subnets, load balancers, internet gateways, and NAT gateways.
 
 - Provide the ability for the customer to
-manage AWS VPN connectivity with on-premises resources, Amazon VPC-to-VPC connectivity, and AWS Direct Connect as required through  {cluster-manager}.
+manage AWS VPN connectivity with on-premise resources, Amazon VPC-to-VPC connectivity, and AWS Direct Connect as required through  {cluster-manager}.
 
 - Enable customers to create and deploy AWS load balancers for use with service load balancers.
 
diff --git a/modules/rosa-policy-incident.adoc b/modules/rosa-policy-incident.adoc
index 355344439619..69b358d7844f 100644
--- a/modules/rosa-policy-incident.adoc
+++ b/modules/rosa-policy-incident.adoc
@@ -102,20 +102,24 @@ Platform audit logs are securely forwarded to a centralized security information
 
 [id="rosa-policy-incident-management_{context}"]
 == Incident management
-An incident is an event that results in a degradation or outage of one or more Red{nbsp}Hat services. An incident can be raised by a customer or a Customer Experience and Engagement (CEE) member through a support case, directly by the centralized monitoring and alerting system, or directly by a member of the SRE team.
+An incident is an event that results in a degradation or outage of one or more Red{nbsp}Hat services, and can affect service-level agreements (SLAs).
+
+Customers and Customer Experience and Engagement (CEE) members can raise an incident through a support case. The centralized monitoring and alerting system and members of the SRE team can also raise an incident directly.
 
 Depending on the impact on the service and customer, the incident is categorized in terms of link:https://access.redhat.com/support/offerings/production/sla[severity].
 
+Red{nbsp}Hat either sends out cluster notifications to affected individual clusters or changes the status at link:https://status.redhat.com[status.redhat.com] to reflect a wider incident. Cluster notifications are not sent for low-impact events, low-risk security updates, routine operations and maintenance, or minor, transient issues that are quickly resolved by SRE.
+
 When managing a new incident, Red{nbsp}Hat uses the following general workflow:
 
 . An SRE first responder is alerted to a new incident and begins an initial investigation.
 . After the initial investigation, the incident is assigned an incident lead, who coordinates the recovery efforts.
-. An incident lead manages all communication and coordination around recovery, including any relevant notifications and support case updates.
+. An incident lead manages all communication and coordination around recovery, including any relevant notifications and support case updates. If the status of a service changes or if Red{nbsp}Hat has a significant update on the progress, then the incident lead sends out an updated cluster notification.
 . The incident is recovered.
 . The incident is documented and a root cause analysis (RCA) is performed within 5 business days of the incident.
 . An RCA draft document will be shared with the customer within 7 business days of the incident.
 
-Red{nbsp}Hat also assists with customer incidents raised through support cases. 
+Red{nbsp}Hat also assists with customer incidents raised through support cases.
 Red{nbsp}Hat can assist with activities including but not limited to:
 
 * Forensic gathering, including isolating virtual compute
diff --git a/modules/rosa-prereq-roles-overview.adoc b/modules/rosa-prereq-roles-overview.adoc
new file mode 100644
index 000000000000..5a7e7fafa299
--- /dev/null
+++ b/modules/rosa-prereq-roles-overview.adoc
@@ -0,0 +1,52 @@
+// Module included in the following assemblies:
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
+
+:_mod-docs-content-type: MODULE
+[id="rosa-prereq-roles-overview"]
+= Overview of required roles
+
+To create and manage your {product-title} cluster, you must create several account-wide and cluster-wide roles. If you intend to use {cluster-manager} to create or manage your cluster, you need some additional roles.
+
+To create and manage clusters:: Several account-wide roles are required to create and manage ROSA clusters. These roles only need to be created once per AWS account, and do not need to be created fresh for each cluster. You can specify your own prefix, or use the default prefix (`ManagedOpenShift`).
++
+The following account-wide roles are required:
+
+ifdef::openshift-rosa-hcp[]
+** `<prefix>-HCP-ROSA-Worker-Role`
+** `<prefix>-HCP-ROSA-Support-Role`
+** `<prefix>-HCP-ROSA-Installer-Role`
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+** `<prefix>-Worker-Role`
+** `<prefix>-Support-Role`
+** `<prefix>-Installer-Role`
+** `<prefix>-ControlPlane-Role`
+endif::openshift-rosa-hcp[]
+
++
+[NOTE]
+====
+Role creation does not request your AWS access or secret keys. AWS Security Token Service (STS) is used as the basis of this workflow. AWS STS uses temporary, limited-privilege credentials to provide authentication.
+====
+
+To manage cluster features provided by Operators:: Cluster-specific Operator roles (`operator-roles` in the ROSA CLI), obtain the temporary permissions required to carry out cluster operations for features provided by Operators, such as managing back-end storage, ingress, and registry. This requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources.
++
+Operator roles are required for every cluster, as several Operators are used to provide cluster features by default.
++
+The following Operator roles are required:
+
+** `<cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credentials`
+** `<cluster_name>-<hash>-openshift-cloud-network-config-controller-credentials`
+** `<cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials`
+** `<cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-credentials`
+** `<cluster_name>-<hash>-openshift-image-registry-installer-cloud-credentials`
+** `<cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials`
+
+To use {cluster-manager}:: The web user interface, {cluster-manager}, requires you to create additional roles in your AWS account to create a trust relationship between that AWS account and the {cluster-manager}.
++
+This trust relationship is achieved through the creation and association of the `ocm-role` AWS IAM role. This role has a trust policy with the AWS installer that links your Red{nbsp}Hat account to your AWS account. In addition, you also need a `user-role` AWS IAM role for each web UI user, which serves to identify these users. This `user-role` AWS IAM role has no permissions.
++
+The following AWS IAM roles are required to use {cluster-manager}:
+
+** `ocm-role`
+** `user-role`
\ No newline at end of file
diff --git a/modules/rosa-required-aws-service-quotas.adoc b/modules/rosa-required-aws-service-quotas.adoc
index 58175ad34212..95d8e7bf5b09 100644
--- a/modules/rosa-required-aws-service-quotas.adoc
+++ b/modules/rosa-required-aws-service-quotas.adoc
@@ -8,8 +8,16 @@
 
 The table below describes the AWS service quotas and levels required to create and run one {product-title} cluster. Although most default values are suitable for most workloads, you might need to request additional quota for the following cases:
 
-* ROSA (classic architecture) clusters require a minimum AWS EC2 service quota of 100 vCPUs to provide for cluster creation, availability, and upgrades. The default maximum value for vCPUs assigned to Running On-Demand Standard Amazon EC2 instances is `5`. Therefore if you have not created a ROSA cluster using the same AWS account previously, you must request additional EC2 quota for `Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`.
-
+* ROSA clusters require a minimum AWS EC2 service quota of
+ifndef::openshift-rosa-hcp[]
+100{nbsp}vCPUs
+endif::[]
+ifdef::openshift-rosa-hcp[]
+32{nbsp}vCPUs
+endif::[]
+to provide for cluster creation, availability, and upgrades. The default maximum value for vCPUs assigned to Running On-Demand Standard Amazon EC2 instances is `5`. Therefore if you have not created a ROSA cluster using the same AWS account previously, you must request additional EC2 quota for `Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`.
+
+//TODO OSDOCS-11789 confirm number of secgroups on HCP clusters - Bala says 10, who can confirm?
 * Some optional cluster configuration features, such as custom security groups, might require you to request additional quota. For example, because ROSA associates 1 security group with network interfaces in worker machine pools by default, and the default quota for `Security groups per network interface` is `5`, if you want to add 5 custom security groups, you must request additional quota, because this would bring the total number of security groups on worker network interfaces to 6.
 
 [NOTE]
@@ -30,27 +38,48 @@ If you need to modify or increase a specific quota, see Amazon's documentation o
 |ec2
 |L-1216C47A
 |5
-|100
-| Maximum number of vCPUs assigned to the Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances.
-
-The default value of 5 vCPUs is not sufficient to create ROSA clusters. ROSA has a minimum requirement of 100 vCPUs for cluster creation.
-
+a|
+ifndef::openshift-rosa-hcp[]
+100
+endif::[]
+ifdef::openshift-rosa-hcp[]
+32
+endif::[]
+|Maximum number of vCPUs assigned to the Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances. The default value of 5 vCPUs is not sufficient to create ROSA clusters.
+
+//gp2 is not used for HCP clusters
+ifndef::openshift-rosa-hcp[]
 |Storage for General Purpose SSD (gp2) volume storage in TiB
 |ebs
 |L-D18FCD1D
 |50
 |300
-| The maximum aggregated amount of storage, in TiB, that can be provisioned across General Purpose SSD (gp2) volumes in this Region.
+|The maximum aggregated amount of storage, in TiB, that can be provisioned across General Purpose SSD (gp2) volumes in this Region.
+endif::openshift-rosa-hcp[]
 
+//HCP minimums assume that Prometheus/Grafana is not used
 |Storage for General Purpose SSD (gp3) volume storage in TiB
 |ebs
 |L-7A658B76
 |50
-|300
-| The maximum aggregated amount of storage, in TiB, that can be provisioned across General Purpose SSD (gp3) volumes in this Region.
-
-300 TiB of storage is the required minimum for optimal performance.
-
+a|
+ifndef::openshift-rosa-hcp[]
+300
+endif::[]
+ifdef::openshift-rosa-hcp[]
+:fn-hcp-storage-quota: footnote:[The default quota of 50{nbsp}TiB is more than {hcp-title} clusters require; however, because AWS cost is based on usage rather than quota, Red{nbsp}Hat recommends using the default quota.]
+1{fn-hcp-storage-quota}
+endif::[]
+a| The maximum aggregated amount of storage, in TiB, that can be provisioned across General Purpose SSD (gp3) volumes in this Region. 
+ifndef::openshift-rosa-hcp[]
+300{nbsp}TiB
+endif::[]
+ifdef::openshift-rosa-hcp[]
+1{nbsp}TiB
+endif::[]
+of storage is the required minimum for optimal performance.
+
+ifndef::openshift-rosa-hcp[]
 |Storage for Provisioned IOPS SSD (io1) volumes in TiB
 |ebs
 |L-FD252861
@@ -58,7 +87,8 @@ The default value of 5 vCPUs is not sufficient to create ROSA clusters. ROSA has
 |300
 | The maximum aggregated amount of storage, in TiB, that can be provisioned across Provisioned IOPS SSD (io1) volumes in this Region.
 
-300 TiB of storage is the required minimum for optimal performance.
+300{nbsp}TiB of storage is the required minimum for optimal performance.
+endif::[]
 
 |===
 
@@ -103,19 +133,23 @@ The default value of 5 vCPUs is not sufficient to create ROSA clusters. ROSA has
 |5
 |The maximum number of security groups per network interface. This quota, multiplied by the quota for rules per security group, cannot exceed 1000.
 
+ifndef::openshift-rosa-hcp[]
 |Snapshots per Region
 |ebs
 |L-309BACF6
 |10,000
 |10,000
 | The maximum number of snapshots per Region
+endif::[]
 
+ifndef::openshift-rosa-hcp[]
 |IOPS for Provisioned IOPS SSD (Io1) volumes
 |ebs
 |L-B3A130E6
 |300,000
 |300,000
 | The maximum aggregated number of IOPS that can be provisioned across Provisioned IOPS SDD (io1) volumes in this Region.
+endif::openshift-rosa-hcp[]
 
 |Application Load Balancers per Region
 |elasticloadbalancing
@@ -124,16 +158,20 @@ The default value of 5 vCPUs is not sufficient to create ROSA clusters. ROSA has
 |50
 |The maximum number of Application Load Balancers that can exist in each region.
 
+ifndef::openshift-rosa-hcp[]
 |Classic Load Balancers per Region
 |elasticloadbalancing
 |L-E9E9831D
 |20
 |20
 |The maximum number of Classic Load Balancers that can exist in each region.
+endif::openshift-rosa-hcp[]
+
 |===
 
 [role="_additional-resources"]
 == Additional resources
 * link:https://aws.amazon.com/premiumsupport/knowledge-center/request-service-quota-increase-cli/[How can I request, view, and manage service quota increase requests using AWS CLI commands?]
 * link:https://docs.aws.amazon.com/ROSA/latest/userguide/service-quotas-rosa.html[ROSA service quotas]
-* link:https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html[Request a quota increase]
\ No newline at end of file
+* link:https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html[Request a quota increase]
+* link:https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html[IAM and AWS STS quotas (AWS documentation)]
\ No newline at end of file
diff --git a/modules/rosa-rhods.adoc b/modules/rosa-rhods.adoc
index 37bd694972f8..59dc9e5dfc21 100644
--- a/modules/rosa-rhods.adoc
+++ b/modules/rosa-rhods.adoc
@@ -2,7 +2,7 @@
 //
 // * adding_service_cluster/rosa-available-services.adoc
 :_mod-docs-content-type: CONCEPT
-[id="rosa-rhods_{context}"]
-= Red{nbsp}Hat OpenShift Data Science
+[id="rosa-AI_{context}"]
+= Red{nbsp}Hat OpenShift AI
 
-{rhods} (RHODS) enables users to integrate data and AI and machine learning software to run end-to-end machine learning workflows. It provides a collection of notebook images with the tools and libraries required to develop and deploy data models. This allows data scientists to easily develop data models, integrate models into applications, and deploy applications using Red{nbsp}Hat OpenShift. RHODS is available as an add-on to Red{nbsp}Hat managed environments such as {osd} and {product-title} (ROSA).
+Red Hat OpenShift AI enables users to integrate data and AI and machine learning software to run end-to-end machine learning workflows. It provides a collection of notebook images with the tools and libraries required to develop and deploy data models. This allows data scientists to easily develop data models, integrate models into applications, and deploy applications using Red{nbsp}Hat OpenShift. OpenShift AI is available as an add-on to Red{nbsp}Hat managed environments such as {osd} and {product-title} (ROSA).
\ No newline at end of file
diff --git a/modules/rosa-sdpolicy-networking.adoc b/modules/rosa-sdpolicy-networking.adoc
index 0f0b26227db5..ecdc221c18ca 100644
--- a/modules/rosa-sdpolicy-networking.adoc
+++ b/modules/rosa-sdpolicy-networking.adoc
@@ -100,6 +100,7 @@ For {product-title} clusters that have a private cloud network configuration, a
 Network verification checks run automatically when you deploy a {product-title} cluster into an existing Virtual Private Cloud (VPC) or create an additional machine pool with a subnet that is new to your cluster. The checks validate your network configuration and highlight errors, enabling you to resolve configuration issues prior to deployment.
 
 You can also run the network verification checks manually to validate the configuration for an existing cluster.
+
 ifeval::["{context}" == "rosa-hcp-service-definition"]
 :!rosa-with-hcp:
 endif::[]
diff --git a/modules/rosa-sdpolicy-platform.adoc b/modules/rosa-sdpolicy-platform.adoc
index b711fc162df9..b187871bc2f4 100644
--- a/modules/rosa-sdpolicy-platform.adoc
+++ b/modules/rosa-sdpolicy-platform.adoc
@@ -4,71 +4,68 @@
 // * rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
 // * rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
 
-ifeval::["{context}" == "rosa-hcp-service-definition"]
-:rosa-with-hcp:
-endif::[]
-
-:_mod-docs-content-type: ASSEMBLY
+:_mod-docs-content-type: MODULE
 [id="rosa-sdpolicy-platform_{context}"]
 = Platform
 :productwinc: Red{nbsp}Hat OpenShift support for Windows Containers
 
 This section provides information about the service definition for the
-ifdef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
 {hcp-title-first} platform.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title} (ROSA) platform.
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 
 [id="rosa-sdpolicy-autoscaling_{context}"]
 == Autoscaling
 Node autoscaling is available on
-ifdef::rosa-with-hcp[]
-{hcp-title-first}.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title}.
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title}.
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 You can configure the autoscaler option to automatically scale the number of machines in a cluster.
 
 [id="rosa-sdpolicy-daemonsets_{context}"]
 == Daemonsets
+
 Customers can create and run daemonsets on
-ifdef::rosa-with-hcp[]
-{hcp-title-first}.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
-{product-title}. To restrict daemonsets to only running on worker nodes, use the following `nodeSelector`:
+ifdef::openshift-rosa-hcp[]
+{hcp-title}.
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+{product-title}.
+endif::openshift-rosa-hcp[]
+To restrict daemonsets to only running on worker nodes, use the following `nodeSelector`:
+
 [source,yaml]
 ----
-...
 spec:
   nodeSelector:
     role: worker
-...
 ----
-endif::rosa-with-hcp[]
 
 [id="rosa-sdpolicy-multiple-availability-zone_{context}"]
 == Multiple availability zone
 
-ifdef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
 Control plane components are always deployed across multiple availability zones, regardless of a customer's worker node configuration.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 In a multiple availability zone cluster, control plane nodes are distributed across availability zones and at least one worker node is required in each availability zone.
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 
 [id="rosa-sdpolicy-node-labels_{context}"]
 == Node labels
 Custom node labels are created by Red{nbsp}Hat during node creation and cannot be changed on
-ifdef::rosa-with-hcp[]
-{hcp-title-first}
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title}
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title}
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 clusters at this time. However, custom labels are supported when creating new machine pools.
 
 [id="rosa-sdpolicy-backup-policy_{context}"]
@@ -76,17 +73,24 @@ clusters at this time. However, custom labels are supported when creating new ma
 
 [IMPORTANT]
 ====
-Red Hat does not provide a backup method for ROSA clusters with STS. It is critical that customers have a backup plan for their applications and application data.
+Red{nbsp}Hat does not provide a backup method for
+ifndef::openshift-rosa-hcp[]
+ROSA clusters that use STS.
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title} clusters.
+endif::openshift-rosa-hcp[]
+It is critical that customers have a backup plan for their applications and application data.
 ====
 
 Application and application data backups are not a part of the
-ifdef::rosa-with-hcp[]
-{hcp-title-first} service.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title} service.
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title} service.
 
-ifndef::rosa-with-hcp[]
+ifndef::openshift-rosa-hcp[]
 
 [%collapsible]
 ====
@@ -121,19 +125,19 @@ The table below only applies to non-STS clusters. The following components are u
 |Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
 |===
 
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 ====
 
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 
 [id="rosa-sdpolicy-openshift-version_{context}"]
 == OpenShift version
-ifdef::rosa-with-hcp[]
-{hcp-title-first}
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title}
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title}
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 is run as a service and is kept up to date with the latest OpenShift Container Platform version. Upgrade scheduling to the latest version is available.
 
 [id="rosa-sdpolicy-upgrades_{context}"]
@@ -148,22 +152,22 @@ See the link:https://docs.openshift.com/rosa/rosa_policy/rosa-life-cycle.html[{p
 
 [id="rosa-sdpolicy-container-engine_{context}"]
 == Container engine
-ifdef::rosa-with-hcp[]
-{hcp-title-first}
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title}
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title}
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 runs on OpenShift 4 and uses link:https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine[CRI-O] as the only available container engine.
 
 [id="rosa-sdpolicy-operating-system_{context}"]
 == Operating system
-ifdef::rosa-with-hcp[]
-{hcp-title-first}
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title}
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title}
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 runs on OpenShift 4 and uses Red{nbsp}Hat CoreOS as the operating system for all control plane and worker nodes.
 
 [id="rosa-sdpolicy-red-hat-operator_{context}"]
@@ -180,8 +184,4 @@ Red{nbsp}Hat workloads typically refer to Red{nbsp}Hat-provided Operators made a
 
 [id="rosa-sdpolicy-kubernetes-operator_{context}"]
 == Kubernetes Operator support
-All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored by Red{nbsp}Hat SRE.
-
-ifeval::["{context}" == "rosa-hcp-service-definition"]
-:!rosa-with-hcp:
-endif::[]
\ No newline at end of file
+All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored by Red{nbsp}Hat SRE.
\ No newline at end of file
diff --git a/modules/rosa-sharing-vpc-dns-and-roles.adoc b/modules/rosa-sharing-vpc-dns-and-roles.adoc
index ae16900e7fb0..a5533ff26cd9 100644
--- a/modules/rosa-sharing-vpc-dns-and-roles.adoc
+++ b/modules/rosa-sharing-vpc-dns-and-roles.adoc
@@ -72,7 +72,7 @@ $ rosa create operator-roles --oidc-config-id <oidc-config-ID> <1>
 The Installer account role and the shared VPC role must have a one-to-one relationship. If you want to create multiple shared VPC roles, you should create one set of account roles per shared VPC role.
 ====
 
-. After you create the Operator roles, share the full domain name, which is created with `<intended_cluster_name>.<reserved_dns_domain>`, your _Ingress Operator Cloud Credentials_ role's ARN, and your _Installer_ role's ARN with the *VPC Owner* to continue configuration.
+. After you create the Operator roles, share the full domain name, which is created with `<intended_cluster_domain_prefix>.<reserved_dns_domain>`, your _Ingress Operator Cloud Credentials_ role's ARN, and your _Installer_ role's ARN with the *VPC Owner* to continue configuration.
 +
 The shared information resembles these examples:
 +
diff --git a/modules/rosa-sharing-vpc-hosted-zones.adoc b/modules/rosa-sharing-vpc-hosted-zones.adoc
index 1b2ce1901855..6673cf7e890f 100644
--- a/modules/rosa-sharing-vpc-hosted-zones.adoc
+++ b/modules/rosa-sharing-vpc-hosted-zones.adoc
@@ -39,7 +39,7 @@ image::372_OpenShift_on_AWS_persona_worflows_0923_3.png[]
   ]
 }
 ----
-. Create a private hosted zone in the link:https://us-east-1.console.aws.amazon.com/route53/v2/[Route 53 section of the AWS console]. In the hosted zone configuration, the domain name is `<cluster_name>.<reserved_dns_domain>`. The private hosted zone must be associated with the created VPC.
+. Create a private hosted zone in the link:https://us-east-1.console.aws.amazon.com/route53/v2/[Route 53 section of the AWS console]. In the hosted zone configuration, the domain name is `<cluster_domain_prefix>.<reserved_dns_domain>`. The private hosted zone must be associated with the created VPC.
 . After the hosted zone is created and associated with the VPC, provide the following to the *Cluster Creator* to continue configuration:
 * Hosted zone ID
 * AWS region
diff --git a/modules/rosa-sts-account-wide-role-and-policy-commands.adoc b/modules/rosa-sts-account-wide-role-and-policy-commands.adoc
index 7f6810508d71..59e939391043 100644
--- a/modules/rosa-sts-account-wide-role-and-policy-commands.adoc
+++ b/modules/rosa-sts-account-wide-role-and-policy-commands.adoc
@@ -11,7 +11,7 @@ This section lists the `aws` CLI commands that the `rosa` command generates in t
 [id="rosa-sts-account-wide-role-and-policy-aws-cli-manual-mode_{context}"]
 == Using manual mode for account role creation
 
-The manual role creation mode generates the `aws` commands for you to review and run. The following command starts that process, where `<openshift_version>` refers to your version of {product-title} (ROSA), such as `4.17`.
+The manual role creation mode generates the `aws` commands for you to review and run. The following command starts that process, where `<openshift_version>` refers to your version of {product-title} (ROSA), such as `{product-version}`.
 
 [source,terminal]
 ----
diff --git a/modules/rosa-sts-account-wide-roles-and-policies.adoc b/modules/rosa-sts-account-wide-roles-and-policies.adoc
index 012fcade4122..a629e1fec9ad 100644
--- a/modules/rosa-sts-account-wide-roles-and-policies.adoc
+++ b/modules/rosa-sts-account-wide-roles-and-policies.adoc
@@ -7,7 +7,7 @@
 
 This section provides details about the account-wide IAM roles and policies that are required for ROSA deployments that use STS, including the Operator policies. It also includes the JSON files that define the policies.
 
-The account-wide roles and policies are specific to an {product-title} minor release version, for example {product-title} 4.17, and are compatible with earlier versions. You can minimize the required STS resources by reusing the account-wide roles and policies for multiple clusters of the same minor version, regardless of their patch version.
+The account-wide roles and policies are specific to an {product-title} minor release version, for example {product-title} {product-version}, and are compatible with earlier versions. You can minimize the required STS resources by reusing the account-wide roles and policies for multiple clusters of the same minor version, regardless of their patch version.
 
 [id="rosa-sts-account-wide-roles-and-policies-creation-methods_{context}"]
 == Methods of account-wide role creation
@@ -52,7 +52,7 @@ The account number present in the `sts_installer_trust_policy.json` and `sts_sup
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_trust_policy.json[]
 ----
 ====
 
@@ -61,7 +61,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_permission_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_permission_policy.json[]
 ----
 ====
 
@@ -84,7 +84,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_instance_controlplane_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_instance_controlplane_trust_policy.json[]
 ----
 ====
 
@@ -93,7 +93,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_instance_controlplane_permission_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_instance_controlplane_permission_policy.json[]
 ----
 ====
 
@@ -116,7 +116,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_instance_worker_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_instance_worker_trust_policy.json[]
 ----
 ====
 
@@ -125,7 +125,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_instance_worker_permission_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_instance_worker_permission_policy.json[]
 ----
 ====
 
@@ -148,7 +148,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_support_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_support_trust_policy.json[]
 ----
 ====
 
@@ -157,7 +157,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_support_permission_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_support_permission_policy.json[]
 ----
 ====
 
@@ -177,7 +177,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_ocm_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_ocm_trust_policy.json[]
 ----
 ====
 
@@ -197,7 +197,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_trust_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_trust_policy.json[]
 ----
 ====
 
@@ -255,7 +255,7 @@ I: Attached policy 'arn:aws:iam::000000000000:policy/testrole-Worker-Role-Policy
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/openshift_ingress_operator_cloud_credentials_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/openshift_ingress_operator_cloud_credentials_policy.json[]
 ----
 ====
 
@@ -275,7 +275,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json[]
 ----
 ====
 
@@ -295,7 +295,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/openshift_machine_api_aws_cloud_credentials_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/openshift_machine_api_aws_cloud_credentials_policy.json[]
 ----
 ====
 
@@ -315,7 +315,7 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json[]
 ----
 ====
 
@@ -335,6 +335,6 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/openshift_image_registry_installer_cloud_credentials_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/openshift_image_registry_installer_cloud_credentials_policy.json[]
 ----
 ====
diff --git a/modules/rosa-sts-aws-requirements-access-req.adoc b/modules/rosa-sts-aws-requirements-access-req.adoc
deleted file mode 100644
index 69247f996f54..000000000000
--- a/modules/rosa-sts-aws-requirements-access-req.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-// Module included in the following assemblies:
-//
-// * rosa_planning/rosa-sts-aws-prereqs.adoc
-:_mod-docs-content-type: CONCEPT
-[id="rosa-access-requirements_{context}"]
-= Access requirements
-
-* Red{nbsp}Hat must have AWS console access to the customer-provided AWS account. Red{nbsp}Hat protects and manages this access.
-* You must not use the AWS account to elevate your permissions within the {product-title} (ROSA) cluster.
-* Actions available in the ROSA CLI (`rosa`) or {cluster-manager-url} console must not be directly performed in your AWS account.
-* You do not need to have a preconfigured domain to deploy ROSA clusters. If you wish to use a custom domain, see the Additional resources for information.
diff --git a/modules/rosa-sts-aws-requirements-account.adoc b/modules/rosa-sts-aws-requirements-account.adoc
index 3039854dbe7e..fee0788772ff 100644
--- a/modules/rosa-sts-aws-requirements-account.adoc
+++ b/modules/rosa-sts-aws-requirements-account.adoc
@@ -3,21 +3,9 @@
 // * rosa_planning/rosa-sts-aws-prereqs.adocx
 :_mod-docs-content-type: CONCEPT
 [id="rosa-account_{context}"]
-= Account
-* You must ensure that the AWS limits are sufficient to support {product-title} provisioned within your AWS account. Running the `rosa verify quota` command in the CLI validates that you have the required quota to run a cluster.
-+
-[NOTE]
-====
-Quota verification checks your AWS quota, but it does not compare your consumption to your AWS quota. See the "Limits and scalability" link in Additional resources for more information.
-====
-+
-* If SCP policies are applied and enforced, these policies must not be more restrictive than the roles and policies required by the cluster.
-* Your AWS account should not be transferable to Red{nbsp}Hat.
-* You should not impose additional AWS usage restrictions beyond the defined roles and policies on Red{nbsp}Hat activities. Imposing restrictions will severely hinder Red{nbsp}Hat's ability to respond to incidents.
-* You may deploy native AWS services within the same AWS account.
-* Your account must have a service-linked role set up as it is required for Elastic Load Balancing (ELB) to be configured. See the "Creating the Elastic Load Balancing (ELB) service-linked role" link in the Additional resources for information about creating a service-linked role for your ELB if you have not created a load balancer in your AWS account previously.
-+
-[NOTE]
-====
-You are encouraged, but not required, to deploy resources in a Virtual Private Cloud (VPC) separate from the VPC hosting {product-title} and other Red{nbsp}Hat supported services.
-====
+= AWS account
+
+* Your AWS account must allow sufficient quota to deploy your cluster.
+* If your organization applies and enforces SCP policies, these policies must not be more restrictive than the roles and policies required by the cluster.
+* You can deploy native AWS services within the same AWS account.
+* Your account must have a service-linked role to allow the installation program to configure Elastic Load Balancing (ELB). See "Creating the Elastic Load Balancing (ELB) service-linked role" for more information.
\ No newline at end of file
diff --git a/modules/rosa-sts-aws-requirements-association-concept.adoc b/modules/rosa-sts-aws-requirements-association-concept.adoc
index edc081880475..624acd315fdf 100644
--- a/modules/rosa-sts-aws-requirements-association-concept.adoc
+++ b/modules/rosa-sts-aws-requirements-association-concept.adoc
@@ -6,6 +6,6 @@
 [id="rosa-associating-concept_{context}"]
 = AWS account association
 
-{product-title} (ROSA) cluster-provisioning tasks require linking `ocm-role` and `user-role` IAM roles to your AWS account using your Amazon Resource Name (ARN).
+When you provision {product-title} (ROSA) using {cluster-manager}, you must associate the `ocm-role` and `user-role` IAM roles with your AWS account using your Amazon Resource Name (ARN). This association process is also known as _account linking_.
 
-The `ocm-role` ARN is stored as a label in your Red{nbsp}Hat organization while the `user-role` ARN is stored as a label inside your Red{nbsp}Hat user account. Red{nbsp}Hat uses these ARN labels to confirm that the user is a valid account holder and that the correct permissions are available to perform the necessary tasks in the AWS account.
+The `ocm-role` ARN is stored as a label in your Red{nbsp}Hat organization while the `user-role` ARN is stored as a label inside your Red{nbsp}Hat user account. Red{nbsp}Hat uses these ARN labels to confirm that the user is a valid account holder and that the correct permissions are available to perform provisioning tasks in the AWS account.
diff --git a/modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc b/modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc
index a7cd9609418e..500c73ba9931 100644
--- a/modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc
+++ b/modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc
@@ -7,7 +7,7 @@
 = Permission boundaries for the installer role
 
 You can apply a policy as a _permissions boundary_ on an installer role.
-You can use an AWS-managed policy or a customer-managed policy to set the boundary for an Amazon Web Services(AWS) Identity and Access Management (IAM) entity (user or role). The combination of policy and boundary policy limits the maximum permissions for the user or role. ROSA includes a set of three prepared permission boundary policy files, with which you can restrict permissions for the installer role since changing the installer policy itself is not supported.
+You can use an AWS-managed policy or a customer-managed policy to set the boundary for an Amazon Web Services (AWS) Identity and Access Management (IAM) entity (user or role). The combination of policy and boundary policy limits the maximum permissions for the user or role. ROSA includes a set of three prepared permission boundary policy files, with which you can restrict permissions for the installer role since changing the installer policy itself is not supported.
 
 [NOTE]
 ====
@@ -42,7 +42,7 @@ This example procedure is applicable for an installer role and policy with the m
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_core_permission_boundary_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.json[]
 ----
 ====
 
@@ -65,7 +65,7 @@ While the ROSA (`rosa`) CLI offers a permission boundary function, it applies to
 +
 [source,terminal]
 ----
-$ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.17/sts_installer_core_permission_boundary_policy.json
+$ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.json
 ----
 
 . Create the policy in AWS and gather its Amazon Resource Name (ARN) by entering the following command:
@@ -128,7 +128,7 @@ For more examples of PL and VPC permission boundary policies see:
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_privatelink_permission_boundary_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_privatelink_permission_boundary_policy.json[]
 ----
 ====
 +
@@ -137,6 +137,6 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
 ====
 [source,json]
 ----
-include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.17/sts_installer_vpc_permission_boundary_policy.json[]
+include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.18/sts_installer_vpc_permission_boundary_policy.json[]
 ----
 ====
diff --git a/modules/rosa-sts-aws-requirements-creating-association.adoc b/modules/rosa-sts-aws-requirements-creating-association.adoc
index 2e16ee917e48..42d99f3409d6 100644
--- a/modules/rosa-sts-aws-requirements-creating-association.adoc
+++ b/modules/rosa-sts-aws-requirements-creating-association.adoc
@@ -2,19 +2,20 @@
 //
 // * rosa_planning/rosa-sts-ocm-role.adoc
 // * rosa_planning/rosa-sts-aws-prereqs.adoc
+// * support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
+
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-associating-account_{context}"]
-= Linking your AWS account
+= Associating your AWS account with IAM roles
 
-You can link your AWS account to existing IAM roles by using the {product-title} (ROSA) CLI, `rosa`.
+You can associate or link your AWS account with existing IAM roles by using the {product-title} (ROSA) CLI, `rosa`.
 
 .Prerequisites
 
 * You have an AWS account.
-* You are using {cluster-manager-url} to create clusters.
 * You have the permissions required to install AWS account-wide roles. See the "Additional resources" of this section for more information.
 * You have installed and configured the latest AWS (`aws`) and ROSA (`rosa`) CLIs on your installation host.
-* You have created your `ocm-role` and `user-role` IAM roles, but have not yet linked them to your AWS account. You can check whether your IAM roles are already linked by running the following commands:
+* You have created the `ocm-role` and `user-role` IAM roles, but have not yet linked them to your AWS account. You can check whether your IAM roles are already linked by running the following commands:
 +
 [source,terminal]
 ----
diff --git a/modules/rosa-sts-aws-requirements-ocm.adoc b/modules/rosa-sts-aws-requirements-ocm.adoc
index c429affbf157..4ada3a8b7573 100644
--- a/modules/rosa-sts-aws-requirements-ocm.adoc
+++ b/modules/rosa-sts-aws-requirements-ocm.adoc
@@ -6,6 +6,6 @@
 [id="rosa-ocm-requirements_{context}"]
 = Requirements for using {cluster-manager}
 
-The following sections describe requirements for {cluster-manager-url}. If you use the CLI tools exclusively, then you can disregard the requirements.
+The following configuration details are required only if you use {cluster-manager-url} to manage your clusters. If you use the CLI tools exclusively, then you can disregard these requirements.
 
-To use {cluster-manager}, you must link your AWS accounts. This linking concept is also known as account association.
\ No newline at end of file
+To use {cluster-manager}, you must link the roles in your Red{nbsp}Hat user organization and your Red{nbsp}Hat account to your AWS account. This linking concept is also known as account association.
\ No newline at end of file
diff --git a/modules/rosa-sts-aws-requirements-security-req.adoc b/modules/rosa-sts-aws-requirements-security-req.adoc
index 9bb9e913219a..4012e28aa3ea 100644
--- a/modules/rosa-sts-aws-requirements-security-req.adoc
+++ b/modules/rosa-sts-aws-requirements-security-req.adoc
@@ -5,5 +5,6 @@
 :_mod-docs-content-type: CONCEPT
 [id="rosa-security-requirements_{context}"]
 = Security requirements
+//TODO OSDOCS-11789: Red Hat as in RHSRE? Red Hat as in RH services in the cluster?
 * Red{nbsp}Hat must have ingress access to EC2 hosts and the API server from allow-listed IP addresses.
-* Red{nbsp}Hat must have egress allowed to the documented domains. See the "AWS firewall prerequisites" section for the designated domains.
+* Red{nbsp}Hat must have egress allowed to the domains documented in the "Firewall prerequisites" section.
diff --git a/modules/rosa-sts-byo-oidc.adoc b/modules/rosa-sts-byo-oidc.adoc
index b926312c6b58..39b8ef57d22e 100644
--- a/modules/rosa-sts-byo-oidc.adoc
+++ b/modules/rosa-sts-byo-oidc.adoc
@@ -5,32 +5,29 @@
 // * rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc
 // * rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc
 // * rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc
-
-ifeval::["{context}" == "rosa-hcp-sts-creating-a-cluster-quickly"]
-:rosa-hcp:
-endif::[]
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-byo-oidc_{context}"]
 = Creating an OpenID Connect configuration
 
 When using a
-ifdef::rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
 {hcp-title} cluster, you must
-endif::rosa-hcp[]
-ifndef::rosa-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 {product-title} cluster, you can
-endif::rosa-hcp[]
+endif::openshift-rosa-hcp[]
 create the OpenID Connect (OIDC) configuration prior to creating your cluster. This configuration is registered to be used with OpenShift Cluster Manager.
 
 .Prerequisites
 
-ifdef::rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
 * You have completed the AWS prerequisites for {hcp-title}.
-endif::rosa-hcp[]
-ifdef::rosa-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 * You have completed the AWS prerequisites for {product-title}.
-endif::rosa-hcp[]
+endif::openshift-rosa-hcp[]
 * You have installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your installation host.
 
 .Procedure
diff --git a/modules/rosa-sts-creating-a-cluster-with-customizations-cli.adoc b/modules/rosa-sts-creating-a-cluster-with-customizations-cli.adoc
index 91d86eba40dd..188924b6e2a0 100644
--- a/modules/rosa-sts-creating-a-cluster-with-customizations-cli.adoc
+++ b/modules/rosa-sts-creating-a-cluster-with-customizations-cli.adoc
@@ -258,7 +258,7 @@ I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role for th
 ? Disable Workload monitoring (optional): No
 I: Creating cluster '<cluster_name>'
 I: To create this cluster again in the future, you can run:
-   rosa create cluster --cluster-name <cluster_name> --role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role --support-role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role --master-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role --worker-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role --operator-roles-prefix <cluster_name>-<random_string> --region us-east-1 --version 4.17.0 --additional-compute-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-infra-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-control-plane-security-group-ids sg-0e375ff0ec4a6cfa2 --replicas 2 --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 --pod-cidr 10.128.0.0/14 --host-prefix 23 <16>
+   rosa create cluster --cluster-name <cluster_name> --role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role --support-role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role --master-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role --worker-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role --operator-roles-prefix <cluster_name>-<random_string> --region us-east-1 --version 4.18.0 --additional-compute-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-infra-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-control-plane-security-group-ids sg-0e375ff0ec4a6cfa2 --replicas 2 --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 --pod-cidr 10.128.0.0/14 --host-prefix 23 <16>
 I: To view a list of clusters and their status, run 'rosa list clusters'
 I: Cluster '<cluster_name>' has been created.
 I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information.
@@ -267,7 +267,7 @@ I: Once the cluster is installed you will need to add an Identity Provider befor
 <1> Optional. When creating your cluster, you can customize the subdomain for your cluster on `*.openshiftapps.com` using the `--domain-prefix` flag. The value for this flag must be unique within your organization, cannot be longer than 15 characters, and cannot be changed after cluster creation. If the flag is not supplied, an autogenerated value is created that depends on the length of the cluster name. If the cluster name is fewer than or equal to 15 characters, that name is used for the domain prefix. If the cluster name is longer than 15 characters, the domain prefix is randomly generated to a 15 character string.
 <2> When creating your cluster, you can create a local administrator user (`cluster-admin`) for your cluster. This automatically configures an `htpasswd` identity provider for the `cluster-admin` user.
 <3> You can create a custom password for the `cluster-admin` user, or have the system generate a password. If you do not create a custom password, the generated password is displayed in the command line output. If you specify a custom password, the password must be at least 14 characters (ASCII-standard) without any whitespace. When defined, the password is hashed and transported securely.
-<4> When creating the cluster, the listed `OpenShift version` options include the major, minor, and patch versions, for example `4.17.0`.
+<4> When creating the cluster, the listed `OpenShift version` options include the major, minor, and patch versions, for example `4.18.0`.
 <5> Optional: Specify `optional` to configure all EC2 instances to use both v1 and v2 endpoints of EC2 Instance Metadata Service (IMDS). This is the default value. Specify `required` to configure all EC2 instances to use IMDSv2 only.
 +
 ifdef::openshift-rosa[]
diff --git a/modules/rosa-sts-interactive-cluster-creation-mode-options.adoc b/modules/rosa-sts-interactive-cluster-creation-mode-options.adoc
index 18f3cd11b487..76683711af15 100644
--- a/modules/rosa-sts-interactive-cluster-creation-mode-options.adoc
+++ b/modules/rosa-sts-interactive-cluster-creation-mode-options.adoc
@@ -105,7 +105,7 @@ Tags that are added by Red{nbsp}Hat are required for clusters to stay in complia
 |Select the additional custom security group IDs that are used with the control plane nodes created along side the cluster. The default is none selected. Only security groups associated with the selected VPC are displayed. You can select a maximum of 5 additional security groups.
 
 |`Compute nodes`
-|Specify the number of compute nodes to provision into each availability zone. Clusters deployed in a single availability zone require at least 2 nodes. Clusters deployed in multiple zones must have at least 3 nodes. The maximum number of worker nodes is 180 nodes. The default value is `2`.
+|Specify the number of compute nodes to provision into each availability zone. Clusters deployed in a single availability zone require at least 2 nodes. Clusters deployed in multiple zones must have at least 3 nodes. The maximum number of worker nodes is 249 nodes. The default value is `2`.
 
 |`Default machine pool labels (optional)`
 |Specify the labels for the default machine pool. The label format should be a comma-separated list of key-value pairs. This list will overwrite any modifications made to node labels on an ongoing basis.
diff --git a/modules/rosa-sts-ocm-and-user-role-troubleshooting.adoc b/modules/rosa-sts-ocm-and-user-role-troubleshooting.adoc
index a0abccddaf83..ea557028cc17 100644
--- a/modules/rosa-sts-ocm-and-user-role-troubleshooting.adoc
+++ b/modules/rosa-sts-ocm-and-user-role-troubleshooting.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * support/rosa-troubleshooting-iam-resources.adoc
+// * support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-ocm-roles-and-permissions-troubleshooting_{context}"]
diff --git a/modules/rosa-sts-ocm-role-creation.adoc b/modules/rosa-sts-ocm-role-creation.adoc
index d3851897092a..b2048b24a0c1 100644
--- a/modules/rosa-sts-ocm-role-creation.adoc
+++ b/modules/rosa-sts-ocm-role-creation.adoc
@@ -1,7 +1,8 @@
 // Module included in the following assemblies:
-//* rosa_architecture/rosa-sts-about-iam-resources.adoc
-// * support/rosa-troubleshooting-iam-resources.adoc
+// * rosa_architecture/rosa-sts-about-iam-resources.adoc
+// * support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
 // * rosa_planning/rosa-sts-ocm-role.adoc
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-ocm-roles-and-permissions-iam-basic-role_{context}"]
 = Creating an ocm-role IAM role
@@ -30,7 +31,8 @@ $ rosa create ocm-role
 $ rosa create ocm-role --admin
 ----
 +
-This command allows you create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (`rosa`) create your Operator roles and policies. See "Methods of account-wide role creation" in the Additional resources for more information.
+This command allows you to create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (`rosa`) create your Operator roles and policies.
+See "Methods of account-wide role creation" for more information.
 
 .Example output
 [source,terminal]
diff --git a/modules/rosa-sts-oidc-provider-command.adoc b/modules/rosa-sts-oidc-provider-command.adoc
index e2a072d44743..799d45b4047d 100644
--- a/modules/rosa-sts-oidc-provider-command.adoc
+++ b/modules/rosa-sts-oidc-provider-command.adoc
@@ -2,7 +2,7 @@
 //
 // * rosa_architecture/rosa-sts-about-iam-resources.adoc
 // * rosa_architecture/rosa_policy_service_definition/rosa-oidc-overview.adoc
-
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-oidc-provider-for-operators-aws-cli_{context}"]
 = Creating an OIDC provider using the CLI
diff --git a/modules/rosa-sts-operator-roles.adoc b/modules/rosa-sts-operator-roles.adoc
index 25433e3f4dbf..0b7273018efa 100644
--- a/modules/rosa-sts-operator-roles.adoc
+++ b/modules/rosa-sts-operator-roles.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * rosa_architecture/rosa-sts-about-iam-resources.adoc
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="rosa-sts-operator-roles_{context}"]
diff --git a/modules/rosa-sts-overview-of-the-default-cluster-specifications.adoc b/modules/rosa-sts-overview-of-the-default-cluster-specifications.adoc
index b0444403f418..02d4754f0ea0 100644
--- a/modules/rosa-sts-overview-of-the-default-cluster-specifications.adoc
+++ b/modules/rosa-sts-overview-of-the-default-cluster-specifications.adoc
@@ -129,7 +129,7 @@ endif::tf-classic,tf-hcp[]
 ifndef::tf-classic,tf-hcp[]
 * Machine CIDR: 10.0.0.0/16
 * Service CIDR: 172.30.0.0/16
-* Pod CIDR: 10.128.0.0/16
+* Pod CIDR: 10.128.0.0/14
 endif::tf-classic,tf-hcp[]
 * Host prefix: /23
 +
diff --git a/modules/rosa-sts-setting-up-environment.adoc b/modules/rosa-sts-setting-up-environment.adoc
index 0d6b5fcf4b13..e80b909ce78e 100644
--- a/modules/rosa-sts-setting-up-environment.adoc
+++ b/modules/rosa-sts-setting-up-environment.adoc
@@ -4,7 +4,6 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-setting-up-environment_{context}"]
-
 = Setting up the environment for STS
 
 Before you create a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS), complete the following steps to set up your environment.
diff --git a/modules/rosa-sts-user-role-creation.adoc b/modules/rosa-sts-user-role-creation.adoc
index 7963336b0fd1..5f6a0988e1dd 100644
--- a/modules/rosa-sts-user-role-creation.adoc
+++ b/modules/rosa-sts-user-role-creation.adoc
@@ -1,7 +1,8 @@
 // Module included in the following assemblies:
 //
-// * support/rosa-troubleshooting-iam-resources.adoc
+// * support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
 // * rosa_planning/rosa-sts-ocm-role.adoc
+// * rosa_planning/rosa-hcp-prepare-iam-resources.adoc
 :_mod-docs-content-type: PROCEDURE
 [id="rosa-sts-user-role-iam-basic-role_{context}"]
 = Creating a user-role IAM role
@@ -21,7 +22,8 @@ You can create your `user-role` IAM roles by using the command-line interface (C
 $ rosa create user-role
 ----
 +
-This command allows you create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (`rosa`) to create your Operator roles and policies. See "Understanding the auto and manual deployment modes" in the Additional resources for more information.
+This command allows you to create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (`rosa`) to create your Operator roles and policies.
+See "Understanding the auto and manual deployment modes" for more information.
 
 .Example output
 [source,terminal]
diff --git a/modules/rosa-troubleshooting-cluster-deletion.adoc b/modules/rosa-troubleshooting-cluster-deletion.adoc
index 4de908f74cb0..29247cf04c2e 100644
--- a/modules/rosa-troubleshooting-cluster-deletion.adoc
+++ b/modules/rosa-troubleshooting-cluster-deletion.adoc
@@ -38,4 +38,4 @@ $ rosa create user-role
 [source,terminal]
 ----
 I: Successfully linked role ARN <user role ARN> with account <account ID>
-----
\ No newline at end of file
+----
diff --git a/modules/rosa-troubleshooting-elb-service-role.adoc b/modules/rosa-troubleshooting-elb-service-role.adoc
index 3dbb6c4083a8..64783c1be897 100644
--- a/modules/rosa-troubleshooting-elb-service-role.adoc
+++ b/modules/rosa-troubleshooting-elb-service-role.adoc
@@ -14,13 +14,13 @@ Error: Error creating network Load Balancer: AccessDenied: User: arn:aws:sts::xx
 
 .Procedure
 
-To resolve this issue, ensure that the role exists on your AWS account. If not, create this role with the following command:
-
+* To resolve this issue, ensure that the role exists on your AWS account. If not, create this role with the following command:
++
 [source,terminal]
 ----
 aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" || aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
 ----
-
++
 [NOTE]
 ====
 This command only needs to be executed once per account.
diff --git a/modules/rosa-troubleshooting-general-deployment.adoc b/modules/rosa-troubleshooting-general-deployment.adoc
index e7eb9db4afa3..02069708904b 100644
--- a/modules/rosa-troubleshooting-general-deployment.adoc
+++ b/modules/rosa-troubleshooting-general-deployment.adoc
@@ -8,8 +8,9 @@
 If a cluster deployment fails, the cluster is put into an "error" state.
 
 .Procedure
-Run the following command to get more information:
 
+* Run the following command to get more information:
++
 [source,terminal]
 ----
 $ rosa describe cluster -c <my_cluster_name> --debug
diff --git a/modules/rosa-troubleshooting-installing.adoc b/modules/rosa-troubleshooting-installing.adoc
index 72288e9a85d4..54fcf243f7dd 100644
--- a/modules/rosa-troubleshooting-installing.adoc
+++ b/modules/rosa-troubleshooting-installing.adoc
@@ -39,6 +39,7 @@ $ rosa logs uninstall --cluster=<cluster_name>
 $ rosa logs uninstall --cluster=<cluster_name> --watch
 ----
 
+ifndef::openshift-rosa-hcp[]
 [id="rosa-faq-verify-permissions-for-clusters-without-sts_{context}"]
 == Verify your AWS account permissions for clusters without STS
 
@@ -50,6 +51,7 @@ $ rosa verify permissions
 ----
 
 If you receive any errors, double check to ensure than an link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_type-auth.html#orgs_manage_policies_scp[SCP] is not applied to your AWS account. If you are required to use an SCP, see link:https://www.openshift.com/dedicated/ccs#scp[Red{nbsp}Hat Requirements for Customer Cloud Subscriptions] for details on the minimum required SCP.
+endif::openshift-rosa-hcp[]
 
 [id="rosa-faq-verify-aws-quota_{context}"]
 == Verify your AWS account and quota
diff --git a/modules/rosa-troubleshooting-networking-nlb.adoc b/modules/rosa-troubleshooting-networking-nlb.adoc
index a86f35328dac..003c9eac415e 100644
--- a/modules/rosa-troubleshooting-networking-nlb.adoc
+++ b/modules/rosa-troubleshooting-networking-nlb.adoc
@@ -5,6 +5,6 @@
 [id="rosa-troubleshooting-general-deployment-failure_{context}"]
 = Connectivity issues on clusters with private Network Load Balancers
 
-{product-title} and {hcp-title} clusters created with version {product-version} deploy AWS Network Load Balancers (NLB) by default for the `default` ingress controller. In the case of a private NLB, the NLB's client IP address preservation might cause connections to be dropped where the source and destination are the same host. See the AWS's documentation about how to link:https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#loopback-timeout[Troubleshoot your Network Load Balancer]. This IP address preservation has the implication that any customer workloads cohabitating on the same node with the router pods, may not be able send traffic to the private NLB fronting the ingress controller router.
+{product-title} clusters created with version {product-version} deploy AWS Network Load Balancers (NLB) by default for the `default` ingress controller. In the case of a private NLB, the NLB's client IP address preservation might cause connections to be dropped where the source and destination are the same host. See the AWS's documentation about how to link:https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#loopback-timeout[Troubleshoot your Network Load Balancer]. This IP address preservation has the implication that any customer workloads cohabitating on the same node with the router pods, may not be able send traffic to the private NLB fronting the ingress controller router.
 
-To mitigate this impact, customer's should reschedule their workloads onto nodes separate from those where the router pods are scheduled. Alternatively, customers should rely on the internal pod and service networks for accessing other workloads co-located within the same cluster.
\ No newline at end of file
+To mitigate this impact, customers should reschedule their workloads onto nodes separate from those where the router pods are scheduled. Alternatively, customers should rely on the internal pod and service networks for accessing other workloads co-located within the same cluster.
diff --git a/modules/rosa-verify-hcp-install.adoc b/modules/rosa-verify-hcp-install.adoc
new file mode 100644
index 000000000000..6d0e83ce939b
--- /dev/null
+++ b/modules/rosa-verify-hcp-install.adoc
@@ -0,0 +1,8 @@
+// Module included in the following assemblies:
+//
+// * support/rosa-troubleshooting-installations-hcp .adoc
+:_mod-docs-content-type: PROCEDURE
+[id="rosa-verify-hcp-install_{context}"]
+= Verifying installation of {hcp-title} clusters
+
+If the {hcp-title} cluster is in the installing state for over 30 minutes and has not become ready, ensure the AWS account environment is prepared for the required cluster configurations. If the AWS account environment is prepared for the required cluster configurations correctly, try to delete and recreate the cluster. If the problem persists, contact support.
\ No newline at end of file
diff --git a/modules/rotating-bound-service-keys.adoc b/modules/rotating-bound-service-keys.adoc
new file mode 100644
index 000000000000..f018e9aa5d35
--- /dev/null
+++ b/modules/rotating-bound-service-keys.adoc
@@ -0,0 +1,409 @@
+// Module included in the following assemblies:
+//
+// * post_installation_configuration/changing-cloud-credentials-configuration.adoc
+
+ifeval::["{context}" == "key-rotation-aws"]
+:rotate-aws:
+endif::[]
+ifeval::["{context}" == "key-rotation-gcp"]
+:rotate-gcp:
+endif::[]
+ifeval::["{context}" == "key-rotation-azure"]
+:rotate-azure:
+endif::[]
+
+:_mod-docs-content-type: PROCEDURE
+[id="rotating-bound-service-keys_{context}"]
+ifdef::rotate-aws[= Rotating {aws-short} OIDC bound service account signer keys]
+ifdef::rotate-gcp[= Rotating {gcp-short} OIDC bound service account signer keys]
+ifdef::rotate-azure[= Rotating {azure-short} OIDC bound service account signer keys]
+
+If the Cloud Credential Operator (CCO) for your {product-title} cluster 
+ifdef::rotate-aws[on {aws-first}]
+ifdef::rotate-gcp[on {gcp-first}]
+ifdef::rotate-azure[on {azure-first}]
+is configured to operate in manual mode with 
+ifdef::rotate-aws[{sts-short},]
+ifdef::rotate-gcp[{gcp-wid-short},]
+ifdef::rotate-azure[{entra-first},]
+you can rotate the bound service account signer key.
+
+To rotate the key, you delete the existing key on your cluster, which causes the Kubernetes API server to create a new key.
+To reduce authentication failures during this process, you must immediately add the new public key to the existing issuer file. 
+After the cluster is using the new key for authentication, you can remove any remaining keys.
+
+//Modified version of the disclaimer from enabling Azure WID on an existing cluster, since there are similar concerns:
+[IMPORTANT]
+====
+The process to rotate OIDC bound service account signer keys is disruptive and takes a significant amount of time.
+Some steps are time-sensitive.
+Before proceeding, observe the following considerations:
+
+* Read the following steps and ensure that you understand and accept the time requirement.
+The exact time requirement varies depending on the individual cluster, but it is likely to require at least one hour.
+
+* To reduce the risk of authentication failures, ensure that you understand and prepare for the time-sensitive steps.
+
+* During this process, you must refresh all service accounts and restart all pods on the cluster.
+These actions are disruptive to workloads.
+To mitigate this impact, you can temporarily halt these services and then redeploy them when the cluster is ready.
+====
+
+.Prerequisites
+
+* You have access to the {oc-first} as a user with the `cluster-admin` role.
+//Permissions requirements (per platform, for install and key rotation)
+include::snippets/ccoctl-provider-permissions-requirements.adoc[]
+* You have configured the `ccoctl` utility.
+* Your cluster is in a stable state.
+You can confirm that the cluster is stable by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-stable-cluster --minimum-stable-period=5s
+----
+
+.Procedure
+
+. Configure the following environment variables:
++
+[source,text]
+----
+ifdef::rotate-aws[]
+INFRA_ID=$(oc get infrastructures cluster -o jsonpath='{.status.infrastructureName}')
+CLUSTER_NAME=${INFRA_ID%-*} <1>
+endif::rotate-aws[]
+ifdef::rotate-gcp[]
+CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
+GCP_BUCKET=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
+endif::rotate-gcp[]
+ifdef::rotate-azure[]
+CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
+AZURE_STORAGE_ACCOUNT=$(echo ${CURRENT_ISSUER} | cut -d "/" -f3 | cut -d "." -f1)
+AZURE_STORAGE_CONTAINER=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
+endif::rotate-azure[]
+----
+ifdef::rotate-aws[]
+<1> This value should match the name of the cluster that was specified in the `metadata.name` field of the `install-config.yaml` file during installation.
+endif::rotate-aws[]
++
+[NOTE]
+====
+Your cluster might differ from this example, and the resource names might not be derived identically from the cluster name.
+Ensure that you specify the correct corresponding resource names for your cluster.
+====
+ifdef::rotate-aws[]
+** For {aws-short} clusters that store the OIDC configuration in a public S3 bucket, configure the following environment variable:
++
+[source,text]
+----
+AWS_BUCKET=$(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} | awk -F'://' '{print$2}' |awk -F'.' '{print$1}')
+----
+
+** For {aws-short} clusters that store the OIDC configuration in a private S3 bucket that is accessed by the IAM identity provider through a public CloudFront distribution URL, complete the following steps:
+
+... Extract the public CloudFront distribution URL by running the following command:
++
+[source,terminal]
+----
+$ basename $(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} )
+----
++
+.Example output
+[source,text]
+----
+<subdomain>.cloudfront.net
+----
++
+where `<subdomain>` is an alphanumeric string.
+
+... Determine the private S3 bucket name by running the following command:
++
+[source,terminal]
+----
+$ aws cloudfront list-distributions --query "DistributionList.Items[].{DomainName: DomainName, OriginDomainName: Origins.Items[0].DomainName}[?contains(DomainName, '<subdomain>.cloudfront.net')]"
+----
++
+.Example output
+[source,text]
+----
+[
+    {
+        "DomainName": "<subdomain>.cloudfront.net",
+        "OriginDomainName": "<s3_bucket>.s3.us-east-2.amazonaws.com"
+    }
+]
+----
++
+where `<s3_bucket>` is the private S3 bucket name for your cluster.
+
+... Configure the following environment variable:
++
+[source,text]
+----
+AWS_BUCKET=$<s3_bucket>
+----
++
+where `<s3_bucket>` is the private S3 bucket name for your cluster.
+endif::rotate-aws[]
+
+. Create a temporary directory to use and assign it an environment variable by running the following command:
++
+[source,terminal]
+----
+$ TEMPDIR=$(mktemp -d)
+----
+
+. To cause the Kubernetes API server to create a new bound service account signing key, you delete the next bound service account signing key.
++
+[IMPORTANT]
+====
+After you complete this step, the Kubernetes API server starts to roll out a new key.
+To reduce the risk of authentication failures, complete the remaining steps as quickly as possible.
+The remaining steps might be disruptive to workloads.
+====
++
+When you are ready, delete the next bound service account signing key by running the following command:
++
+[source,terminal]
+----
+$ oc delete secrets/next-bound-service-account-signing-key \
+  -n openshift-kube-apiserver-operator
+----
+
+. Download the public key from the service account signing key secret that the Kubernetes API server created by running the following command:
++
+[source,terminal]
+----
+$ oc get secret/next-bound-service-account-signing-key \
+  -n openshift-kube-apiserver-operator \
+  -ojsonpath='{ .data.service-account\.pub }' | base64 \
+  -d > ${TEMPDIR}/serviceaccount-signer.public
+----
+
+. Use the public key to create a `keys.json` file by running the following command:
+ifdef::rotate-aws[]
++
+[source,terminal]
+----
+$ ccoctl aws create-identity-provider \
+  --dry-run \// <1> 
+  --output-dir ${TEMPDIR} \
+  --name fake \// <2>
+  --region us-east-1 <3>
+----
+<1> The `--dry-run` option outputs files, including the new `keys.json` file, to the disk without making API calls.
+<2> Because the `--dry-run` option does not make any API calls, some parameters do not require real values.
+<3> Specify any valid {aws-short} region, such as `us-east-1`.
+This value does not need to match the region the cluster is in.
+endif::rotate-aws[]
+ifdef::rotate-gcp[]
++
+[source,terminal]
+----
+$ ccoctl gcp create-workload-identity-provider \
+  --dry-run \// <1>
+  --output-dir=${TEMPDIR} \
+  --name fake \// <2>
+  --project fake \
+  --workload-identity-pool fake
+----
+<1> The `--dry-run` option outputs files, including the new `keys.json` file, to the disk without making API calls.
+<2> Because the `--dry-run` option does not make any API calls, some parameters do not require real values.
+endif::rotate-gcp[]
+ifdef::rotate-azure[]
++
+[source,terminal]
+----
+$ ccoctl aws create-identity-provider \// <1>
+  --dry-run \// <2>
+  --output-dir ${TEMPDIR} \
+  --name fake \// <3>
+  --region us-east-1 <4>
+----
+<1> The `ccoctl azure` command does not include a `--dry-run` option.
+To use the `--dry-run` option, you must specify `aws` for an {azure-short} cluster.
+<2> The `--dry-run` option outputs files, including the new `keys.json` file, to the disk without making API calls.
+<3> Because the `--dry-run` option does not make any API calls, some parameters do not require real values.
+<4> Specify any valid {aws-short} region, such as `us-east-1`.
+This value does not need to match the region the cluster is in.
+endif::rotate-azure[]
+
+. Rename the `keys.json` file by running the following command:
++
+[source,terminal]
+----
+$ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json
+----
++
+where `<number>` is a two-digit numerical value that varies depending on your environment.
+
+. Download the existing `keys.json` file from the cloud provider by running the following command:
+ifdef::rotate-aws[]
++
+[source,terminal]
+----
+$ aws s3api get-object \
+  --bucket ${AWS_BUCKET} \
+  --key keys.json ${TEMPDIR}/jwks.current.json
+----
+endif::rotate-aws[]
+ifdef::rotate-gcp[]
++
+[source,terminal]
+----
+$ gcloud storage cp gs://${GCP_BUCKET}/keys.json ${TEMPDIR}/jwks.current.json
+----
+endif::rotate-gcp[]
+ifdef::rotate-azure[]
++
+[source,terminal]
+----
+$ az storage blob download \
+  --container-name ${AZURE_STORAGE_CONTAINER} \
+  --account-name ${AZURE_STORAGE_ACCOUNT} \
+  --name 'openid/v1/jwks' \
+  -f ${TEMPDIR}/jwks.current.json
+----
+endif::rotate-azure[]
+
+. Combine the two `keys.json` files by running the following command:
++
+[source,terminal]
+----
+$ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json
+----
+
+. To enable authentication for the old and new keys during the rotation, upload the combined `keys.json` file to the cloud provider by running the following command:
+ifdef::rotate-aws[]
++
+[source,terminal]
+----
+$ aws s3api put-object \
+  --bucket ${AWS_BUCKET} \
+  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
+  --key keys.json \
+  --body ${TEMPDIR}/jwks.combined.json
+----
+endif::rotate-aws[]
+ifdef::rotate-gcp[]
++
+[source,terminal]
+----
+$ gcloud storage cp ${TEMPDIR}/jwks.combined.json gs://${GCP_BUCKET}/keys.json
+----
+endif::rotate-gcp[]
+ifdef::rotate-azure[]
++
+[source,terminal]
+----
+$ az storage blob upload \
+  --overwrite \
+  --account-name ${AZURE_STORAGE_ACCOUNT} \
+  --container-name ${AZURE_STORAGE_CONTAINER} \
+  --name 'openid/v1/jwks' \
+  -f ${TEMPDIR}/jwks.combined.json
+----
+endif::rotate-azure[]
+
+. Wait for the Kubernetes API server to update and use the new key. 
+You can monitor the update progress by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-stable-cluster
+----
++
+This process might take 15 minutes or longer.
+The following output indicates that the process is complete:
++
+[source,text]
+----
+All clusteroperators are stable
+----
+
+. To ensure that all pods on the cluster use the new key, you must restart them.
++
+[IMPORTANT]
+====
+This step maintains uptime for services that are configured for high availability across multiple nodes, but might cause downtime for any services that are not.
+====
++
+Restart all of the pods in the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc adm reboot-machine-config-pool mcp/worker mcp/master
+----
+
+. Monitor the restart and update process by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-node-reboot nodes --all
+----
++
+This process might take 15 minutes or longer.
+The following output indicates that the process is complete:
++
+[source,text]
+----
+All nodes rebooted
+----
+
+. Monitor the update progress by running the following command:
++
+[source,terminal]
+----
+$ oc adm wait-for-stable-cluster
+----
++
+This process might take 15 minutes or longer.
+The following output indicates that the process is complete:
++
+[source,text]
+----
+All clusteroperators are stable
+----
+
+. Replace the combined `keys.json` file with the updated `keys.json` file on the cloud provider by running the following command:
+ifdef::rotate-aws[]
++
+[source,terminal]
+----
+$ aws s3api put-object \
+  --bucket ${AWS_BUCKET} \
+  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
+  --key keys.json \
+  --body ${TEMPDIR}/jwks.new.json
+----
+endif::rotate-aws[]
+ifdef::rotate-gcp[]
++
+[source,terminal]
+----
+$ gcloud storage cp ${TEMPDIR}/jwks.new.json gs://${GCP_BUCKET}/keys.json
+----
+endif::rotate-gcp[]
+ifdef::rotate-azure[]
++
+[source,terminal]
+----
+$ az storage blob upload \
+  --overwrite \
+  --account-name ${AZURE_STORAGE_ACCOUNT} \
+  --container-name ${AZURE_STORAGE_CONTAINER} \
+  --name 'openid/v1/jwks' \
+  -f ${TEMPDIR}/jwks.new.json
+----
+endif::rotate-azure[]
+
+ifeval::["{context}" == "key-rotation-aws"]
+:!rotate-aws:
+endif::[]
+ifeval::["{context}" == "key-rotation-gcp"]
+:!rotate-gcp:
+endif::[]
+ifeval::["{context}" == "key-rotation-azure"]
+:!rotate-azure:
+endif::[]
\ No newline at end of file
diff --git a/modules/running-cluster-oci-c3-agent-based.adoc b/modules/running-cluster-oci-c3-agent-based.adoc
new file mode 100644
index 000000000000..e3ff8a625aeb
--- /dev/null
+++ b/modules/running-cluster-oci-c3-agent-based.adoc
@@ -0,0 +1,44 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-oci-agent-based-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="running-cluster-oci-c3-agent-based_{context}"]
+= Running a cluster on {oci-c3-short}
+
+To run a cluster on {oci-c3}, you must first convert your generated Agent ISO image into an {oci} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-c3-short} system.
+
+[NOTE]
+====
+{oci-c3-short} supports the following {product-title} cluster topologies:
+
+* Installing an {product-title} cluster on a single node.
+* A highly available cluster that has a minimum of three control plane instances and two compute instances.
+* A compact three-node cluster that has a minimum of three control plane instances.
+====
+
+.Prerequisites
+
+* You generated an Agent ISO image. See the "Creating configuration files for installing a cluster on {oci-c3-short}" section.
+
+.Procedure
+
+. Convert the agent ISO image to an {oci} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-c3-short} system.
+See "Prepare the OpenShift Master Images" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer (Oracle documentation)] for instructions.
+
+. Create control plane instances on {oci-c3-short}.
+See "Create control plane instances on C3 and Master Node LB Backend Sets" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer (Oracle documentation)] for instructions.
+
+. Create a compute instance from the supplied base image for your cluster topology.
+See "Add worker nodes" in link:https://www.oracle.com/a/otn/docs/compute_cloud_at_customer_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Compute
+Cloud@Customer (Oracle documentation)] for instructions.
++
+[IMPORTANT]
+====
+Before you create the compute instance, check that you have enough memory and disk resources for your cluster. Additionally, ensure that at least one compute instance has the same IP address as the address stated under `rendezvousIP` in the `agent-config.yaml` file.
+====
\ No newline at end of file
diff --git a/modules/running-cluster-oci-pca-agent-based.adoc b/modules/running-cluster-oci-pca-agent-based.adoc
new file mode 100644
index 000000000000..80a69dedabe0
--- /dev/null
+++ b/modules/running-cluster-oci-pca-agent-based.adoc
@@ -0,0 +1,41 @@
+// Module included in the following assemblies:
+//
+// * installing/installing_oci/installing-oci-agent-based-installer.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="running-cluster-oci-pca-agent-based_{context}"]
+= Running a cluster on {oci-pca-short}
+
+To run a cluster on {oci-pca}, you must first convert your generated Agent ISO image into an {oci} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-pca-short} system.
+
+[NOTE]
+====
+{oci-pca-short} supports the following {product-title} cluster topologies:
+
+* Installing an {product-title} cluster on a single node.
+* A highly available cluster that has a minimum of three control plane instances and two compute instances.
+* A compact three-node cluster that has a minimum of three control plane instances.
+====
+
+.Prerequisites
+
+* You generated an Agent ISO image. See the "Creating configuration files for installing a cluster on {oci-pca-short}" section.
+
+.Procedure
+
+. Convert the agent ISO image to an {oci} image, upload it to an {oci} Home Region Bucket, and then import the uploaded image to the {oci-pca-short} system.
+See "Prepare the OpenShift Master Images" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance (Oracle documentation)] for instructions.
+
+. Create control plane instances on {oci-pca-short}.
+See "Create control plane instances on PCA and Master Node LB Backend Sets" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance (Oracle documentation)] for instructions.
+
+. Create a compute instance from the supplied base image for your cluster topology.
+See "Add worker nodes" in link:https://www.oracle.com/a/otn/docs/private_cloud_appliance_agent_based_installation.pdf?source=:em:nl:mt::::PCATP[OpenShift Cluster Setup with
+Agent Based Installer on Private Cloud Appliance (Oracle documentation)] for instructions.
++
+[IMPORTANT]
+====
+Before you create the compute instance, check that you have enough memory and disk resources for your cluster. Additionally, ensure that at least one compute instance has the same IP address as the address stated under `rendezvousIP` in the `agent-config.yaml` file.
+====
\ No newline at end of file
diff --git a/modules/running-compliance-scans.adoc b/modules/running-compliance-scans.adoc
index bf7d8156a1ea..54b84f0bf110 100644
--- a/modules/running-compliance-scans.adoc
+++ b/modules/running-compliance-scans.adoc
@@ -13,6 +13,8 @@ You can run a scan using the Center for Internet Security (CIS) profiles. For co
 For all-in-one control plane and worker nodes, the compliance scan runs twice on the worker and control plane nodes. The compliance scan might generate inconsistent scan results. You can avoid inconsistent results by defining only a single role in the `ScanSetting` object.
 ====
 
+For more information about inconsistent scan results, see link:https://access.redhat.com/solutions/6970861[Compliance Operator shows INCONSISTENT scan result with worker node].
+
 .Procedure
 
 .  Inspect the `ScanSetting` object by running the following command:
diff --git a/modules/scale-down-data-plane.adoc b/modules/scale-down-data-plane.adoc
index c2fe6ff55c40..a0a8eb7c3478 100644
--- a/modules/scale-down-data-plane.adoc
+++ b/modules/scale-down-data-plane.adoc
@@ -72,7 +72,8 @@ To allow the node draining process to continue for a certain period of time, you
 +
 [source,terminal]
 ----
-$ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> --replicas=0
+$ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> \
+  --replicas=0
 ----
 +
 [NOTE]
diff --git a/modules/scaling-up-the-3scale-operator-and-deployment.adoc b/modules/scaling-up-the-3scale-operator-and-deployment.adoc
new file mode 100644
index 000000000000..3184fd2be9d3
--- /dev/null
+++ b/modules/scaling-up-the-3scale-operator-and-deployment.adoc
@@ -0,0 +1,60 @@
+:_mod-docs-content-type: PROCEDURE
+
+//included in backing-up-and-restoring-3scale-by-using-oadp.adoc assembly
+
+[id="scaling-up-the-3scale-operator-and-deployment_{context}"]
+= Scaling up the 3scale Operator and deployment
+
+You can scale up the 3scale Operator and any deployment that was manually scaled down. After a few minutes, 3scale installation should be fully functional, and its state should match the backed-up state.
+
+.Prerequisites
+
+* Ensure that there are no scaled up deployments or no extra pods running.
+There might be some `system-mysql` or `backend-redis` pods running detached from deployments after restoration, which can be removed after the restoration is successful.
+
+
+.Procedure
+
+. Scale up the 3scale Operator by running the following command:
++
+[source,terminal]
+----
+$ oc scale deployment threescale-operator-controller-manager-v2 --replicas=1 -n threescale
+----
+
+. Ensure that the 3scale Operator was deployed by running the following command: 
++
+[source,terminal]
+----
+$ oc get deployment -n threescale
+----
+
+. Scale up the deployments by executing the following script:
++
+[source,terminal]
+----
+$ ./scaledeployment.sh
+----
+
+. Get the `3scale-admin` route to log in to the 3scale UI by running the following command:
++
+[source,terminal]
+----
+$ oc get routes -n threescale
+----
++
+.Example output
+[source,terminal]
+----
+NAME                         HOST/PORT                                                                   PATH   SERVICES             PORT      TERMINATION     WILDCARD
+backend                      backend-3scale.apps.custom-cluster-name.openshift.com                         backend-listener     http      edge/Allow      None
+zync-3scale-api-b4l4d        api-3scale-apicast-production.apps.custom-cluster-name.openshift.com          apicast-production   gateway   edge/Redirect   None
+zync-3scale-api-b6sns        api-3scale-apicast-staging.apps.custom-cluster-name.openshift.com             apicast-staging      gateway   edge/Redirect   None
+zync-3scale-master-7sc4j     master.apps.custom-cluster-name.openshift.com                                 system-master        http      edge/Redirect   None
+zync-3scale-provider-7r2nm   3scale-admin.apps.custom-cluster-name.openshift.com                           system-provider      http      edge/Redirect   None
+zync-3scale-provider-mjxlb   3scale.apps.custom-cluster-name.openshift.com                                 system-developer     http      edge/Redirect   None
+----
++
+In this example, `3scale-admin.apps.custom-cluster-name.openshift.com` is the 3scale-admin URL.
+
+. Use the URL from this output to log in to the 3scale Operator as an administrator. You can verify that the existing data is available before trying to create a backup.
\ No newline at end of file
diff --git a/modules/sd-hcp-planning-cluster-maximums.adoc b/modules/sd-hcp-planning-cluster-maximums.adoc
index b8fd076b159e..f7483d71d41b 100644
--- a/modules/sd-hcp-planning-cluster-maximums.adoc
+++ b/modules/sd-hcp-planning-cluster-maximums.adoc
@@ -10,10 +10,6 @@ Consider the following tested object maximums when you plan a {hcp-title-first}
 
 These guidelines are based on a cluster of 500 compute (also known as worker) nodes. For smaller clusters, the maximums are lower.
 
-[NOTE]
-====
-Customers running {hcp-title} 4.14.x and 4.15.x clusters require a minimum z-stream version of 4.14.28 or 4.15.15 and greater to scale to 500 worker nodes. For earlier versions, the maximum is 90 worker nodes. 
-====
 
 .Tested cluster maximums
 [options="header",cols="50,50"]
diff --git a/modules/sd-nodes-cma-autoscaling-custom-install.adoc b/modules/sd-nodes-cma-autoscaling-custom-install.adoc
index 6dca94939639..21ffb13799c1 100644
--- a/modules/sd-nodes-cma-autoscaling-custom-install.adoc
+++ b/modules/sd-nodes-cma-autoscaling-custom-install.adoc
@@ -140,7 +140,7 @@ spec:
 <2> Specifies the level of verbosity for the Custom Metrics Autoscaler Operator log messages. The allowed values are `debug`, `info`, `error`. The default is `info`.
 <3> Specifies the logging format for the Custom Metrics Autoscaler Operator log messages. The allowed values are `console` or `json`. The default is `console`.
 <4> Optional: Specifies one or more config maps with CA certificates, which the Custom Metrics Autoscaler Operator can use to connect securely to TLS-enabled metrics sources.
-<5> Specifies the logging level for the Custom Metrics Autoscaler Metrics Server. The allowed values are `0` for `info` and `4` or `debug`. The default is `0`.
+<5> Specifies the logging level for the Custom Metrics Autoscaler Metrics Server. The allowed values are `0` for `info` and `4` for `debug`. The default is `0`.
 <6> Activates audit logging for the Custom Metrics Autoscaler Operator and specifies the audit policy to use, as described in the "Configuring audit logging" section.
 
 .. Click *Create* to create the KEDA controller.
diff --git a/modules/sd-planning-cluster-maximums.adoc b/modules/sd-planning-cluster-maximums.adoc
index 1a240d4d492b..f8734f6c7e79 100644
--- a/modules/sd-planning-cluster-maximums.adoc
+++ b/modules/sd-planning-cluster-maximums.adoc
@@ -19,7 +19,7 @@ ifdef::openshift-dedicated[]
 endif::[]
 cluster.
 
-These guidelines are based on a cluster of 180 compute (also known as worker) nodes in a multiple availability zone configuration. For smaller clusters, the maximums are lower.
+These guidelines are based on a cluster of 249 compute (also known as worker) nodes in a multiple availability zone configuration. For smaller clusters, the maximums are lower.
 
 
 .Tested cluster maximums
diff --git a/modules/sd-planning-considerations.adoc b/modules/sd-planning-considerations.adoc
index 5303bec532f6..3d46ab47b1e3 100644
--- a/modules/sd-planning-considerations.adoc
+++ b/modules/sd-planning-considerations.adoc
@@ -43,7 +43,7 @@ endif::[]
 |m5.4xlarge
 |r5.2xlarge
 
-|101 to 180
+|101 to 249
 |m5.8xlarge
 |r5.4xlarge
 |===
@@ -65,7 +65,7 @@ GCP control plane and infrastructure node size:
 |custom-16-65536
 |custom-8-65536-ext
 
-|101 to 180
+|101 to 249
 |custom-32-131072
 |custom-16-131072-ext
 |===
@@ -85,7 +85,7 @@ GCP control plane and infrastructure node size for clusters created on or after
 |n2-standard-16
 |n2-highmem-8
 
-|101 to 180
+|101 to 249
 |n2-standard-32
 |n2-highmem-16
 |===
@@ -101,7 +101,7 @@ endif::[]
 ifdef::openshift-dedicated[]
 {product-title}
 endif::[]
-is 180.
+clusters version 4.14.14 and later is 249. For earlier versions, the limit is 180.
 ====
 
 [id="node-scaling-after-installation_{context}"]
@@ -145,7 +145,7 @@ endif::[]
 ifdef::openshift-dedicated[]
 {product-title}
 endif::[]
-is 180.
+cluster versions 4.14.14 and later is 249. For earlier versions, the limit is 180.
 
 The resizing alerts only appear after sustained periods of high utilization. Short usage spikes, such as a node temporarily going down causing the other node to scale up, do not trigger these alerts.
 ====
diff --git a/modules/sd-understanding-process-id-limits.adoc b/modules/sd-understanding-process-id-limits.adoc
index 7ba8bfad5458..fb7a706b107e 100644
--- a/modules/sd-understanding-process-id-limits.adoc
+++ b/modules/sd-understanding-process-id-limits.adoc
@@ -6,15 +6,45 @@
 [id="understanding-process-id-limits_{context}"]
 = Understanding process ID limits
 
+ifdef::openshift-enterprise,openshift-origin[]
+A process identifier (PID) is a unique identifier assigned by the Linux kernel to each process or thread currently running on a system. The number of processes that can run simultaneously on a system is limited to 4,194,304 by the Linux kernel. This number might also be affected by limited access to other system resources such as memory, CPU, and disk space.
+endif::openshift-enterprise,openshift-origin[]
+
 In {product-title}, consider these two supported limits for process ID (PID) usage before you schedule work on your cluster:
 
 * Maximum number of PIDs per pod.
 +
 The default value is 4,096 in {product-title} 4.11 and later. This value is controlled by the `podPidsLimit` parameter set on the node.
+ifdef::openshift-enterprise,openshift-origin[]
++
+You can view the current PID limit on a node by running the following command in a `chroot` environment:
++
+[source,terminal]
+----
+sh-5.1# cat /etc/kubernetes/kubelet.conf | grep -i pids
+----
++
+.Example output
+[source,terminal]
+----
+"podPidsLimit": 4096,
+----
++
+You can change the `podPidsLimit` by using a `KubeletConfig` object. See "Creating a KubeletConfig CR to edit kubelet parameters".
++
+Containers inherit the `podPidsLimit` value from the parent pod, so the kernel enforces the lower of the two limits. For example, if the container PID limit is set to the maximum, but the pod PID limit is `4096`, the PID limit of each container in the pod is confined to 4096.
+endif::openshift-enterprise,openshift-origin[]
 
+ifdef::openshift-enterprise,openshift-origin[]
+* Maximum number of PIDs per node.
++
+The default value depends on node resources. In {product-title}, this value is controlled by the `systemReserved` parameter in a kubelet configuration, which reserves PIDs on each node based on the total resources of the node. For more information, see "Allocating resources for nodes in an {product-title} cluster".
+endif::openshift-enterprise,openshift-origin[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Maximum number of PIDs per node.
 +
-The default value depends on link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/nodes/index#nodes-nodes-resources-configuring[node resources]. In {product-title}, this value is controlled by the link:https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved[`--system-reserved`] parameter, which reserves PIDs on each node based on the total resources of the node.
+The default value depends on link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/nodes/index#nodes-nodes-resources-configuring[node resources]. In {product-title}, this value is controlled by the link:https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved[`--system-reserved`] parameter, which reserves PIDs on each node based on the total resources of the node.
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 When a pod exceeds the allowed maximum number of PIDs per pod, the pod might stop functioning correctly and might be evicted from the node. See link:https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/#eviction-signals-and-thresholds[the Kubernetes documentation for eviction signals and thresholds] for more information.
 
diff --git a/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc b/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc
index e84fce02401d..cf51395645d0 100644
--- a/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc
+++ b/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc
@@ -3,7 +3,7 @@
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 :_mod-docs-content-type: CONCEPT
 [id="aws-instance-types-non-ccs_{context}"]
-= AWS instance types for standard clusters
+= AWS instance types for non-CCS clusters
 
 {product-title} offers the following worker node types and sizes on AWS:
 
diff --git a/modules/sdpolicy-am-billing.adoc b/modules/sdpolicy-am-billing.adoc
index a389722c3965..518bc05823ee 100644
--- a/modules/sdpolicy-am-billing.adoc
+++ b/modules/sdpolicy-am-billing.adoc
@@ -39,10 +39,10 @@ Cloud provider for consumption of cloud infrastructure
 Customers that use their own cloud infrastructure account, referred to as Customer Cloud Subscription (CSS), are responsible to pre-purchase or provide Reserved Instance (RI) compute instances to ensure lower cloud infrastructure costs.
 ====
 
-Additional resources can be purchased for an OpenShift Dedicated Cluster, including:
+Additional resources can be purchased for an OpenShift Dedicated cluster, including:
 
 * Additional nodes (can be different types and sizes through the use of machine pools)
 * Middleware (JBoss EAP, JBoss Fuse, and so on) - additional pricing based on specific middleware component
-* Additional storage in increments of 500 GB (standard only; 100 GB included)
-* Additional 12 TiB Network I/O (standard only; 12 TB included)
-* Load Balancers for Services are available in bundles of 4; enables non-HTTP/SNI traffic or non-standard ports (standard only)
\ No newline at end of file
+* Additional storage in increments of 500 GB (non-CCS only; 100 GB included)
+* Additional 12 TiB Network I/O (non-CCS only; 12 TB included)
+* Load Balancers for Services are available in bundles of 4; enables non-HTTP/SNI traffic or non-standard ports (non-CCS only)
\ No newline at end of file
diff --git a/modules/sdpolicy-am-compute.adoc b/modules/sdpolicy-am-compute.adoc
index 26715f5a8f2d..49c01011dd33 100644
--- a/modules/sdpolicy-am-compute.adoc
+++ b/modules/sdpolicy-am-compute.adoc
@@ -5,16 +5,22 @@
 [id="instance-types_{context}"]
 = Instance types
 
-Single availability zone clusters require a minimum of 2 worker nodes for Customer Cloud Subscription (CCS) clusters deployed to a single availability zone. A minimum of 4 worker nodes is required for standard clusters. These 4 worker nodes are included in the base subscription.
+Single availability zone clusters require a minimum of 2 worker nodes for Customer Cloud Subscription (CCS) clusters deployed to a single availability zone. A minimum of 4 worker nodes is required for non-CCS clusters. These 4 worker nodes are included in the base subscription.
 
-Multiple availability zone clusters require a minimum of 3 worker nodes for Customer Cloud Subscription (CCS) clusters, 1 deployed to each of 3 availability zones. A minimum of 9 worker nodes are required for standard clusters. These 9 worker nodes are included in the base subscription, and additional nodes must be purchased in multiples of 3 to maintain proper node distribution.
+Multiple availability zone clusters require a minimum of 3 worker nodes for Customer Cloud Subscription (CCS) clusters, 1 deployed to each of 3 availability zones. A minimum of 9 worker nodes are required for non-CCS clusters. These 9 worker nodes are included in the base subscription, and additional nodes must be purchased in multiples of 3 to maintain proper node distribution.
 
 [NOTE]
 ====
 All worker nodes within a single {product-title} machine pool must be of the same type and size. However, worker nodes across multiple machine pools within an {product-title} cluster can be of different types and sizes.
 ====
 
-Control plane and infrastructure nodes are also provided by Red Hat. There are at least 3 control plane nodes that handle etcd and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control plane and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes. See the Red Hat Operator support section below for more information about Red Hat workloads that must be deployed on worker nodes.
+Control plane and infrastructure nodes are deployed and managed by Red{nbsp}Hat. There are at least 3 control plane nodes that handle etcd and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control plane and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes.
+[IMPORTANT]
+====
+Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss.
+====
+
+For more information about Red{nbsp}Hat workloads that must be deployed on worker nodes, see the _Red{nbsp}Hat Operator support_ section below.
 
 [NOTE]
 ====
diff --git a/modules/sdpolicy-am-gcp-compute-types.adoc b/modules/sdpolicy-am-gcp-compute-types.adoc
index 047ec8b0b474..45b358e2a1dd 100644
--- a/modules/sdpolicy-am-gcp-compute-types.adoc
+++ b/modules/sdpolicy-am-gcp-compute-types.adoc
@@ -3,12 +3,12 @@
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 :_mod-docs-content-type: CONCEPT
 [id="gcp-compute-types_{context}"]
-= Google Cloud compute types
+= Google Cloud instance types
 
 {product-title} offers the following worker node types and sizes on Google Cloud that are chosen to have a common CPU and memory capacity that are the same as other cloud instance types:
 [NOTE]
 ====
-`e2`, `a2`, and `a3` compute types are available for CCS only.
+`e2`, `a2`, and `a3` instance types are available for CCS only.
 ====
 
 .General purpose
diff --git a/modules/sdpolicy-networking.adoc b/modules/sdpolicy-networking.adoc
index df158e06adfb..618c3ff60ef6 100644
--- a/modules/sdpolicy-networking.adoc
+++ b/modules/sdpolicy-networking.adoc
@@ -32,15 +32,15 @@ Custom domains and subdomains are not available for the platform service routes,
 {product-title} uses up to 5 different load balancers:
 
 * Internal control plane load balancer that is internal to the cluster and used to balance traffic for internal cluster communications.
-* External control plane load balancer that is used for accessing the {OCP} and Kubernetes APIs. This load balancer can be disabled in {cluster-manager-first}. If this load balancer is disabled, Red Hat reconfigures the API DNS to point to the internal control load balancer.
-* External control plane load balancer for Red Hat that is reserved for cluster management by Red Hat. Access is strictly controlled, and communication is only possible from allowlisted bastion hosts.
+* External control plane load balancer that is used for accessing the {OCP} and Kubernetes APIs. This load balancer can be disabled in {cluster-manager-first}. If this load balancer is disabled, Red{nbsp}Hat reconfigures the API DNS to point to the internal control load balancer.
+* External control plane load balancer for Red{nbsp}Hat that is reserved for cluster management by Red{nbsp}Hat. Access is strictly controlled, and communication is only possible from allowlisted bastion hosts.
 * Default router/ingress load balancer that is the default application load balancer, denoted by `apps` in the URL. The default load balancer can be configured in {cluster-manager} to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. All application routes on the cluster are exposed on this default router load balancer, including cluster services such as the logging UI, metrics API, and registry.
 * Optional: Secondary router/ingress load balancer that is a secondary application load balancer, denoted by `apps2` in the URL. The secondary load balancer can be configured in {cluster-manager} to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. If a 'Label match' is configured for this router load balancer, then only application routes matching this label will be exposed on this router load balancer, otherwise all application routes are also exposed on this router load balancer.
-* Optional: Load balancers for services that can be mapped to a service running on {product-title} to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. These can be purchased in groups of 4 for standard clusters, or they can be provisioned without charge in Customer Cloud Subscription (CCS) clusters; however, each AWS account has a quota that link:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-limits.html[limits the number of Classic Load Balancers] that can be used within each cluster.
+* Optional: Load balancers for services that can be mapped to a service running on {product-title} to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. These can be purchased in groups of 4 for non-CCS clusters, or they can be provisioned through the cloud provider console in Customer Cloud Subscription (CCS) clusters; however, each AWS account has a quota that link:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-limits.html[limits the number of Classic Load Balancers] that can be used within each cluster.
 
 [id="network-usage{context}"]
 == Network usage
-For standard {product-title} clusters, network usage is measured based on data transfer between inbound, VPC peering, VPN, and AZ traffic. On a standard {product-title} base cluster, 12 TB of network I/O is provided. Additional network I/O can be purchased in 12 TB increments. For CCS {product-title} clusters, network usage is not monitored, and is billed directly by the cloud provider.
+For non-CCS {product-title} clusters, network usage is measured based on data transfer between inbound, VPC peering, VPN, and AZ traffic. On a non-CCS {product-title} base cluster, 12 TB of network I/O is provided. Additional network I/O can be purchased in 12 TB increments. For CCS {product-title} clusters, network usage is not monitored, and is billed directly by the cloud provider.
 
 [id="cluster-ingress_{context}"]
 == Cluster ingress
@@ -79,7 +79,7 @@ $ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bi
 
 [IMPORTANT]
 ====
-Red Hat SREs do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
+Red{nbsp}Hat SREs do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
 ====
 
 [id="dns-forwarding_{context}"]
diff --git a/modules/sdpolicy-storage.adoc b/modules/sdpolicy-storage.adoc
index 08ac384ffdd8..0f8d620ca13b 100644
--- a/modules/sdpolicy-storage.adoc
+++ b/modules/sdpolicy-storage.adoc
@@ -16,7 +16,7 @@ EBS volumes used for persistent volumes (PVs) are encrypted-at-rest by default.
 
 [id="block-storage_{context}"]
 == Block storage (RWO)
-Persistent volumes (PVs) are backed by AWS EBS and Google Cloud persistent disk block storage, which uses the ReadWriteOnce (RWO) access mode. On a standard {product-title} base cluster, 100 GB of block storage is provided for PVs, which is dynamically provisioned and recycled based on application requests. Additional persistent storage can be purchased in 500 GB increments.
+Persistent volumes (PVs) are backed by AWS EBS and Google Cloud persistent disk block storage, which uses the ReadWriteOnce (RWO) access mode. On a non-CCS {product-title} base cluster, 100 GB of block storage is provided for PVs, which is dynamically provisioned and recycled based on application requests. Additional persistent storage can be purchased in 500 GB increments.
 
 PVs can only be attached to a single node at a time and are specific to the availability zone in which they were provisioned, but they can be attached to any node in the availability zone.
 
@@ -25,4 +25,4 @@ Each cloud provider has its own limits for how many PVs can be attached to a sin
 [id="shared-storage_{context}"]
 == Shared storage (RWX)
 
-The AWS CSI Driver can be used to provide RWX support for {product-title} on AWS. A community Operator is provided to simplify setup. See link:https://access.redhat.com/articles/5025181[AWS EFS Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS] for details. 
+The AWS CSI Driver can be used to provide RWX support for {product-title} on AWS. A community Operator is provided to simplify setup. For more information, see link:https://access.redhat.com/articles/5025181[AWS EFS Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS].
diff --git a/modules/secrets-store-vault.adoc b/modules/secrets-store-vault.adoc
index 161f01fa8b41..01dc81b591c8 100644
--- a/modules/secrets-store-vault.adoc
+++ b/modules/secrets-store-vault.adoc
@@ -174,7 +174,7 @@ $ TOKEN_REVIEWER_JWT="$(oc exec vault-0 --namespace=vault -- cat /var/run/secret
 +
 [source,terminal]
 ----
-$ KUBERNETES_SERVICE_IP="$(oc get svc kubernetes -o go-template="{{ .spec.clusterIP }}")"
+$ KUBERNETES_SERVICE_IP="$(oc get svc kubernetes --namespace=default -o go-template="{{ .spec.clusterIP }}")"
 ----
 
 ... Update the Kubernetes auth method by running the following command:
diff --git a/modules/security-context-constraints-about.adoc b/modules/security-context-constraints-about.adoc
index 2311ec3fc47d..39156d92ae01 100644
--- a/modules/security-context-constraints-about.adoc
+++ b/modules/security-context-constraints-about.adoc
@@ -36,14 +36,14 @@ The cluster contains several default security context constraints (SCCs) as desc
 [IMPORTANT]
 ====
 Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 {product-title}
 endif::[]
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 ROSA
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
-ifdef::openshift-origin,openshift-enterprise,openshift-webscale,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-webscale,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see _Creating security context constraints_.
 endif::[]
diff --git a/modules/security-context-constraints-pre-allocated-values.adoc b/modules/security-context-constraints-pre-allocated-values.adoc
index 835cbf7a73b0..f28d304ee5c3 100644
--- a/modules/security-context-constraints-pre-allocated-values.adoc
+++ b/modules/security-context-constraints-pre-allocated-values.adoc
@@ -3,7 +3,7 @@
 // * authentication/managing-security-context-constraints.adoc
 
 :_mod-docs-content-type: CONCEPT
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [id="security-context-constraints-pre-allocated-values_{context}"]
 = About pre-allocated security context constraints values
 
diff --git a/modules/security-context-constraints-psa-opting.adoc b/modules/security-context-constraints-psa-opting.adoc
index 0f8c938f4c7c..3a91040985ca 100644
--- a/modules/security-context-constraints-psa-opting.adoc
+++ b/modules/security-context-constraints-psa-opting.adoc
@@ -11,9 +11,9 @@ You can enable or disable automatic pod security admission synchronization for m
 [IMPORTANT]
 ====
 You cannot enable pod security admission synchronization on
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 some
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 system-created namespaces. For more information, see _Pod security admission synchronization namespace exclusions_.
 ====
 
diff --git a/modules/security-hardening-what.adoc b/modules/security-hardening-what.adoc
index a330901f7035..31af3c6d0c97 100644
--- a/modules/security-hardening-what.adoc
+++ b/modules/security-hardening-what.adoc
@@ -6,13 +6,15 @@
 
 = Choosing what to harden in {op-system}
 ifdef::openshift-origin[]
-The link:https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/chap-Security_Guide-Basic_Hardening.html[{op-system-base} Security Hardening] guide describes how you should approach security for any {op-system-base} system.
+For information on how to approach security for any {op-system-base} system, see the link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9#Security[Security] category in the Red{nbsp}Hat Enterprise Linux 9 documentation.
+
+Use these documents to learn about managing security updates, security hardening, securing networks, and other security measures.  
 endif::[]
 ifdef::openshift-enterprise,openshift-webscale,openshift-aro[]
-The link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#scanning-container-and-container-images-for-vulnerabilities_scanning-the-system-for-security-compliance-and-vulnerabilities[{op-system-base} 9 Security Hardening] guide describes how you should approach security for any {op-system-base} system.
-endif::[]
+For information on how to approach security for any {op-system-base} system, see the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#scanning-container-and-container-images-for-vulnerabilities_scanning-the-system-for-security-compliance-and-vulnerabilities[{op-system-base} 9 Security Hardening] guide.
 
 Use this guide to learn how to approach cryptography, evaluate vulnerabilities, and assess threats to various services.
 Likewise, you can learn how to scan for compliance standards, check file integrity, perform auditing, and encrypt storage devices.
+endif::[]
 
 With the knowledge of what features you want to harden, you can then decide how to harden them in {op-system}.
diff --git a/modules/security-pod-scan-cso.adoc b/modules/security-pod-scan-cso.adoc
index c8b6f0450982..4dfff68023ea 100644
--- a/modules/security-pod-scan-cso.adoc
+++ b/modules/security-pod-scan-cso.adoc
@@ -44,7 +44,7 @@ $ oc create secret generic container-security-operator-extra-certs --from-file=q
 $ oc get packagemanifests container-security-operator \
   -o jsonpath='{range .status.channels[*]}{@.currentCSV} {@.name}{"\n"}{end}' \
   | awk '{print "STARTING_CSV=" $1 " CHANNEL=" $2 }' \
-  | sort -nr \
+  | sort -Vr \
   | head -1
 ----
 +
@@ -87,4 +87,4 @@ $ oc apply -f container-security-operator.yaml
 [source,terminal]
 ----
 subscription.operators.coreos.com/container-security-operator created
-----
\ No newline at end of file
+----
diff --git a/modules/serverless-quarkus-template.adoc b/modules/serverless-quarkus-template.adoc
index 7a263fdc169f..464fdf23d189 100644
--- a/modules/serverless-quarkus-template.adoc
+++ b/modules/serverless-quarkus-template.adoc
@@ -45,7 +45,7 @@ Both `http` and `event` trigger functions have the same template structure:
     <dependency>
       <groupId>junit</groupId>
       <artifactId>junit</artifactId>
-      <version>4.17</version>
+      <version>4.18</version>
       <scope>test</scope>
     </dependency>
     <dependency>
diff --git a/modules/service-accounts-creating.adoc b/modules/service-accounts-creating.adoc
index 78bdd4833421..1777bd46c5a0 100644
--- a/modules/service-accounts-creating.adoc
+++ b/modules/service-accounts-creating.adoc
@@ -22,9 +22,9 @@ $ oc get sa
 [source,terminal]
 ----
 NAME       SECRETS   AGE
-builder    2         2d
-default    2         2d
-deployer   2         2d
+builder    1         2d
+default    1         2d
+deployer   1         2d
 ----
 
 . To create a new service account in the current project:
@@ -67,10 +67,10 @@ $ oc describe sa robot
 ----
 Name:                robot
 Namespace:           project1
-Labels:	             <none>
-Annotations:	     <none>
+Labels:              <none>
+Annotations:         openshift.io/internal-registry-pull-secret-ref: robot-dockercfg-qzbhb
 Image pull secrets:  robot-dockercfg-qzbhb
 Mountable secrets:   robot-dockercfg-qzbhb
-Tokens:              robot-token-f4khf
+Tokens:              <none>
 Events:              <none>
 ----
diff --git a/modules/service-accounts-granting-roles.adoc b/modules/service-accounts-granting-roles.adoc
index be123ea2213b..bcab0ad027c5 100644
--- a/modules/service-accounts-granting-roles.adoc
+++ b/modules/service-accounts-granting-roles.adoc
@@ -3,7 +3,7 @@
 // * authentication/using-service-accounts.adoc
 
 [id="service-accounts-granting-roles_{context}"]
-= Examples of granting roles to service accounts
+= Granting roles to service accounts
 
 You can grant roles to service accounts in the same way that you grant roles
 to a regular user account.
diff --git a/modules/service-accounts-overview.adoc b/modules/service-accounts-overview.adoc
index 3c330053edcc..c029e7a21a0c 100644
--- a/modules/service-accounts-overview.adoc
+++ b/modules/service-accounts-overview.adoc
@@ -15,11 +15,12 @@ When you use the {product-title} CLI or web console, your API token
 authenticates you to the API. You can associate a component with a service account
 so that they can access the API without using a regular user's credentials.
 ifdef::openshift-online,openshift-origin,openshift-enterprise,openshift-webscale[]
+
 For example, service accounts can allow:
 
-* Replication controllers to make API calls to create or delete pods.
-* Applications inside containers to make API calls for discovery purposes.
-* External applications to make API calls for monitoring or integration purposes.
+* Replication controllers to make API calls to create or delete pods
+* Applications inside containers to make API calls for discovery purposes
+* External applications to make API calls for monitoring or integration purposes
 endif::[]
 
 Each service account's user name is derived from its project and name:
@@ -45,12 +46,3 @@ Every service account is also a member of two groups:
 specified project.
 
 |===
-
-Each service account automatically contains two secrets:
-
-* An API token
-* Credentials for the OpenShift Container Registry
-
-The generated API token and registry credentials do not expire, but you can
-revoke them by deleting the secret. When you delete the secret, a new one is
-automatically generated to take its place.
diff --git a/modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc b/modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc
index d33a53ca5319..6c675473c2dc 100644
--- a/modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc
+++ b/modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc
@@ -67,8 +67,8 @@ New `99-worker-generated-containerruntime` and `rendered-worker-xyz` objects are
 .Example output
 [source,terminal]
 ----
-99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
-rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s
+99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.4.0             7m42s
+rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.4.0             7m36s
 ----
 
 . After those objects are created, monitor the machine config pool for the changes to be applied:
diff --git a/modules/sre-cluster-access.adoc b/modules/sre-cluster-access.adoc
index 7e354b9ba040..af33ee9683c0 100644
--- a/modules/sre-cluster-access.adoc
+++ b/modules/sre-cluster-access.adoc
@@ -82,7 +82,7 @@ When SREs are on a VPN through two-factor authentication, they and Red Hat Suppo
 
 All activities performed by SREs arrive from Red Hat IP addresses and are logged to CloudTrail to allow you to audit and review all activity. This role is only used in cases where access to AWS services is required to assist you. The majority of permissions are read-only. However, a select few permissions have more access, including the ability to reboot an instance or spin up a new instance. SRE access is limited to the policy permissions attached to the `ManagedOpenShift-Support-Role`.
 
-For a full list of permissions, see sts_support_permission_policy.json in the link:https://docs.openshift.com/rosa/rosa_architecture/rosa-sts-about-iam-resources.html[About IAM resources for ROSA clusters that use STS] user guide.
+For a full list of permissions, see `sts_support_permission_policy.json` in the link:https://docs.openshift.com/rosa/rosa_architecture/rosa-sts-about-iam-resources.html[About IAM resources] user guide.
 
 [id="rosa-sre-access-privatelink-vpc.adoc_{context}"]
 == SRE access through PrivateLink VPC endpoint service
diff --git a/modules/ssh-agent-using.adoc b/modules/ssh-agent-using.adoc
index ae4096e81d77..65f8663f6434 100644
--- a/modules/ssh-agent-using.adoc
+++ b/modules/ssh-agent-using.adoc
@@ -128,9 +128,7 @@ Do not skip this procedure in production environments, where disaster recovery a
 ifndef::osp,ibm-z[]
 [NOTE]
 ====
-You must use a local key, not one that you configured with platform-specific
-approaches such as
-link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html[AWS key pairs].
+You must use a local key, not one that you configured with platform-specific approaches.
 ====
 endif::[]
 
diff --git a/modules/starting-debug-pods-with-root-access.adoc b/modules/starting-debug-pods-with-root-access.adoc
index c5a35ce6df37..64e82118b777 100644
--- a/modules/starting-debug-pods-with-root-access.adoc
+++ b/modules/starting-debug-pods-with-root-access.adoc
@@ -10,12 +10,12 @@ You can start a debug pod with root access, based on a problematic pod's deploym
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Your API service is still functional.
 * You have installed the OpenShift CLI (`oc`).
 
diff --git a/modules/summarizing-cluster-specifications-through-clusterversion.adoc b/modules/summarizing-cluster-specifications-through-clusterversion.adoc
index b8ff5c188201..80a3e1fdcdf2 100644
--- a/modules/summarizing-cluster-specifications-through-clusterversion.adoc
+++ b/modules/summarizing-cluster-specifications-through-clusterversion.adoc
@@ -10,12 +10,12 @@ You can obtain a summary of {product-title} cluster specifications by querying t
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
 
 .Procedure
diff --git a/modules/support-collecting-host-network-trace.adoc b/modules/support-collecting-host-network-trace.adoc
index c2091326f082..fceaa747f7ff 100644
--- a/modules/support-collecting-host-network-trace.adoc
+++ b/modules/support-collecting-host-network-trace.adoc
@@ -49,14 +49,14 @@ ifndef::openshift-origin[]
 [source,terminal]
 ----
 $ oc adm must-gather \
-    --dest-dir /tmp/captures \  <.>
-    --source-dir '/tmp/tcpdump/' \  <.>
-    --image registry.redhat.io/openshift4/network-tools-rhel8:latest \  <.>
-    --node-selector 'node-role.kubernetes.io/worker' \  <.>
-    --host-network=true \  <.>
-    --timeout 30s \  <.>
+    --dest-dir /tmp/captures \// <.>
+    --source-dir '/tmp/tcpdump/' \// <.>
+    --image registry.redhat.io/openshift4/network-tools-rhel8:latest \// <.>
+    --node-selector 'node-role.kubernetes.io/worker' \// <.>
+    --host-network=true \// <.>
+    --timeout 30s \// <.>
     -- \
-    tcpdump -i any \  <.>
+    tcpdump -i any \// <.>
     -w /tmp/tcpdump/%Y-%m-%dT%H:%M:%S.pcap -W 1 -G 300
 ----
 <.> The `--dest-dir` argument specifies that `oc adm must-gather` stores the packet captures in directories that are relative to `/tmp/captures` on the client machine. You can specify any writable directory.
diff --git a/modules/support-collecting-network-trace.adoc b/modules/support-collecting-network-trace.adoc
index c94c7ee97cfc..884ea2856fe5 100644
--- a/modules/support-collecting-network-trace.adoc
+++ b/modules/support-collecting-network-trace.adoc
@@ -21,11 +21,11 @@ endif::openshift-dedicated[]
 +
 * You have installed the OpenShift CLI (`oc`).
 * You have an existing Red Hat Support case ID.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have a Red Hat standard or premium Subscription.
 * You have a Red Hat Customer Portal account.
 * You have SSH access to your hosts.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -49,14 +49,14 @@ $ oc debug node/my-cluster-node
 ----
 # chroot /host
 ----
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
-ifndef::openshift-rosa,openshift-dedicated[]
 [NOTE]
 ====
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes by using SSH is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>` instead.
 ====
-+
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
 . From within the `chroot` environment console, obtain the node's interface names:
 +
 [source,terminal]
@@ -75,7 +75,7 @@ endif::openshift-rosa,openshift-dedicated[]
 ====
 If an existing `toolbox` pod is already running, the `toolbox` command outputs `'toolbox-' already exists. Trying to start...`. To avoid `tcpdump` issues, remove the running toolbox container with `podman rm toolbox-` and spawn a new toolbox container.
 ====
-+
+
 . Initiate a `tcpdump` session on the cluster node and redirect output to a capture file. This example uses `ens5` as the interface name:
 +
 [source,terminal]
@@ -109,16 +109,8 @@ $ tcpdump -nn -s 0 -i ens5 -w /host/var/tmp/my-cluster-node_$(date +%d_%m_%Y-%H_
 
 . Provide the `tcpdump` capture file to Red Hat Support for analysis, using one of the following methods.
 +
-* Upload the file to an existing Red Hat support case directly from an {product-title} cluster.
-.. From within the toolbox container, run `redhat-support-tool` to attach the file directly to an existing Red Hat Support case. This example uses support case ID `01234567`:
-+
-[source,terminal]
-----
-# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-tcpdump-capture-file.pcap <1>
-----
-<1> The toolbox container mounts the host's root directory at `/host`. Reference the absolute path from the toolbox container's root directory, including `/host/`, when specifying files to upload through the `redhat-support-tool` command.
-+
 * Upload the file to an existing Red Hat support case.
+
 .. Concatenate the `sosreport` archive by running the `oc debug node/<node_name>` command and redirect the output to a file. This command assumes you have exited the previous `oc debug` session:
 +
 [source,terminal]
@@ -126,16 +118,16 @@ $ tcpdump -nn -s 0 -i ens5 -w /host/var/tmp/my-cluster-node_$(date +%d_%m_%Y-%H_
 $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-tcpdump-capture-file.pcap' > /tmp/my-tcpdump-capture-file.pcap <1>
 ----
 <1> The debug container mounts the host's root directory at `/host`. Reference the absolute path from the debug container's root directory, including `/host`, when specifying target files for concatenation.
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
-ifndef::openshift-rosa,openshift-dedicated[]
 [NOTE]
 ====
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Transferring a `tcpdump` capture file from a cluster node by using `scp` is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to copy a `tcpdump` capture file from a node by running `scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>`.
 ====
-+
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
 .. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
-+
+
 .. Select *Attach files* and follow the prompts to upload the file.
 
 // TODO - Add details relating to https://github.com/openshift/must-gather/pull/156 within the procedure.
diff --git a/modules/support-gather-data.adoc b/modules/support-gather-data.adoc
index 3d0f395e201f..055891d38631 100644
--- a/modules/support-gather-data.adoc
+++ b/modules/support-gather-data.adoc
@@ -8,6 +8,10 @@
 
 You can gather debugging information about your cluster by using the `oc adm must-gather` CLI command.
 
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+If you are gathering information to debug a self-managed hosted cluster, see "Gathering information to troubleshoot {hcp}".
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` role.
diff --git a/modules/support-generating-a-sosreport-archive.adoc b/modules/support-generating-a-sosreport-archive.adoc
index 9e72f97ada18..bbeefe934314 100644
--- a/modules/support-generating-a-sosreport-archive.adoc
+++ b/modules/support-generating-a-sosreport-archive.adoc
@@ -114,15 +114,6 @@ The checksum is: 382ffc167510fd71b4f12a4f40b97a4e
 
 . Provide the `sosreport` archive to Red Hat Support for analysis, using one of the following methods.
 +
-* Upload the file to an existing Red Hat support case directly from an {product-title} cluster.
-.. From within the toolbox container, run `redhat-support-tool` to attach the archive directly to an existing Red Hat support case. This example uses support case ID `01234567`:
-+
-[source,terminal]
-----
-# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-sosreport.tar.xz <1>
-----
-<1> The toolbox container mounts the host's root directory at `/host`. Reference the absolute path from the toolbox container's root directory, including `/host/`, when specifying files to upload through the `redhat-support-tool` command.
-+
 * Upload the file to an existing Red Hat support case.
 .. Concatenate the `sosreport` archive by running the `oc debug node/<node_name>` command and redirect the output to a file. This command assumes you have exited the previous `oc debug` session:
 +
diff --git a/modules/support-providing-diagnostic-data-to-red-hat.adoc b/modules/support-providing-diagnostic-data-to-red-hat.adoc
index a9e9d07548da..7811c7208b95 100644
--- a/modules/support-providing-diagnostic-data-to-red-hat.adoc
+++ b/modules/support-providing-diagnostic-data-to-red-hat.adoc
@@ -6,7 +6,7 @@
 [id="support-providing-diagnostic-data-to-red-hat_{context}"]
 = Providing diagnostic data to Red Hat Support
 
-When investigating {product-title} issues, Red Hat Support might ask you to upload diagnostic data to a support case. Files can be uploaded to a support case through the Red Hat Customer Portal, or from an {product-title} cluster directly by using the `redhat-support-tool` command.
+When investigating {product-title} issues, Red Hat Support might ask you to upload diagnostic data to a support case. Files can be uploaded to a support case through the Red Hat Customer Portal.
 
 .Prerequisites
 
@@ -20,32 +20,31 @@ In {product-title} deployments, customers who are not using the Customer Cloud S
 endif::openshift-dedicated[]
 +
 * You have installed the OpenShift CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have SSH access to your hosts.
 * You have a Red Hat standard or premium Subscription.
 * You have a Red Hat Customer Portal account.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have an existing Red Hat Support case ID.
 
 .Procedure
 
 * Upload diagnostic data to an existing Red Hat support case through the Red Hat Customer Portal.
-. Concatenate a diagnostic file contained on an {product-title} node by using the `oc debug node/<node_name>` command and redirect the output to a file. The following example copies `/host/var/tmp/my-diagnostic-data.tar.gz` from a debug container to `/var/tmp/my-diagnostic-data.tar.gz`:
+.. Concatenate a diagnostic file contained on an {product-title} node by using the `oc debug node/<node_name>` command and redirect the output to a file. The following example copies `/host/var/tmp/my-diagnostic-data.tar.gz` from a debug container to `/var/tmp/my-diagnostic-data.tar.gz`:
 +
 [source,terminal]
 ----
 $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-diagnostic-data.tar.gz' > /var/tmp/my-diagnostic-data.tar.gz <1>
 ----
 <1> The debug container mounts the host's root directory at `/host`. Reference the absolute path from the debug container's root directory, including `/host`, when specifying target files for concatenation.
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 +
-ifndef::openshift-rosa,openshift-dedicated[]
 [NOTE]
 ====
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Transferring files from a cluster node by using `scp` is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to copy diagnostic files from a node by running `scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>`.
 ====
-+
-endif::openshift-rosa,openshift-dedicated[]
-. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
-+
-. Select *Attach files* and follow the prompts to upload the file.
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
+.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 
+.. Select *Attach files* and follow the prompts to upload the file.
diff --git a/modules/support-reviewing-an-access-request-from-an-email-notification.adoc b/modules/support-reviewing-an-access-request-from-an-email-notification.adoc
index 9285de31547f..6b02b2642f59 100644
--- a/modules/support-reviewing-an-access-request-from-an-email-notification.adoc
+++ b/modules/support-reviewing-an-access-request-from-an-email-notification.adoc
@@ -11,10 +11,10 @@
 
 Cluster owners will receive an email notification when Red{nbsp}Hat Site Reliability Engineering (SRE) request access to their cluster with a link to review the request in the {hybrid-console-second}.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Prerequisites
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 
 .Procedure
diff --git a/modules/support-reviewing-an-access-request-from-the-hybrid-console.adoc b/modules/support-reviewing-an-access-request-from-the-hybrid-console.adoc
index 15b85176e704..d7b8323ccc4a 100644
--- a/modules/support-reviewing-an-access-request-from-the-hybrid-console.adoc
+++ b/modules/support-reviewing-an-access-request-from-the-hybrid-console.adoc
@@ -9,10 +9,10 @@
 
 Review access requests for your {product-rosa} clusters from the {hybrid-console-second}.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .Prerequisites
 * You have access to the cluster as a user with the `Cluster Owner` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 
 .Procedure
diff --git a/modules/support-submitting-a-case-enable-approved-access.adoc b/modules/support-submitting-a-case-enable-approved-access.adoc
index 84a1795d0952..1387faff9617 100644
--- a/modules/support-submitting-a-case-enable-approved-access.adoc
+++ b/modules/support-submitting-a-case-enable-approved-access.adoc
@@ -23,7 +23,12 @@
 
 . Enter the following information:
 
-.. In the *Product* field, select *{product-title}* or *{product-title} {hcp-capital}*.
+ifdef::openshift-rosa[]
+.. In the *Product* field, select *{product-title}*.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+.. In the *Product* field, select *{product-title} {hcp-capital}*.
+endif::openshift-rosa-hcp[]
 .. In the *Problem statement* field, enter *Enable ROSA Access Protection*.
 .. Click *See more options*.
 
@@ -41,4 +46,3 @@
 . Select *Severity* as *4(Low)* and click *Continue*.
 
 . Preview the case details and click *Submit*.
-
diff --git a/modules/support-submitting-a-case.adoc b/modules/support-submitting-a-case.adoc
index 1b49c34013f1..5ad6727ddd2d 100644
--- a/modules/support-submitting-a-case.adoc
+++ b/modules/support-submitting-a-case.adoc
@@ -12,20 +12,20 @@
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have installed the OpenShift CLI (`oc`).
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the {cluster-manager-first}.
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have a Red Hat Customer Portal account.
 * You have a Red Hat Standard or Premium subscription.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
@@ -45,9 +45,9 @@ endif::openshift-rosa,openshift-dedicated[]
 
 .. Select *{product-title}* from the *Product* drop-down menu.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 .. Select *{product-version}* from the *Version* drop-down.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Review the list of suggested Red Hat Knowledgebase solutions for a potential match against the problem that is being reported. If the suggested articles do not address the issue, click *Continue*.
 
@@ -87,9 +87,9 @@ $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
 * When does this behavior occur? Frequency? Repeatedly? At certain times?
 
 . Upload relevant diagnostic data files and click *Continue*.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 It is recommended to include data gathered using the `oc adm must-gather` command as a starting point, plus any issue specific data that is not collected by that command.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 . Input relevant case management details and click *Continue*.
 
diff --git a/modules/telco-core-about-the-telco-core-cluster-use-model.adoc b/modules/telco-core-about-the-telco-core-cluster-use-model.adoc
new file mode 100644
index 000000000000..aeaa5b37b19e
--- /dev/null
+++ b/modules/telco-core-about-the-telco-core-cluster-use-model.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-about-the-telco-core-cluster-use-model_{context}"]
+= About the telco core cluster use model
+
+The telco core cluster use model is designed for clusters that run on commodity hardware.
+Telco core clusters support large scale telco applications including control plane functions such as signaling, aggregation, and session border controller (SBC); and centralized data plane functions such as 5G user plane functions (UPF).
+Telco core cluster functions require scalability, complex networking support, resilient software-defined storage, and support performance requirements that are less stringent and constrained than far-edge RAN deployments.
+
+.Telco core RDS cluster service-based architecture and networking topology
+image::openshift-5g-core-cluster-architecture-networking.png[5G core cluster showing a service-based architecture with overlaid networking topology]
+
+Networking requirements for telco core functions vary widely across a range of networking features and performance points.
+IPv6 is a requirement and dual-stack is common.
+Some functions need maximum throughput and transaction rate and require support for user-plane DPDK networking.
+Other functions use more typical cloud-native patterns and can rely on OVN-Kubernetes, kernel networking, and load balancing.
+
+Telco core clusters are configured as standard with three control plane and two or more worker nodes configured with the stock (non-RT) kernel.
+In support of workloads with varying networking and performance requirements, you can segment worker nodes by using `MachineConfigPool` custom resources (CR), for example, for non-user data plane or high-throughput use cases.
+In support of required telco operational features, core clusters have a standard set of Day 2 OLM-managed Operators installed.
diff --git a/modules/telco-core-additional-storage-solutions.adoc b/modules/telco-core-additional-storage-solutions.adoc
new file mode 100644
index 000000000000..e60e982315db
--- /dev/null
+++ b/modules/telco-core-additional-storage-solutions.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-additional-storage-solutions_{context}"]
+= Additional storage solutions
+You can use other storage solutions to provide persistent storage for telco core clusters.
+The configuration and integration of these solutions is outside the scope of the reference design specifications (RDS).
+
+Integration of the storage solution into the telco core cluster must include proper sizing and performance analysis to ensure the storage meets overall performance and resource usage requirements.
diff --git a/modules/telco-core-agent-based-installer-abi.adoc b/modules/telco-core-agent-based-installer-abi.adoc
deleted file mode 100644
index c04882f9f23b..000000000000
--- a/modules/telco-core-agent-based-installer-abi.adoc
+++ /dev/null
@@ -1,26 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-agent-based-installer-abi_{context}"]
-= Agent-based installer
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-You can install telco core clusters with the Agent-based installer (ABI) on bare-metal servers without requiring additional servers or virtual machines for managing the installation.
-ABI supports installations in disconnected environments.
-With ABI, you install clusters by using declarative custom resources (CRs).
-+
-[NOTE]
-====
-Agent-based installer is an optional component. The recommended installation method is by using {rh-rhacm-title} or {mce}.
-====
-
-Limits and requirements::
-* You need to have a disconnected mirror registry with all required content mirrored to do Agent-based installs in a disconnected environment.
-
-Engineering considerations::
-* Networking configuration should be applied as `NMState` custom resources (CRs) during cluster installation.
diff --git a/modules/telco-core-agent-based-installer.adoc b/modules/telco-core-agent-based-installer.adoc
new file mode 100644
index 000000000000..3ddf02fe6e33
--- /dev/null
+++ b/modules/telco-core-agent-based-installer.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-agent-based-installer_{context}"]
+= Agent-based Installer
+
+New in this release::
+* No reference design updates in this release
+
+Description::
++
+--
+Telco core clusters can be installed by using the Agent-based Installer.
+This method allows you to install OpenShift on bare-metal servers without requiring additional servers or VMs for managing the installation.
+The Agent-based Installer can be run on any system (for example, from a laptop) to generate an ISO installation image.
+The ISO is used as the installation media for the cluster supervisor nodes.
+Installation progress can be monitored using the ABI tool from any system with network connectivity to the supervisor node's API interfaces.
+
+ABI supports the following:
+
+* Installation from declarative CRs
+* Installation in disconnected environments
+* Installation with no additional supporting install or bastion servers required to complete the installation
+--
+
+Limits and requirements::
+* Disconnected installation requires a registry that is reachable from the installed host, with all required content mirrored in that registry.
+
+Engineering considerations::
+* Networking configuration should be applied as NMState configuration during installation.
+Day 2 networking configuration using the NMState Operator is not supported.
diff --git a/modules/telco-core-application-workloads.adoc b/modules/telco-core-application-workloads.adoc
new file mode 100644
index 000000000000..143e861f1f48
--- /dev/null
+++ b/modules/telco-core-application-workloads.adoc
@@ -0,0 +1,37 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-application-workloads_{context}"]
+= Application workloads
+
+Application workloads running on telco core clusters can include a mix of high performance cloud-native network functions (CNFs) and traditional best-effort or burstable pod workloads.
+
+Guaranteed QoS scheduling is available to pods that require exclusive or dedicated use of CPUs due to performance or security requirements.
+Typically, pods that run high performance or latency sensitive CNFs by using user plane networking (for example, DPDK) require exclusive use of dedicated whole CPUs achieved through node tuning and guaranteed QoS scheduling.
+When creating pod configurations that require exclusive CPUs, be aware of the potential implications of hyper-threaded systems.
+Pods should request multiples of 2 CPUs when the entire core (2 hyper-threads) must be allocated to the pod.
+
+Pods running network functions that do not require high throughput or low latency networking should be scheduled with best-effort or burstable QoS pods and do not require dedicated or isolated CPU cores.
+
+Engineering considerations::
++
+--
+Use the following information to plan telco core workloads and cluster resources:
+
+* CNF applications should conform to the latest version of https://redhat-best-practices-for-k8s.github.io/guide/[Red Hat Best Practices for Kubernetes].
+* Use a mix of best-effort and burstable QoS pods as required by your applications.
+** Use guaranteed QoS pods with proper configuration of reserved or isolated CPUs in the `PerformanceProfile` CR that configures the node.
+** Guaranteed QoS Pods must include annotations for fully isolating CPUs.
+** Best effort and burstable pods are not guaranteed exclusive CPU use.
+Workloads can be preempted by other workloads, operating system daemons, or kernel tasks.
+* Use exec probes sparingly and only when no other suitable option is available.
+** Do not use exec probes if a CNF uses CPU pinning.
+Use other probe implementations, for example, `httpGet` or `tcpSocket`.
+** When you need to use exec probes, limit the exec probe frequency and quantity.
+The maximum number of exec probes must be kept below 10, and the frequency must not be set to less than 10 seconds.
+** You can use startup probes, because they do not use significant resources at steady-state operation.
+This limitation on exec probes applies primarily to liveness and readiness probes.
+Exec probes cause much higher CPU usage on management cores compared to other probe types because they require process forking.
+--
diff --git a/modules/telco-core-cluster-common-use-model-engineering-considerations.adoc b/modules/telco-core-cluster-common-use-model-engineering-considerations.adoc
new file mode 100644
index 000000000000..28a4fe93d8c4
--- /dev/null
+++ b/modules/telco-core-cluster-common-use-model-engineering-considerations.adoc
@@ -0,0 +1,48 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-cluster-common-use-model-engineering-considerations_{context}"]
+= Telco core cluster common use model engineering considerations
+
+* Cluster workloads are detailed in "Application workloads".
+* Worker nodes should run on either of the following CPUs:
+** Intel 3rd Generation Xeon (IceLake) CPUs or better when supported by {product-title}, or CPUs with the silicon security bug (Spectre and similar) mitigations turned off.
+Skylake and older CPUs can experience 40% transaction performance drops when Spectre and similar mitigations are enabled.
+** AMD EPYC Zen 4 CPUs (Genoa, Bergamo, or newer) or better when supported by {product-title}.
++
+[NOTE]
+====
+Currently, per-pod power management is not available for AMD CPUs.
+====
+** IRQ balancing is enabled on worker nodes.
+The `PerformanceProfile` CR sets `globallyDisableIrqLoadBalancing` to false.
+Guaranteed QoS pods are annotated to ensure isolation as described in "CPU partitioning and performance tuning".
+
+* All cluster nodes should have the following features:
+** Have Hyper-Threading enabled
+** Have x86_64 CPU architecture
+** Have the stock (non-realtime) kernel enabled
+** Are not configured for workload partitioning
+
+* The balance between power management and maximum performance varies between machine config pools in the cluster.
+The following configurations should be consistent for all nodes in a machine config pools group.
+** Cluster scaling.
+See "Scalability" for more information.
+** Clusters should be able to scale to at least 120 nodes.
+
+* CPU partitioning is configured using a `PerformanceProfile` CR and is applied to nodes on a per `MachineConfigPool` basis.
+See "CPU partitioning and performance tuning" for additional considerations.
+* CPU requirements for {product-title} depend on the configured feature set and application workload characteristics.
+For a cluster configured according to the reference configuration running a simulated workload of 3000 pods as created by the kube-burner node-density test, the following CPU requirements are validated:
+** The minimum number of reserved CPUs for control plane and worker nodes is 2 CPUs (4 hyper-threads) per NUMA node.
+** The NICs used for non-DPDK network traffic should be configured to use at least 16 RX/TX queues.
+** Nodes with large numbers of pods or other resources might require additional reserved CPUs.
+The remaining CPUs are available for user workloads.
+
++
+[NOTE]
+====
+Variations in {product-title} configuration, workload size, and workload characteristics require additional analysis to determine the effect on the number of required CPUs for the OpenShift platform.
+====
diff --git a/modules/telco-core-cluster-network-operator.adoc b/modules/telco-core-cluster-network-operator.adoc
index 4e3f1dd9aa33..e03ebc26a5d4 100644
--- a/modules/telco-core-cluster-network-operator.adoc
+++ b/modules/telco-core-cluster-network-operator.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-cluster-network-operator_{context}"]
@@ -10,27 +10,35 @@ New in this release::
 * No reference design updates in this release
 
 Description::
-The Cluster Network Operator (CNO) deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during {product-title} cluster installation. It allows configuring primary interface MTU settings, OVN gateway modes to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
++
+--
+The Cluster Network Operator (CNO) deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during cluster installation.
+The CNO allows for configuring primary interface MTU settings, OVN gateway modes to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
+
+In support of network traffic separation, multiple network interfaces are configured through the CNO.
+Traffic steering to these interfaces is configured through static routes applied by using the NMState Operator.
+To ensure that pod traffic is properly routed, OVN-K is configured with the `routingViaHost` option enabled.
+This setting uses the kernel routing table and the applied static routes rather than OVN for pod egress traffic.
+
+The Whereabouts CNI plugin is used to provide dynamic IPv4 and IPv6 addressing for additional pod network interfaces without the use of a DHCP server.
+--
 
 Limits and requirements::
 * OVN-Kubernetes is required for IPv6 support.
-
 * Large MTU cluster support requires connected network equipment to be set to the same or larger value.
-
+MTU size up to 8900 is supported.
+//https://issues.redhat.com/browse/CNF-10593
 * MACVLAN and IPVLAN cannot co-locate on the same main interface due to their reliance on the same underlying kernel mechanism, specifically the `rx_handler`.
 This handler allows a third-party module to process incoming packets before the host processes them, and only one such handler can be registered per network interface.
 Since both MACVLAN and IPVLAN need to register their own `rx_handler` to function, they conflict and cannot coexist on the same interface.
-See link:https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82[ipvlan/ipvlan_main.c#L82] and link:https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/macvlan.c#L1260[net/macvlan.c#L1260] for details.
-
-* Alternative NIC configurations include splitting the shared NIC into multiple NICs or using a single dual-port NIC.
-+
-[IMPORTANT]
-====
-Splitting the shared NIC into multiple NICs or using a single dual-port NIC has not been validated with the telco core reference design.
-====
-
-* Single-stack IP cluster not validated.
-
+Review the source code for more details:
+** https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82[linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82]
+** https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/macvlan.c#L1260[linux/v6.10.2/source/drivers/net/macvlan.c#L1260]
+* Alternative NIC configurations include splitting the shared NIC into multiple NICs or using a single dual-port NIC, though they have not been tested and validated.
+* Clusters with single-stack IP configuration are not validated.
+* The `reachabilityTotalTimeoutSeconds` parameter in the `Network` CR configures the `EgressIP` node reachability check total timeout in seconds.
+The recommended value is `1` second.
 
 Engineering considerations::
-* Pod egress traffic is handled by kernel routing table with the `routingViaHost` option. Appropriate static routes must be configured in the host.
+* Pod egress traffic is handled by kernel routing table using the `routingViaHost` option.
+Appropriate static routes must be configured in the host.
diff --git a/modules/telco-core-cluster-service-based-architecture-and-networking-topology.adoc b/modules/telco-core-cluster-service-based-architecture-and-networking-topology.adoc
deleted file mode 100644
index 4eabf134c074..000000000000
--- a/modules/telco-core-cluster-service-based-architecture-and-networking-topology.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-cluster-service-based-architecture-and-networking-topology_{context}"]
-= {rds-caps} cluster service-based architecture and networking topology
-
-The {rds-caps} reference design specification (RDS) describes a platform that supports large-scale telco applications including control plane functions such as signaling and aggregation. It also includes some centralized data plane functions, for example, user plane functions (UPF). These functions generally require scalability, complex networking support, resilient software-defined storage, and support performance requirements that are less stringent and constrained than far-edge deployments like RAN.
-
-.{rds-caps} cluster service-based architecture and networking topology
-image::openshift-5g-core-cluster-architecture-networking.png[5G core cluster showing a service-based architecture with overlaid networking topology]
-
-The telco core cluster service-based architecture consists of the following components:
-
-* Network data analytics functions (**NWDAF**)
-* Network slice selection functions (**NSFF**)
-* Authentication server functions (**AUSF**)
-* Unified data managements (**UDM**)
-* Network repository functions (**NRF**)
-* Network exposure functions (**NEF**)
-* Application functions (**AF**)
-* Access and mobility functions (**AMF**)
-* Session management functions (**SMF**)
-* Policy control functions (**PCF**)
-* Charging functions (**CHF**)
-* User equipment (**UE**)
-* Radio access network (**RAN**)
-* User plane functions (**UPF**)
-* Data plane networking (**DN**)
diff --git a/modules/telco-core-common-baseline-model.adoc b/modules/telco-core-common-baseline-model.adoc
new file mode 100644
index 000000000000..d5cc07d39a07
--- /dev/null
+++ b/modules/telco-core-common-baseline-model.adoc
@@ -0,0 +1,47 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-common-baseline-model_{context}"]
+= Telco core common baseline model
+
+The following configurations and use models are applicable to all telco core use cases.
+The telco core use cases build on this common baseline of features.
+
+Cluster topology::
+Telco core clusters conform to the following requirements:
+
+* High availability control plane (three or more control plane nodes)
+* Non-schedulable control plane nodes
+* Multiple machine config pools
+
+Storage::
+Telco core use cases require persistent storage as provided by {rh-storage-first}.
+
+Networking::
+Telco core cluster networking conforms to the following requirements:
+
+* Dual stack IPv4/IPv6 (IPv4 primary).
+* Fully disconnected – clusters do not have access to public networking at any point in their lifecycle.
+* Supports multiple networks.
+Segmented networking provides isolation between operations, administration and maintenance (OAM), signaling, and storage traffic.
+* Cluster network type is OVN-Kubernetes as required for IPv6 support.
+* Telco core clusters have multiple layers of networking supported by underlying RHCOS, SR-IOV Network Operator, Load Balancer and other components.
+These layers include the following:
+** Cluster networking layer.
+The cluster network configuration is defined and applied through the installation configuration.
+Update the configuration during Day 2 operations with the NMState Operator.
+Use the initial configuration to establish the following:
+*** Host interface configuration.
+*** Active/active bonding (LACP).
+** Secondary/additional network layer.
+Configure the {product-title} CNI through network `additionalNetwork` or `NetworkAttachmentDefinition` CRs.
+Use the initial configuration to configure MACVLAN virtual network interfaces.
+** Application workload layer.
+User plane networking runs in cloud-native network functions (CNFs).
+
+Service Mesh::
+Telco CNFs can use Service Mesh.
+All telco core clusters require a Service Mesh implementation.
+The choice of implementation and configuration is outside the scope of this specification.
diff --git a/modules/telco-core-cpu-partitioning-and-performance-tuning.adoc b/modules/telco-core-cpu-partitioning-and-performance-tuning.adoc
new file mode 100644
index 000000000000..7ec4980a357a
--- /dev/null
+++ b/modules/telco-core-cpu-partitioning-and-performance-tuning.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-cpu-partitioning-and-performance-tuning_{context}"]
+= CPU partitioning and performance tuning
+
+New in this release::
+* No reference design updates in this release
+
+Description::
+CPU partitioning improves performance and reduces latency by separating sensitive workloads from general-purpose tasks, interrupts, and driver work queues.
+The CPUs allocated to those auxiliary processes are referred to as _reserved_ in the following sections.
+In a system with Hyper-Threading enabled, a CPU is one hyper-thread.
+
+Limits and requirements::
+* The operating system needs a certain amount of CPU to perform all the support tasks, including kernel networking.
+** A system with just user plane networking applications (DPDK) needs at least one core (2 hyper-threads when enabled) reserved for the operating system and the infrastructure components.
+* In a system with Hyper-Threading enabled, core sibling threads must always be in the same pool of CPUs.
+* The set of reserved and isolated cores must include all CPU cores.
+* Core 0 of each NUMA node must be included in the reserved CPU set.
+* Low latency workloads require special configuration to avoid being affected by interrupts, kernel scheduler, or other parts of the platform.
+For more information, see "Creating a performance profile".
+
+Engineering considerations::
+* The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in the link:https://access.redhat.com/solutions/5843241[Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?] Knowledgebase article.
+* The actual required reserved CPU capacity depends on the cluster configuration and workload attributes.
+* The reserved CPU value must be rounded up to a full core (2 hyper-threads) alignment.
+* Changes to CPU partitioning cause the nodes contained in the relevant machine config pool to be drained and rebooted.
+* The reserved CPUs reduce the pod density, because the reserved CPUs are removed from the allocatable capacity of the {product-title} node.
+* The real-time workload hint should be enabled for real-time capable workloads.
+** Applying the real time `workloadHint` setting results in the `nohz_full` kernel command line parameter being applied to improve performance of high performance applications.
+When you apply the `workloadHint` setting, any isolated or burstable pods that do not have the `cpu-quota.crio.io: "disable"` annotation and a proper `runtimeClassName` value, are subject to CRI-O rate limiting.
+When you set the `workloadHint` parameter, be aware of the tradeoff between increased performance and the potential impact of CRI-O rate limiting.
+Ensure that required pods are correctly annotated.
+* Hardware without IRQ affinity support affects isolated CPUs.
+All server hardware must support IRQ affinity to ensure that pods with guaranteed CPU QoS can fully use allocated CPUs.
+* OVS dynamically manages its `cpuset` entry to adapt to network traffic needs.
+You do not need to reserve an additional CPU for handling high network throughput on the primary CNI.
+* If workloads running on the cluster use kernel level networking, the RX/TX queue count for the participating NICs should be set to 16 or 32 queues if the hardware permits it.
+Be aware of the default queue count.
+With no configuration, the default queue count is one RX/TX queue per online CPU; which can result in too many interrupts being allocated.
++
+[NOTE]
+====
+Some drivers do not deallocate the interrupts even after reducing the queue count.
+====
+
+* If workloads running on the cluster require cgroup v1, you can configure nodes to use cgroup v1 as part of the initial cluster deployment.
+See "Enabling Linux control group version 1 (cgroup v1)" and link:https://www.redhat.com/en/blog/rhel-9-changes-context-red-hat-openshift-workloads[Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads].
++
+[NOTE]
+====
+Support for cgroup v1 is planned for removal in {product-title} 4.19.
+Clusters running cgroup v1 must transition to cgroup v2.
+====
diff --git a/modules/telco-core-cpu-partitioning-performance-tune.adoc b/modules/telco-core-cpu-partitioning-performance-tune.adoc
deleted file mode 100644
index 5072a0627bae..000000000000
--- a/modules/telco-core-cpu-partitioning-performance-tune.adoc
+++ /dev/null
@@ -1,46 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-cpu-partitioning-performance-tune_{context}"]
-= CPU partitioning and performance tuning
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-CPU partitioning allows for the separation of sensitive workloads from generic purposes, auxiliary processes, interrupts, and driver work queues to achieve improved performance and latency.
-
-Limits and requirements::
-* The operating system needs a certain amount of CPU to perform all the support tasks including kernel networking.
-** A system with just user plane networking applications (DPDK) needs at least one Core (2 hyperthreads when enabled) reserved for the operating system and the infrastructure components.
-* A system with Hyper-Threading enabled must always put all core sibling threads to the same pool of CPUs.
-* The set of reserved and isolated cores must include all CPU cores.
-* Core 0 of each NUMA node must be included in the reserved CPU set.
-* Isolated cores might be impacted by interrupts. The following annotations must be attached to the pod if guaranteed QoS pods require full use of the CPU:
-+
-----
-cpu-load-balancing.crio.io: "disable"
-cpu-quota.crio.io: "disable"
-irq-load-balancing.crio.io: "disable"
-----
-* When per-pod power management is enabled with `PerformanceProfile.workloadHints.perPodPowerManagement` the following annotations must also be attached to the pod if guaranteed QoS pods require full use of the CPU:
-+
-----
-cpu-c-states.crio.io: "disable"
-cpu-freq-governor.crio.io: "performance"
-----
-
-Engineering considerations::
-* The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in  link:https://access.redhat.com/solutions/5843241["Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?"]
-* The actual required reserved CPU capacity depends on the cluster configuration and workload attributes.
-* This reserved CPU value must be rounded up to a full core (2 hyper-thread) alignment.
-* Changes to the CPU partitioning will drain and reboot the nodes in the MCP.
-* The reserved CPUs reduce the pod density, as the reserved CPUs are removed from the allocatable capacity of the OpenShift node.
-* The real-time workload hint should be enabled if the workload is real-time capable.
-* Hardware without Interrupt Request (IRQ) affinity support will impact isolated CPUs. To ensure that pods with guaranteed CPU QoS have full use of allocated CPU, all hardware in the server must support IRQ affinity.
-* OVS dynamically manages its `cpuset` configuration to adapt to network traffic needs.
-You do not need to reserve additional CPUs for handling high network throughput on the primary CNI.
-* If workloads running on the cluster require cgroups v1, you can configure nodes to use cgroups v1 as part of the initial cluster deployment.
-For more information, see "Enabling Linux cgroup v1 during installation".
diff --git a/modules/telco-core-crs-machine-configuration.adoc b/modules/telco-core-crs-machine-configuration.adoc
deleted file mode 100644
index 9eacac00e7d5..000000000000
--- a/modules/telco-core-crs-machine-configuration.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/ran/telco-core-ref-du-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="reference-crs_{context}"]
-= Reference CRs
-
-.Resource Tuning
-[cols="3*"]
-|====
-| Component | Reference CR | Optional
-
-| System Reserved capacity a| * xref:telco-core-ref-du-crs.adoc#pid-limits-cr-yaml[pid-limits-cr.yaml]
-* xref:telco-core-ref-du-crs.adoc#control-plane-system-reserved[control-plane-system-reserved.yaml] | Yes
-
-|====
\ No newline at end of file
diff --git a/modules/telco-core-crs-networking.adoc b/modules/telco-core-crs-networking.adoc
index 09f9e6535a57..c6bc9e3e5d4e 100644
--- a/modules/telco-core-crs-networking.adoc
+++ b/modules/telco-core-crs-networking.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="networking-crs_{context}"]
@@ -9,27 +9,27 @@
 .Networking CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-network-yaml[Network.yaml],Yes,No
-Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-addr-pool-yaml[addr-pool.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bfd-profile-yaml[bfd-profile.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-advr-yaml[bgp-advr.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-peer-yaml[bgp-peer.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-community-yaml[community.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallb-yaml[metallb.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbns-yaml[metallbNS.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbopergroup-yaml[metallbOperGroup.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbsubscription-yaml[metallbSubscription.yaml],No,No
-Multus - Tap CNI for rootless DPDK pods,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],No,No
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstate-yaml[NMState.yaml],No,No
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatens-yaml[NMStateNS.yaml],No,No
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstateopergroup-yaml[NMStateOperGroup.yaml],No,No
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatesubscription-yaml[NMStateSubscription.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetwork-yaml[sriovNetwork.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetworknodepolicy-yaml[sriovNetworkNodePolicy.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscription-yaml[SriovSubscription.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscriptionns-yaml[SriovSubscriptionNS.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscriptionopergroup-yaml[SriovSubscriptionOperGroup.yaml],No,No
+Component,Reference CR,Description,Optional
+Baseline,`Network.yaml`,"Configures the default cluster network, specifying OVN Kubernetes settings like routing via the host. It also allows the definition of additional networks, including custom CNI configurations, and enables the use of MultiNetworkPolicy CRs for network policies across multiple networks.",No
+Baseline,`networkAttachmentDefinition.yaml`,Optional. Defines a NetworkAttachmentDefinition resource specifying network configuration details such as node selector and CNI configuration.,Yes
+Load Balancer,`addr-pool.yaml`,Configures MetalLB to manage a pool of IP addresses with auto-assign enabled for dynamic allocation of IPs from the specified range.,No
+Load Balancer,`bfd-profile.yaml`,"Configures bidirectional forwarding detection (BFD) with customized intervals, detection multiplier, and modes for quicker network fault detection and load balancing failover.",No
+Load Balancer,`bgp-advr.yaml`,"Defines a BGP advertisement resource for MetalLB, specifying how an IP address pool is advertised to BGP peers. This enables fine-grained control over traffic routing and announcements.",No
+Load Balancer,`bgp-peer.yaml`,"Defines a BGP peer in MetalLB, representing a BGP neighbor for dynamic routing.",No
+Load Balancer,`community.yaml`,"Defines a MetalLB community, which groups one or more BGP communities under a named resource. Communities can be applied to BGP advertisements to control routing policies and change traffic routing.",No
+Load Balancer,`metallb.yaml`,Defines the MetalLB resource in the cluster.,No
+Load Balancer,`metallbNS.yaml`,Defines the metallb-system namespace in the cluster.,No
+Load Balancer,`metallbOperGroup.yaml`,Defines the Operator group for the MetalLB Operator.,No
+Load Balancer,`metallbSubscription.yaml`,Creates a subscription resource for the metallb Operator with manual approval for install plans.,No
+Multus - Tap CNI for rootless DPDK pods,`mc_rootless_pods_selinux.yaml`,Configures a MachineConfig resource which sets an SELinux boolean for the tap CNI plugin on worker nodes.,Yes
+NMState Operator,`NMState.yaml`,Defines an NMState resource that is used by the NMState Operator to manage node network configurations.,No
+NMState Operator,`NMStateNS.yaml`,Creates the NMState Operator namespace.,No
+NMState Operator,`NMStateOperGroup.yaml`,"Creates the Operator group in the openshift-nmstate namespace, allowing the NMState Operator to watch and manage resources.",No
+NMState Operator,`NMStateSubscription.yaml`,"Creates a subscription for the NMState Operator, managed through OLM.",No
+SR-IOV Network Operator,`sriovNetwork.yaml`,"Defines an SR-IOV network specifying network capabilities, IP address management (ipam), and the associated network namespace and resource.",No
+SR-IOV Network Operator,`sriovNetworkNodePolicy.yaml`,"Configures network policies for SR-IOV devices on specific nodes, including customization of device selection, VF allocation (numVfs), node-specific settings (nodeSelector), and priorities.",No
+SR-IOV Network Operator,`SriovOperatorConfig.yaml`,"Configures various settings for the SR-IOV Operator, including enabling the injector and Operator webhook, disabling pod draining, and defining the node selector for the configuration daemon.",No
+SR-IOV Network Operator,`SriovSubscription.yaml`,"Creates a subscription for the SR-IOV Network Operator, managed through OLM.",No
+SR-IOV Network Operator,`SriovSubscriptionNS.yaml`,Creates the SR-IOV Network Operator subscription namespace.,No
+SR-IOV Network Operator,`SriovSubscriptionOperGroup.yaml`,"Creates the Operator group for the SR-IOV Network Operator, allowing it to watch and manage resources in the target namespace.",No
 |====
diff --git a/modules/telco-core-crs-node-configuration.adoc b/modules/telco-core-crs-node-configuration.adoc
index 5a44755c0ade..c104a9df98f0 100644
--- a/modules/telco-core-crs-node-configuration.adoc
+++ b/modules/telco-core-crs-node-configuration.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="node-configuration-crs_{context}"]
@@ -9,12 +9,12 @@
 .Node configuration CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-control-plane-load-kernel-modules-yaml[control-plane-load-kernel-modules.yaml],Yes,No
-Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sctp_module_mc-yaml[sctp_module_mc.yaml],Yes,No
-Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-worker-load-kernel-modules-yaml[worker-load-kernel-modules.yaml],Yes,No
-Container mount namespace hiding,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mount_namespace_config_master-yaml[mount_namespace_config_master.yaml],No,Yes
-Container mount namespace hiding,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mount_namespace_config_worker-yaml[mount_namespace_config_worker.yaml],No,Yes
-Kdump enable,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-kdump-master-yaml[kdump-master.yaml],No,Yes
-Kdump enable,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-kdump-worker-yaml[kdump-worker.yaml],No,Yes
+Component,Reference CR,Description,Optional
+Additional kernel modules,`control-plane-load-kernel-modules.yaml`,Optional. Configures the kernel modules for control plane nodes.,No
+Additional kernel modules,`sctp_module_mc.yaml`,Optional. Loads the SCTP kernel module in worker nodes.,No
+Additional kernel modules,`worker-load-kernel-modules.yaml`,Optional. Configures kernel modules for worker nodes.,No
+Container mount namespace hiding,`mount_namespace_config_master.yaml`,Configures a mount namespace for sharing container-specific mounts between kubelet and CRI-O on control plane nodes.,No
+Container mount namespace hiding,`mount_namespace_config_worker.yaml`,Configures a mount namespace for sharing container-specific mounts between kubelet and CRI-O on worker nodes.,No
+Kdump enable,`kdump-master.yaml`,Configures kdump crash reporting on master nodes.,No
+Kdump enable,`kdump-worker.yaml`,Configures kdump crash reporting on worker nodes.,No
 |====
diff --git a/modules/telco-core-crs-other.adoc b/modules/telco-core-crs-other.adoc
deleted file mode 100644
index 2a4fa630c9ec..000000000000
--- a/modules/telco-core-crs-other.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="other-crs_{context}"]
-= Other reference CRs
-
-.Other CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogforwarder-yaml[ClusterLogForwarder.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogns-yaml[ClusterLogNS.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogopergroup-yaml[ClusterLogOperGroup.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogserviceaccount-yaml[ClusterLogServiceAccount.yaml],Yes,Yes
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogserviceaccountauditbinding-yaml[ClusterLogServiceAccountAuditBinding.yaml],Yes,Yes
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogserviceaccountinfrastructurebinding-yaml[ClusterLogServiceAccountInfrastructureBinding.yaml],Yes,Yes
-Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogsubscription-yaml[ClusterLogSubscription.yaml],Yes,No
-Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-catalog-source-yaml[catalog-source.yaml],No,No
-Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-icsp-yaml[icsp.yaml],No,No
-Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-operator-hub-yaml[operator-hub.yaml],No,No
-Monitoring and observability,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-monitoring-config-cm-yaml[monitoring-config-cm.yaml],Yes,No
-Power management,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-performanceprofile-yaml[PerformanceProfile.yaml],No,No
-|====
diff --git a/modules/telco-core-crs-resource-tuning.adoc b/modules/telco-core-crs-resource-tuning.adoc
index c6aefdb9d3b7..0131759f5c50 100644
--- a/modules/telco-core-crs-resource-tuning.adoc
+++ b/modules/telco-core-crs-resource-tuning.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="resource-tuning-crs_{context}"]
@@ -9,6 +9,6 @@
 .Resource tuning CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-System reserved capacity,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-control-plane-system-reserved-yaml[control-plane-system-reserved.yaml],Yes,No
+Component,Reference CR,Description,Optional
+System reserved capacity,`control-plane-system-reserved.yaml`,"Optional. Configures kubelet, enabling auto-sizing reserved resources for the control plane node pool.",No
 |====
diff --git a/modules/telco-core-crs-scheduling.adoc b/modules/telco-core-crs-scheduling.adoc
index d3ae65265f96..2793905bad0f 100644
--- a/modules/telco-core-crs-scheduling.adoc
+++ b/modules/telco-core-crs-scheduling.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="scheduling-crs_{context}"]
@@ -9,11 +9,11 @@
 .Scheduling CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nrop-yaml[nrop.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscription-yaml[NROPSubscription.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscriptionns-yaml[NROPSubscriptionNS.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscriptionopergroup-yaml[NROPSubscriptionOperGroup.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sched-yaml[sched.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-scheduler-yaml[Scheduler.yaml],No,No
+Component,Reference CR,Description,Optional
+NUMA-aware scheduler,`nrop.yaml`,"Enables the NUMA Resources Operator, aligning workloads with specific NUMA node configurations. Required for clusters with multi-NUMA nodes.",No
+NUMA-aware scheduler,`NROPSubscription.yaml`,"Creates a subscription for the NUMA Resources Operator, managed through OLM. Required for clusters with multi-NUMA nodes.",No
+NUMA-aware scheduler,`NROPSubscriptionNS.yaml`,Creates the NUMA Resources Operator subscription namespace. Required for clusters with multi-NUMA nodes.,No
+NUMA-aware scheduler,`NROPSubscriptionOperGroup.yaml`,"Creates the Operator group in the numaresources-operator namespace, allowing the NUMA Resources Operator to watch and manage resources. Required for clusters with multi-NUMA nodes.",No
+NUMA-aware scheduler,`sched.yaml`,Configures a topology-aware scheduler in the cluster that can handle NUMA aware scheduling of pods across nodes.,No
+NUMA-aware scheduler,`Scheduler.yaml`,Configures control plane nodes as non-schedulable for workloads.,No
 |====
diff --git a/modules/telco-core-crs-storage.adoc b/modules/telco-core-crs-storage.adoc
index c8c6f5ef16da..7ae3f0531103 100644
--- a/modules/telco-core-crs-storage.adoc
+++ b/modules/telco-core-crs-storage.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="storage-crs_{context}"]
@@ -9,10 +9,10 @@
 .Storage CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-01-rook-ceph-external-cluster-details.secret-yaml[01-rook-ceph-external-cluster-details.secret.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-02-ocs-external-storagecluster-yaml[02-ocs-external-storagecluster.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfns-yaml[odfNS.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfopergroup-yaml[odfOperGroup.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfsubscription-yaml[odfSubscription.yaml],No,No
+Component,Reference CR,Description,Optional
+External ODF configuration,`01-rook-ceph-external-cluster-details.secret.yaml`,Defines a Secret resource containing base64-encoded configuration data for an external Ceph cluster in the openshift-storage namespace.,No
+External ODF configuration,`02-ocs-external-storagecluster.yaml`,Defines an OpenShift Container Storage (OCS) storage resource which configures the cluster to use an external storage back end.,No
+External ODF configuration,`odfNS.yaml`,Creates the monitored openshift-storage namespace for the OpenShift Data Foundation Operator.,No
+External ODF configuration,`odfOperGroup.yaml`,"Creates the Operator group in the openshift-storage namespace, allowing the OpenShift Data Foundation Operator to watch and manage resources.",No
+External ODF configuration,`odfSubscription.yaml`,"Creates the subscription for the OpenShift Data Foundation Operator in the openshift-storage namespace.",No
 |====
diff --git a/modules/telco-core-disconnected-environment.adoc b/modules/telco-core-disconnected-environment.adoc
new file mode 100644
index 000000000000..6f4a7e3c81ca
--- /dev/null
+++ b/modules/telco-core-disconnected-environment.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-disconnected-environment_{context}"]
+= Disconnected environment
+
+New in this release::
+* No reference design updates in this release
+
+Descrption::
+Telco core clusters are expected to be installed in networks without direct access to the internet.
+All container images needed to install, configure, and operate the cluster must be available in a disconnected registry.
+This includes {product-title} images, Day 2 OLM Operator images, and application workload images.
+The use of a disconnected environment provides multiple benefits, including:
+
+* Security - limiting access to the cluster
+* Curated content – the registry is populated based on curated and approved updates for clusters
+
+Limits and requirements::
+* A unique name is required for all custom `CatalogSource` resources.
+Do not reuse the default catalog names.
+
+Engineering considerations::
+* A valid time source must be configured as part of cluster installation
diff --git a/modules/telco-core-gitops-operator-and-ztp-plugins.adoc b/modules/telco-core-gitops-operator-and-ztp-plugins.adoc
new file mode 100644
index 000000000000..2a4e7ff4d952
--- /dev/null
+++ b/modules/telco-core-gitops-operator-and-ztp-plugins.adoc
@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-gitops-operator-and-ztp-plugins_{context}"]
+= GitOps Operator and GitOps ZTP plugins
+
+New in this release::
+* No reference design updates in this release
+
+Description::
++
+--
+The GitOps Operator provides a GitOps driven infrastructure for managing cluster deployment and configuration.
+Cluster definitions and configuration are maintained in a Git repository.
+
+ZTP plugins provide support for generating `Installation` CRs from `SiteConfig` CRs and automatically wrapping configuration CRs in policies based on {rh-rhacm} `PolicyGenerator` CRs.
+
+The SiteConfig Operator provides improved support for generation of `Installation` CRs from `ClusterInstance` CRs.
+
+[IMPORTANT]
+====
+Where possible, use `ClusterInstance` CRs for cluster installation instead of the `SiteConfig` with {ztp} plugin method.
+====
+
+You should structure the Git repository according to release version, with all necessary artifacts (`SiteConfig`, `ClusterInstance`, `PolicyGenerator`, and `PolicyGenTemplate`, and supporting reference CRs) included.
+This enables deploying and managing multiple versions of the OpenShift platform and configuration versions to clusters simultaneously and through upgrades.
+
+The recommended Git structure keeps reference CRs in a directory separate from customer or partner provided content.
+This means that you can import reference updates by simply overwriting existing content.
+Customer or partner-supplied CRs can be provided in a parallel directory to the reference CRs for easy inclusion in the generated configuration policies.
+--
+
+Limits and requirements::
+* Each ArgoCD application supports up to 300 nodes.
+Multiple ArgoCD applications can be used to achieve the maximum number of clusters supported by a single hub cluster.
+* The `SiteConfig` CR must use the `extraManifests.searchPaths` field to reference the reference manifests.
++
+[NOTE]
+====
+Since {product-title} 4.15, the `spec.extraManifestPath` field is deprecated.
+====
+
+Engineering considerations::
+* Set the `MachineConfigPool` (`mcp`) CR `paused` field to true during a cluster upgrade maintenance window and set the `maxUnavailable` field to the maximum tolerable value.
+This prevents multiple cluster node reboots during upgrade, which results in a shorter overall upgrade.
+When you unpause the `mcp` CR, all the configuration changes are applied with a single reboot.
++
+[NOTE]
+====
+During installation, custom `mcp` CRs can be paused along with setting `maxUnavailable` to 100% to improve installation times.
+====
+
+* To avoid confusion or unintentional overwriting when updating content, you should use unique and distinguishable names for custom CRs in the `reference-crs/` directory under core-overlay and extra manifests in Git.
+* The `SiteConfig` CR allows multiple extra-manifest paths.
+When file names overlap in multiple directory paths, the last file found in the directory order list takes precedence.
diff --git a/modules/telco-core-hardware-platform-specifications.adoc b/modules/telco-core-hardware-platform-specifications.adoc
deleted file mode 100644
index e43a0b330fe6..000000000000
--- a/modules/telco-core-hardware-platform-specifications.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/ran/telco-ran-ref-validation-artifacts.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-hardware-platform-specifications_{context}"]
-= Hardware platform specifications
-
-The telco core DU reference configuration is validated with the following hardware:
-
-.Validated {sno} DU cluster hardware
-[cols="1,3", width="90%", options="header"]
-|====
-|Server
-|Specifications
-
-|Dell PowerEdge R640
-a|* 192G RAM
-* 64 cores
-
-|HP ProLiant e910
-a|* 96G RAM
-* 48 cores
-|====
-
-.Validated  CNF compute cluster hardware
-[cols="1,3", width="90%", options="header"]
-|====
-|Server
-|Specifications
-
-|Dell R640/750 (2-sockets)
-a|* 2 x Intel Xeon Gold 6248 CPUs
-* 196 to 256GB RAM
-* 2.5 to 3 TB HD
-|====
-
-.Validated NICs
-[cols="1,3", width="90%", options="header"]
-|====
-|Network interface
-|Description
-
-|Intel X722
-a|* 10/1 GbE backplane
-
-|Mellanox ConnectX-4 Lx
-a|* 2 ports
-* 25 GbE
-* PCIe 3.0
-|====
-
-.Validated Storage
-[cols="1,3", width="90%", options="header"]
-|====
-|Device
-|Description
-
-|NVME drive
-a|
-|====
\ No newline at end of file
diff --git a/modules/telco-core-host-firmware-bootloader.adoc b/modules/telco-core-host-firmware-and-boot-loader-configuration.adoc
similarity index 57%
rename from modules/telco-core-host-firmware-bootloader.adoc
rename to modules/telco-core-host-firmware-and-boot-loader-configuration.adoc
index bbbbda25eb1a..57d262789d0c 100644
--- a/modules/telco-core-host-firmware-bootloader.adoc
+++ b/modules/telco-core-host-firmware-and-boot-loader-configuration.adoc
@@ -1,16 +1,16 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
-[id="telco-core-host-firmware-and-bootloader-configuration_{context}"]
+[id="telco-core-host-firmware-and-boot-loader-configuration_{context}"]
 = Host firmware and boot loader configuration
 
 New in this release::
-//CNF-11806
-* Secure boot is now recommended for cluster hosts configured with the telco core reference design.
+* No reference design updates in this release
 
 Engineering considerations::
+// https://issues.redhat.com/browse/CNF-11806
 * Enabling secure boot is the recommended configuration.
 +
 [NOTE]
diff --git a/modules/telco-core-installation.adoc b/modules/telco-core-installation.adoc
deleted file mode 100644
index 1ed03897ad90..000000000000
--- a/modules/telco-core-installation.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-installation_{context}"]
-= Installation
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-{rds-caps} clusters can be installed using the Agent Based Installer (ABI). This method allows users to install {product-title} on bare-metal servers without requiring additional servers or VMs for managing the installation.
-
-Limits and requirements::
-* Disconnected installation requires a reachable registry with all required content mirrored.
-
-Engineering considerations::
-* Networking configuration should be applied as an `NMState` custom resource (CR) during installation in preference to Day 2 configuration with the NMState Operator.
diff --git a/modules/telco-core-load-balancer.adoc b/modules/telco-core-load-balancer.adoc
index c085c0e9c82b..50d50c0097f4 100644
--- a/modules/telco-core-load-balancer.adoc
+++ b/modules/telco-core-load-balancer.adoc
@@ -1,38 +1,40 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-load-balancer_{context}"]
 = Load balancer
 
 New in this release::
-//CNF-11914
-* In {product-title} 4.17, `frr-k8s` is now the default and fully supported Border Gateway Protocol (BGP) backend.
-The deprecated `frr` BGP mode is still available.
-You should upgrade clusters to use the `frr-k8s` backend.
-
-Description::
-MetalLB is a load-balancer implementation that uses standard routing protocols for bare-metal clusters. It enables a Kubernetes service to get an external IP address which is also added to the host network for the cluster.
+// https://issues.redhat.com/browse/CNF-14150
+* FRR-K8s is now available under the Cluster Network Operator.
 +
-[NOTE]
+[IMPORTANT]
 ====
-Some use cases might require features not available in MetalLB, for example stateful load balancing.
-Where necessary, use an external third party load balancer.
-Selection and configuration of an external load balancer is outside the scope of this document.
-When you use an external third party load balancer, ensure that it meets all performance and resource utilization requirements.
+If you have custom `FRRConfiguration` CRs in the `metallb-system` namespace, you must move them under the `openshift-network-operator` namespace.
 ====
 
-Limits and requirements::
+Description::
+MetalLB is a load-balancer implementation for bare metal Kubernetes clusters that uses standard routing protocols.
+It enables a Kubernetes service to get an external IP address which is also added to the host network for the cluster.
+The MetalLB Operator deploys and manages the lifecycle of a MetalLB instance in a cluster.
+Some use cases might require features not available in MetalLB, such as stateful load balancing.
+Where necessary, you can use an external third party load balancer.
+Selection and configuration of an external load balancer is outside the scope of this specification.
+When an external third-party load balancer is used, the integration effort must include enough analysis to ensure all performance and resource utilization requirements are met.
 
-* Stateful load balancing is not supported by MetalLB. An alternate load balancer implementation must be used if this is a requirement for workload CNFs.
-* The networking infrastructure must ensure that the external IP address is routable from clients to the host network for the cluster.
+Limits and requirements::
+* Stateful load balancing is not supported by MetalLB.
+An alternate load balancer implementation must be used if this is a requirement for workload CNFs.
+* You must ensure that the external IP address is routable from clients to the host network for the cluster.
 
 Engineering considerations::
-* MetalLB is used in BGP mode only for core use case models.
-* For core use models, MetalLB is supported with only the OVN-Kubernetes network provider used in local gateway mode. See `routingViaHost` in the "Cluster Network Operator" section.
-* BGP configuration in MetalLB varies depending on the requirements of the network and peers.
-* Address pools can be configured as needed, allowing variation in addresses, aggregation length, auto assignment, and other relevant parameters.
-* MetalLB uses BGP for announcing routes only.
+* MetalLB is used in BGP mode only for telco core use models.
+* For telco core use models, MetalLB is supported only with the OVN-Kubernetes network provider used in local gateway mode.
+See `routingViaHost` in "Cluster Network Operator".
+* BGP configuration in MetalLB is expected to vary depending on the requirements of the network and peers.
+** You can configure address pools with variations in addresses, aggregation length, auto assignment, and so on.
+** MetalLB uses BGP for announcing routes only.
 Only the `transmitInterval` and `minimumTtl` parameters are relevant in this mode.
-Other parameters in the BFD profile should remain close to the default settings. Shorter values might lead to errors and impact performance.
+Other parameters in the BFD profile should remain close to the defaults as shorter values can lead to false negatives and affect performance.
diff --git a/modules/telco-core-logging.adoc b/modules/telco-core-logging.adoc
index 445f802305ce..2f4a76306000 100644
--- a/modules/telco-core-logging.adoc
+++ b/modules/telco-core-logging.adoc
@@ -1,21 +1,22 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-logging_{context}"]
 = Logging
 
 New in this release::
-* Cluster Logging Operator 6.0 is new in this release.
-Update your existing implementation to adapt to the new version of the API.
+* No reference design updates in this release
 
 Description::
-The Cluster Logging Operator enables collection and shipping of logs off the node for remote archival and analysis. The reference configuration ships audit and infrastructure logs to a remote archive by using Kafka.
+The Cluster Logging Operator enables collection and shipping of logs off the node for remote archival and analysis.
+The reference configuration uses Kafka to ship audit and infrastructure logs to a remote archive.
 
 Limits and requirements::
 Not applicable
 
 Engineering considerations::
 * The impact of cluster CPU use is based on the number or size of logs generated and the amount of log filtering configured.
-* The reference configuration does not include shipping of application logs. Inclusion of application logs in the configuration requires evaluation of the application logging rate and sufficient additional CPU resources allocated to the reserved set.
+* The reference configuration does not include shipping of application logs.
+The inclusion of application logs in the configuration requires you to evaluate the application logging rate and have sufficient additional CPU resources allocated to the reserved set.
diff --git a/modules/telco-core-monitoring.adoc b/modules/telco-core-monitoring.adoc
index 92ea4d9426fb..716965ef4660 100644
--- a/modules/telco-core-monitoring.adoc
+++ b/modules/telco-core-monitoring.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-monitoring_{context}"]
@@ -10,16 +10,24 @@ New in this release::
 * No reference design updates in this release
 
 Description::
-The {cmo-first} is included by default in {product-title} and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
 +
-[NOTE]
-====
-The default handling of pod CPU and memory metrics is based on upstream Kubernetes `cAdvisor` and makes a tradeoff that prefers handling of stale data over metric accuracy. This leads to spiky data that will create false triggers of alerts over user-specified thresholds. OpenShift supports an opt-in dedicated service monitor feature creating an additional set of pod CPU and memory metrics that do not suffer from the spiky behavior.
-For additional information, see link:https://access.redhat.com/solutions/7012719[Dedicated Service Monitors - Questions and Answers].
-====
+--
+The Cluster Monitoring Operator (CMO) is included by default in {product-title} and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects.
+You can customize the default log retention period, custom alert rules, and so on.
+The default handling of pod CPU and memory metrics, based on upstream Kubernetes and cAdvisor, makes a tradeoff favoring stale data over metric accuracy.
+This leads to spikes in reporting, which can create false alerts, depending on the user-specified thresholds.
+{product-title} supports an opt-in Dedicated Service Monitor feature that creates an additional set of pod CPU and memory metrics that do not suffer from this behavior.
+For more information, see link:https://access.redhat.com/solutions/7012719[Dedicated Service Monitors - Questions and Answers (Red Hat Knowledgebase)].
+
+In addition to the default configuration, the following metrics are expected to be configured for telco core clusters:
+
+* Pod CPU and memory metrics and alerts for user workloads
+--
 
 Limits and requirements::
-* Monitoring configuration must enable the dedicated service monitor feature for accurate representation of pod metrics
+* You must enable the Dedicated Service Monitor feature to represent pod metrics accurately.
 
 Engineering considerations::
-* You configure the Prometheus retention period. The value used is a tradeoff between operational requirements for maintaining historical data on the cluster against CPU and storage resources. Longer retention periods increase the need for storage and require additional CPU to manage the indexing of data.
+* The Prometheus retention period is specified by the user.
+The value used is a tradeoff between operational requirements for maintaining historical data on the cluster against CPU and storage resources.
+Longer retention periods increase the need for storage and require additional CPU to manage data indexing.
diff --git a/modules/telco-core-networking.adoc b/modules/telco-core-networking.adoc
new file mode 100644
index 000000000000..f3a7224ef2a4
--- /dev/null
+++ b/modules/telco-core-networking.adoc
@@ -0,0 +1,61 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-networking_{context}"]
+= Networking
+
+The following diagram describes the telco core reference design networking configuration.
+
+.Telco core reference design networking configuration
+image::openshift-telco-core-rds-networking.png[Overview of the telco core reference design networking configuration]
+
+New in this release::
++
+--
+// https://issues.redhat.com/browse/CNF-12678
+* Support for disabling vendor plugins in the SR-IOV Operator
+
+// https://issues.redhat.com/browse/CNF-13768
+* link:https://access.redhat.com/articles/7090422[New knowledge base article on creating custom node firewall rules]
+
+// https://issues.redhat.com/browse/CNF-13981
+* Extended telco core RDS validation with MetalLB and EgressIP telco QE validation
+
+// https://issues.redhat.com/browse/CNF-14150
+* FRR-K8s is now available under the Cluster Network Operator.
++
+[NOTE]
+====
+If you have custom `FRRConfiguration` CRs in the `metallb-system` namespace, you must move them under the `openshift-network-operator` namespace.
+====
+--
+
+Description::
++
+--
+* The cluster is configured for dual-stack IP (IPv4 and IPv6).
+* The validated physical network configuration consists of two dual-port NICs.
+One NIC is shared among the primary CNI (OVN-Kubernetes) and IPVLAN and MACVLAN traffic, while the second one is dedicated to SR-IOV VF-based pod traffic.
+* A Linux bonding interface (`bond0`) is created in active-active IEEE 802.3ad LACP mode with the two NIC ports attached.
+The top-of-rack networking equipment must support and be configured for multi-chassis link aggregation (mLAG) technology.
+* VLAN interfaces are created on top of `bond0`, including for the primary CNI.
+* Bond and VLAN interfaces are created at cluster install time during the network configuration stage of the installation.
+Except for the `vlan0` VLAN used by the primary CNI, all other VLANs can be created during Day 2 activities with the Kubernetes NMstate Operator.
+* MACVLAN and IPVLAN interfaces are created with their corresponding CNIs.
+They do not share the same base interface.
+For more information, see "Cluster Network Operator".
+* SR-IOV VFs are managed by the SR-IOV Network Operator.
+* To ensure consistent source IP addresses for pods behind a LoadBalancer Service, configure an `EgressIP` CR and specify the `podSelector` parameter.
+* You can implement service traffic separation by doing the following:
+.. Configure VLAN interfaces and specific kernel IP routes on the nodes using `NodeNetworkConfigurationPolicy` CRs.
+.. Create a MetalLB `BGPPeer` CR for each VLAN to establish peering with the remote BGP router.
+.. Define a MetalLB `BGPAdvertisement` CR to specify which IP address pools should be advertised to a selected list of `BGPPeer` resources.
++
+The following diagram illustrates how specific service IP addresses are advertised to the outside via specific VLAN interfaces.
+Services routes are defined in `BGPAdvertisement` CRs and configured with values for `IPAddressPool1` and `BGPPeer1` fields.
+--
+
+.Telco core reference design MetalLB service separation
+image::openshift-telco-core-rds-metallb-service-separation.png[Telco core reference design MetalLB service separation]
diff --git a/modules/telco-core-nmstate-operator.adoc b/modules/telco-core-nmstate-operator.adoc
new file mode 100644
index 000000000000..b9dad0a1a284
--- /dev/null
+++ b/modules/telco-core-nmstate-operator.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-nmstate-operator_{context}"]
+= NMState Operator
+
+New in this release::
+* No reference design updates in this release
+
+Description::
+The Kubernetes NMState Operator provides a Kubernetes API for performing state-driven network configuration across cluster nodes.
+It enables network interface configurations, static IPs and DNS, VLANs, trunks, bonding, static routes, MTU, and enabling promiscuous mode on the secondary interfaces.
+The cluster nodes periodically report on the state of each node's network interfaces to the API server.
+
+Limits and requirements::
+Not applicable
+
+Engineering considerations::
+* Initial networking configuration is applied using `NMStateConfig` content in the installation CRs.
+The NMState Operator is used only when required for network updates.
+* When SR-IOV virtual functions are used for host networking, the NMState Operator (via `nodeNetworkConfigurationPolicy` CRs) is used to configure VF interfaces, such as VLANs and MTU.
diff --git a/modules/telco-core-node-configuration.adoc b/modules/telco-core-node-configuration.adoc
index dc3a4ee31448..fa365f24337d 100644
--- a/modules/telco-core-node-configuration.adoc
+++ b/modules/telco-core-node-configuration.adoc
@@ -1,40 +1,42 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-node-configuration_{context}"]
-= Node configuration
+= Node Configuration
 
 New in this release::
-//CNF-12344
-//CNF-12345
-* Container mount namespace encapsulation and kdump are now available in the {rds} RDS.
-
-Description::
-* Container mount namespace encapsulation creates a container mount namespace that reduces system mount scanning and is visible to kubelet and CRI-O.
-* kdump is an optional configuration that is enabled by default that captures debug information when a kernel panic occurs.
-The reference CRs which enable kdump include an increased memory reservation based on the set of drivers and kernel modules included in the reference configuration.
+* No reference design updates in this release
 
 Limits and requirements::
-* Use of kdump and container mount namespace encapsulation is made available through additional kernel modules.
-You should analyze these modules to determine impact on CPU load, system performance, and ability to meet required KPIs.
+* Analyze additional kernel modules to determine impact on CPU load, system performance, and ability to meet KPIs.
++
+--
+.Additional kernel modules
+|====
+|Feature|Description
+
+|Additional kernel modules
+a|Install the following kernel modules by using `MachineConfig` CRs to provide extended kernel functionality to CNFs.
 
-Engineering considerations::
-* Install the following kernel modules with `MachineConfig` CRs.
-These modules provide extended kernel functionality to cloud-native functions (CNFs).
+* sctp
+* ip_gre
+* ip6_tables
+* ip6t_REJECT
+* ip6table_filter
+* ip6table_mangle
+* iptable_filter
+* iptable_mangle
+* iptable_nat
+* xt_multiport
+* xt_owner
+* xt_REDIRECT
+* xt_statistic
+* xt_TCPMSS
 
-** sctp
-** ip_gre
-** ip6_tables
-** ip6t_REJECT
-** ip6table_filter
-** ip6table_mangle
-** iptable_filter
-** iptable_mangle
-** iptable_nat
-** xt_multiport
-** xt_owner
-** xt_REDIRECT
-** xt_statistic
-** xt_TCPMSS
+|Container mount namespace hiding|Reduce the frequency of kubelet housekeeping and eviction monitoring to reduce CPU usage.
+Creates a container mount namespace, visible to kubelet/CRI-O, to reduce system mount scanning overhead.
+|Kdump enable|Optional configuration (enabled by default)
+|====
+--
diff --git a/modules/telco-core-openshift-data-foundation.adoc b/modules/telco-core-openshift-data-foundation.adoc
new file mode 100644
index 000000000000..3424c3612c95
--- /dev/null
+++ b/modules/telco-core-openshift-data-foundation.adoc
@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-openshift-data-foundation_{context}"]
+= Red Hat OpenShift Data Foundation
+
+New in this release::
+* No reference design updates in this release
+
+Description::
+{rh-storage-first} is a software-defined storage service for containers.
+For telco core clusters, storage support is provided by {rh-storage} storage services running externally to the application workload cluster.
+{rh-storage} supports separation of storage traffic using secondary CNI networks.
+
+Limits and requirements::
+* In an IPv4/IPv6 dual-stack networking environment, {rh-storage} uses IPv4 addressing.
+For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html/planning_your_deployment/network-requirements_rhodf#network-requirements_rhodf[Network requirements].
+
+Engineering considerations::
+* {rh-storage} network traffic should be isolated from other traffic on a dedicated network, for example, by using VLAN isolation.
diff --git a/modules/telco-core-power-management.adoc b/modules/telco-core-power-management.adoc
index 8ba4c636b235..ca1a5f0bd456 100644
--- a/modules/telco-core-power-management.adoc
+++ b/modules/telco-core-power-management.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-power-management_{context}"]
@@ -12,9 +12,12 @@ New in this release::
 Description::
 Use the Performance Profile to configure clusters with high power mode, low power mode, or mixed mode.
 The choice of power mode depends on the characteristics of the workloads running on the cluster, particularly how sensitive they are to latency.
+Configure the maximum latency for a low-latency pod by using the per-pod power management C-states feature.
 
 Limits and requirements::
-* Power configuration relies on appropriate BIOS configuration, for example, enabling C-states and P-states. Configuration varies between hardware vendors.
+* Power configuration relies on appropriate BIOS configuration, for example, enabling C-states and P-states.
+Configuration varies between hardware vendors.
 
 Engineering considerations::
-* Latency: To ensure that latency-sensitive workloads meet their requirements, you will need either a high-power configuration or a per-pod power management configuration. Per-pod power management is only available for `Guaranteed` QoS Pods with dedicated pinned CPUs.
+* Latency: To ensure that latency-sensitive workloads meet requirements, you require a high-power or a per-pod power management configuration.
+Per-pod power management is only available for Guaranteed QoS pods with dedicated pinned CPUs.
diff --git a/modules/telco-core-rds-container.adoc b/modules/telco-core-rds-container.adoc
index 81451665e335..070cebc36ce0 100644
--- a/modules/telco-core-rds-container.adoc
+++ b/modules/telco-core-rds-container.adoc
@@ -24,7 +24,7 @@ $ mkdir -p ./out
 +
 [source,terminal]
 ----
-$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
+$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out
 ----
 
 .Verification
diff --git a/modules/telco-core-rds-disconnected.adoc b/modules/telco-core-rds-disconnected.adoc
deleted file mode 100644
index e513a26fc029..000000000000
--- a/modules/telco-core-rds-disconnected.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-disconnected-environment_{context}"]
-= Disconnected environment
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-{rds-caps} clusters are expected to be installed in networks without direct access to the internet.
-All container images needed to install, configure, and operator the cluster must be available in a disconnected registry.
-This includes {product-title} images, Day 2 Operator Lifecycle Manager (OLM) Operator images, and application workload images.
-
-Limits and requirements::
-* A unique name is required for all custom CatalogSources. Do not reuse the default catalog names.
-* A valid time source must be configured as part of cluster installation.
diff --git a/modules/telco-core-rds-networking.adoc b/modules/telco-core-rds-networking.adoc
deleted file mode 100644
index 07ffe88a0e6e..000000000000
--- a/modules/telco-core-rds-networking.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-networking_{context}"]
-= Networking
-
-New in this release::
-//CNF-10593
-* Telco core validation is now extended with bonding, MACVLAN, IPVLAN and SR-IOV networking scenarios.
-
-Description::
-* The cluster is configured in dual-stack IP configuration (IPv4 and IPv6).
-
-* The validated physical network configuration consists of two dual-port NICs.
-One NIC is shared among the primary CNI (OVN-Kubernetes) and IPVLAN and MACVLAN traffic, the second NIC is dedicated to SR-IOV VF-based Pod traffic.
-
-* A Linux bonding interface (`bond0`) is created in an active-active LACP `IEEE 802.3ad` configuration with the two NIC ports attached.
-+
-[NOTE]
-====
-The top-of-rack networking equipment must support and be configured for multi-chassis link aggregation (mLAG) technology.
-====
-
-* VLAN interfaces are created on top of `bond0`, including for the primary CNI.
-
-* Bond and VLAN interfaces are created at install time during network configuration.
-Apart from the VLAN (`VLAN0`) used by the primary CNI, the other VLANS can be created on Day 2 using the Kubernetes NMState Operator.
-
-* MACVLAN and IPVLAN interfaces are created with their corresponding CNIs.
-They do not share the same base interface.
-
-* SR-IOV VFs are managed by the SR-IOV Network Operator.
-The following diagram provides an overview of SR-IOV NIC sharing:
-+
-.SR-IOV NIC sharing
-image::313_OpenShift_SR-IOV_NIC_sharing_0323.png[Simplified SR-IOV NIC sharing configuration]
diff --git a/modules/telco-core-rds-product-version-use-model-overview.adoc b/modules/telco-core-rds-product-version-use-model-overview.adoc
new file mode 100644
index 000000000000..a04bb1982c46
--- /dev/null
+++ b/modules/telco-core-rds-product-version-use-model-overview.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-rds-product-version-use-model-overview_{context}"]
+= Telco core RDS {product-version} use model overview
+
+The telco core reference design specifications (RDS) describes a platform that supports large-scale telco applications, including control plane functions such as signaling and aggregation.
+It also includes some centralized data plane functions, such as user plane functions (UPF).
+These functions generally require scalability, complex networking support, resilient software-defined storage, and support performance requirements that are less stringent and constrained than far-edge deployments such as RAN.
diff --git a/modules/telco-core-red-hat-advanced-cluster-management-rhacm.adoc b/modules/telco-core-red-hat-advanced-cluster-management-rhacm.adoc
deleted file mode 100644
index 8de9073dc4cb..000000000000
--- a/modules/telco-core-red-hat-advanced-cluster-management-rhacm.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-ran-core-hat-advanced-cluster-management-rhacm_{context}"]
-= {rh-rhacm-title}
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-{rh-rhacm-first} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters.
-You manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
-+
-You apply policies with the {rh-rhacm} policy controller as managed by {cgu-operator-first}.
-+
-When installing managed clusters, {rh-rhacm} applies labels and initial ignition configuration to individual nodes in support of custom disk partitioning, allocation of roles, and allocation to machine config pools.
-You define these configurations with `SiteConfig` or `ClusterInstance` CRs.
-
-Limits and requirements::
-* Size your cluster according to the limits specified in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/install/index#sizing-your-cluster[Sizing your cluster].
-* {rh-rhacm} scaling limits are described in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/install/index#performance-and-scalability[Performance and scalability].
-
-Engineering considerations::
-* Use {rh-rhacm} policy hub-side templating to better scale cluster configuration.
-You can significantly reduce the number of policies by using a single group policy or small number of general group policies where the group and per-cluster values are substituted into templates.
-
-* Cluster specific configuration: managed clusters typically have some number of configuration values that are specific to the individual cluster.
-These configurations should be managed using {rh-rhacm} policy hub-side templating with values pulled from `ConfigMap` CRs based on the cluster name.
diff --git a/modules/telco-core-red-hat-advanced-cluster-management.adoc b/modules/telco-core-red-hat-advanced-cluster-management.adoc
new file mode 100644
index 000000000000..e304a1a5de54
--- /dev/null
+++ b/modules/telco-core-red-hat-advanced-cluster-management.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-red-hat-advanced-cluster-management_{context}"]
+= Red Hat Advanced Cluster Management
+
+New in this release::
+* No reference design updates in this release
+
+Description::
++
+--
+{rh-rhacm-first} provides Multi Cluster Engine (MCE) installation and ongoing {ztp} lifecycle management for deployed clusters.
+You manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
+
+You apply policies with the {rh-rhacm} policy controller as managed by {cgu-operator-full}.
+Configuration, upgrades, and cluster status are managed through the policy controller.
+
+When installing managed clusters, {rh-rhacm} applies labels and initial ignition configuration to individual nodes in support of custom disk partitioning, allocation of roles, and allocation to machine config pools.
+You define these configurations with `SiteConfig` or `ClusterInstance` CRs.
+--
+
+Limits and requirements::
+
+* Hub cluster sizing is discussed in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/install/index#sizing-your-cluster[Sizing your cluster].
+
+* {rh-rhacm} scaling limits are described in link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/install/index#performance-and-scalability[Performance and Scalability].
+
+Engineering considerations::
+* When managing multiple clusters with unique content per installation, site, or deployment, using {rh-rhacm} hub templating is strongly recommended.
+{rh-rhacm} hub templating allows you to apply a consistent set of policies to clusters while providing for unique values per installation.
diff --git a/modules/telco-core-ref-application-workloads.adoc b/modules/telco-core-ref-application-workloads.adoc
deleted file mode 100644
index 300dcf094d2d..000000000000
--- a/modules/telco-core-ref-application-workloads.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-ref-application-workloads_{context}"]
-= Application workloads
-
-Application workloads running on core clusters might include a mix of high-performance networking CNFs and traditional best-effort or burstable pod workloads.
-
-Guaranteed QoS scheduling is available to pods that require exclusive or dedicated use of CPUs due to performance or security requirements. Typically pods hosting high-performance and low-latency-sensitive Cloud Native Functions (CNFs) utilizing user plane networking with DPDK necessitate the exclusive utilization of entire CPUs. This is accomplished through node tuning and guaranteed Quality of Service (QoS) scheduling. For pods that require exclusive use of CPUs, be aware of the potential implications of hyperthreaded systems and configure them to request multiples of 2 CPUs when the entire core (2 hyperthreads) must be allocated to the pod.
-
-Pods running network functions that do not require the high throughput and low latency networking are typically scheduled with best-effort or burstable QoS and do not require dedicated or isolated CPU cores.
-
-Workload limits::
-* CNF applications should conform to the latest version of the link:https://redhat-best-practices-for-k8s.github.io/guide/[Red Hat{nbsp}Best Practices for Kubernetes] guide.
-* For a mix of best-effort and burstable QoS pods.
-** Guaranteed QoS pods might be used but require correct configuration of reserved and isolated CPUs in the `PerformanceProfile`.
-** Guaranteed QoS Pods must include annotations for fully isolating CPUs.
-** Best effort and burstable pods are not guaranteed exclusive use of a CPU. Workloads might be preempted by other workloads, operating system daemons, or kernel tasks.
-* Exec probes should be avoided unless there is no viable alternative.
-** Do not use exec probes if a CNF is using CPU pinning.
-** Other probe implementations, for example `httpGet/tcpSocket`, should be used.
-
-+
-[NOTE]
-====
-Startup probes require minimal resources during steady-state operation.
-The limitation on exec probes applies primarily to liveness and readiness probes.
-====
-
-Signaling workload::
-* Signaling workloads typically use SCTP, REST, gRPC, or similar TCP or UDP protocols.
-* The transactions per second (TPS) is in the order of hundreds of thousands using secondary CNI (multus) configured as MACVLAN or SR-IOV.
-* Signaling workloads run in pods with either guaranteed or burstable QoS.
diff --git a/modules/telco-core-ref-config-scale-testing.adoc b/modules/telco-core-ref-config-scale-testing.adoc
deleted file mode 100644
index c1b9fb51ca6a..000000000000
--- a/modules/telco-core-ref-config-scale-testing.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/ran/telco-ran-ref-validation-artifacts.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-ref-config-scale-testing_{context}"]
-= Telco core scale test results
-
-The Red Hat performance and scale lab successfully
-
-Scale tests are run with a representative three-node hub cluster with the following specifications and lab network configurations applied.
\ No newline at end of file
diff --git a/modules/telco-core-ref-design-baseline-model.adoc b/modules/telco-core-ref-design-baseline-model.adoc
deleted file mode 100644
index cdcb199996f8..000000000000
--- a/modules/telco-core-ref-design-baseline-model.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-ref-design-baseline-model_{context}"]
-= Common baseline model
-
-The following configurations and use model description are applicable to all {rds} use cases.
-
-Cluster::
-
-The cluster conforms to these requirements:
-
-* High-availability (3+ supervisor nodes) control plane
-* Non-schedulable supervisor nodes
-* Multiple `MachineConfigPool` resources
-
-Storage::
-
-Core use cases require persistent storage as provided by external {rh-storage}. For more information, see the "Storage" subsection in "Reference core design components".
-
-Networking::
-
-{rds-caps} clusters networking conforms to these requirements:
-
-* Dual stack IPv4/IPv6
-
-* Fully disconnected: Clusters do not have access to public networking at any point in their lifecycle.
-
-* Multiple networks: Segmented networking provides isolation between OAM, signaling, and storage traffic.
-
-* Cluster network type: OVN-Kubernetes is required for IPv6 support.
-
-+
-Core clusters have multiple layers of networking supported by underlying RHCOS, SR-IOV Operator, Load Balancer, and other components detailed in the following "Networking" section. At a high level these layers include:
-
-* Cluster networking: The cluster network configuration is defined and applied through the installation configuration. Updates to the configuration can be done at Day 2 through the NMState Operator. Initial configuration can be used to establish:
-
-** Host interface configuration
-
-** Active/Active Bonding (Link Aggregation Control Protocol (LACP))
-
-* Secondary or additional networks: OpenShift CNI is configured through the Network `additionalNetworks` or NetworkAttachmentDefinition CRs.
-
-** MACVLAN
-
-* Application Workload: User plane networking is running in cloud-native network functions (CNFs).
-
-Service Mesh::
-
-Use of Service Mesh by telco CNFs is very common. It is expected that all core clusters will include a Service Mesh implementation. Service Mesh implementation and configuration is outside the scope of this specification.
diff --git a/modules/telco-core-ref-eng-usecase-model.adoc b/modules/telco-core-ref-eng-usecase-model.adoc
deleted file mode 100644
index e6cfeeb36703..000000000000
--- a/modules/telco-core-ref-eng-usecase-model.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-ref-eng-usecase-model_{context}"]
-= Telco core RDS engineering considerations
-
-The following engineering considerations are relevant for the telco core common use model.
-
-Worker nodes::
-* Worker nodes should run on Intel 3rd Generation Xeon (IceLake) processors or newer.
-+
-[NOTE]
-====
-Alternatively, if your worker nodes have Skylake or earlier processors, you must disable the mitigations for silicon security vulnerabilities such as Spectre.
-Failure to do can result in a 40% decrease in transaction performance.
-====
-
-* Enable IRQ Balancing for worker nodes.
-Set the `globallyDisableIrqLoadBalancing` field in the `PerformanceProfile` custom resource (CR) to `false`.
-Annotate pods with QoS class of `Guaranteed` to ensure that they are isolated.
-See "CPU partitioning and performance tuning" for more information.
-
-All nodes in the cluster::
-* Enable Hyper-Threading for all nodes.
-* Ensure CPU architecture is `x86_64` only.
-* Ensure that nodes are running the stock (non-RT) kernel.
-* Ensure that nodes are not configured for workload partitioning.
-
-Power management and performance::
-* The balance between power management and maximum performance varies between the `MachineConfigPool` resources in the cluster.
-
-Cluster scaling::
-* Scale number of cluster nodes to at least 120 nodes.
-
-CPU partitioning::
-* CPU partitioning is configured using `PerformanceProfile` CRs, one for every `MachineConfigPool` CR in the cluster.
-See "CPU partitioning and performance tuning" for more information.
diff --git a/modules/telco-core-scalability.adoc b/modules/telco-core-scalability.adoc
index 00a4ef9034bd..0d9bf84ea0a4 100644
--- a/modules/telco-core-scalability.adoc
+++ b/modules/telco-core-scalability.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-scalability_{context}"]
@@ -9,5 +9,8 @@
 New in this release::
 * No reference design updates in this release
 
+Description::
+Scaling of workloads is described in "Application workloads".
+
 Limits and requirements::
-* Cluster should scale to at least 120 nodes.
+* Cluster can scale to at least 120 nodes.
diff --git a/modules/telco-core-scheduling.adoc b/modules/telco-core-scheduling.adoc
index caf1e1cdec4c..fe8bfe7c05fd 100644
--- a/modules/telco-core-scheduling.adoc
+++ b/modules/telco-core-scheduling.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-scheduling_{context}"]
@@ -10,17 +10,31 @@ New in this release::
 * No reference design updates in this release
 
 Description::
-* The scheduler is a cluster-wide component responsible for selecting the right node for a given workload. It is a core part of the platform and does not require any specific configuration in the common deployment scenarios. However, there are few specific use cases described in the following section.
++
+--
+The scheduler is a cluster-wide component responsible for selecting the correct node for a given workload.
+It is a core part of the platform and does not require any specific configuration in the common deployment scenarios.
+However, a few specific use cases are described in the following section.
+
 NUMA-aware scheduling can be enabled through the NUMA Resources Operator.
 For more information, see "Scheduling NUMA-aware workloads".
+--
 
 Limits and requirements::
-* The default scheduler does not understand the NUMA locality of workloads. It only knows about the sum of all free resources on a worker node. This might cause workloads to be rejected when scheduled to a node with the topology manager policy set to `single-numa-node` or `restricted`.
-** For example, consider a pod requesting 6 CPUs and being scheduled to an empty node that has 4 CPUs per NUMA node. The total allocatable capacity of the node is 8 CPUs and the scheduler will place the pod there. The node local admission will fail, however, as there are only 4 CPUs available in each of the NUMA nodes.
-** All clusters with multi-NUMA nodes are required to use the NUMA Resources Operator. Use the `machineConfigPoolSelector` field in the `KubeletConfig` CR to select all nodes where NUMA aligned scheduling is needed.
-* All machine config pools must have consistent hardware configuration for example all nodes are expected to have the same NUMA zone count.
+* The default scheduler does not understand the NUMA locality of workloads.
+It only knows about the sum of all free resources on a worker node.
+This might cause workloads to be rejected when scheduled to a node with the topology manager policy set to `single-numa-node` or `restricted`.
+For more information, see "Topology Manager policies".
+** For example, consider a pod requesting 6 CPUs that is scheduled to an empty node that has 4 CPUs per NUMA node.
+The total allocatable capacity of the node is 8 CPUs. The scheduler places the pod on the empty node.
+The node local admission fails, as there are only 4 CPUs available in each of the NUMA nodes.
+* All clusters with multi-NUMA nodes are required to use the NUMA Resources Operator.
+See "Installing the NUMA Resources Operator" for more information.
+Use the `machineConfigPoolSelector` field in the `KubeletConfig` CR to select all nodes where NUMA aligned scheduling is required.
+* All machine config pools must have consistent hardware configuration.
+For example, all nodes are expected to have the same NUMA zone count.
 
 Engineering considerations::
-* Pods might require annotations for correct scheduling and isolation. For more information on annotations, see "CPU partitioning and performance tuning".
-
+* Pods might require annotations for correct scheduling and isolation.
+For more information about annotations, see "CPU partitioning and performance tuning".
 * You can configure SR-IOV virtual function NUMA affinity to be ignored during scheduling by using the `excludeTopology` field in `SriovNetworkNodePolicy` CR.
diff --git a/modules/telco-core-security.adoc b/modules/telco-core-security.adoc
index fb30ace2f7b5..548d7773bf2c 100644
--- a/modules/telco-core-security.adoc
+++ b/modules/telco-core-security.adoc
@@ -1,31 +1,69 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-security_{context}"]
 = Security
 
 New in this release::
-//CNF-11806
-* Secure boot host firmware setting is now recommended for telco core clusters.
-For more information, see "Host firmware and boot loader configuration".
+// https://issues.redhat.com/browse/CNF-13768
+* link:https://access.redhat.com/articles/7090422[New knowledgebase article on creating custom node firewall rules]
 
 Description::
-You should harden clusters against multiple attack vectors.
++
+--
+Telco customers are security conscious and require clusters to be hardened against multiple attack vectors.
 In {product-title}, there is no single component or feature responsible for securing a cluster.
 Use the following security-oriented features and configurations to secure your clusters:
 
 * **SecurityContextConstraints (SCC)**: All workload pods should be run with `restricted-v2` or `restricted` SCC.
-* **Seccomp**: All pods should be run with the `RuntimeDefault` (or stronger) seccomp profile.
-* **Rootless DPDK pods**: Many user-plane networking (DPDK) CNFs require pods to run with root privileges. With this feature, a conformant DPDK pod can be run without requiring root privileges.
+* **Seccomp**: All pods should run with the `RuntimeDefault` (or stronger) seccomp profile.
+* **Rootless DPDK pods**: Many user-plane networking (DPDK) CNFs require pods to run with root privileges.
+With this feature, a conformant DPDK pod can run without requiring root privileges.
 Rootless DPDK pods create a tap device in a rootless pod that injects traffic from a DPDK application to the kernel.
-* **Storage**: The storage network should be isolated and non-routable to other cluster networks. See the "Storage" section for additional details.
+* **Storage**: The storage network should be isolated and non-routable to other cluster networks.
+See the "Storage" section for additional details.
+
+Refer to link:https://access.redhat.com/articles/7090422[Custom nftable firewall rules in OpenShift] for a supported method of implementing custom nftables firewall rules in OpenShift cluster nodes.
+This article is intended for cluster administrators who are responsible for managing network security policies in OpenShift environments.
+It is crucial to carefully consider the operational implications before deploying this method, including:
+
+* **Early application**: The rules are applied at boot time, before the network is fully operational.
+Ensure the rules don't inadvertently block essential services required during the boot process.
+
+* **Risk of misconfiguration**: Errors in your custom rules can lead to unintended consequences, potentially leading to performance impact or blocking legitimate traffic or isolating nodes.
+Thoroughly test your rules in a non-production environment before deploying them to your main cluster.
+
+* **External endpoints**: OpenShift requires access to external endpoints to function.
+For more information about the firewall allowlist, see "Configuring your firewall for {product-title}".
+Ensure that cluster nodes are permitted access to those endpoints.
+
+* **Node reboot**: Unless node disruption policies are configured, applying the `MachineConfig` CR with the required firewall settings causes a node reboot.
+Be aware of this impact and schedule a maintenance window accordingly.
+For more information, see "Using node disruption policies to minimize disruption from machine config changes".
++
+[NOTE]
+====
+Node disruption policies are available in {product-title} 4.17 and later.
+====
+
+* **Network flow matrix**: For more information about managing ingress traffic, see "{product-title} network flow matrix".
+You can restrict ingress traffic to essential flows to improve network security.
+The matrix provides insights into base cluster services but excludes traffic generated by Day-2 Operators.
+
+* **Cluster version updates and upgrades**: Exercise caution when updating or upgrading OpenShift clusters.
+Recent changes to the platform's firewall requirements might require adjustments to network port permissions.
+Although the documentation provides guidelines, note that these requirements can evolve over time.
+To minimize disruptions, you should test any updates or upgrades in a staging environment before applying them in production.
+This helps you to identify and address potential compatibility issues related to firewall configuration changes.
+--
 
 Limits and requirements::
-* Rootless DPDK pods requires the following additional configuration steps:
-** Configure the TAP plugin with the `container_t` SELinux context.
-** Enable the `container_use_devices` SELinux boolean on the hosts.
+* Rootless DPDK pods requires the following additional configuration:
+** Configure the `container_t` SELinux context for the tap plugin.
+** Enable the `container_use_devices` SELinux boolean for the cluster host.
 
 Engineering considerations::
-* For rootless DPDK pod support, the SELinux boolean `container_use_devices` must be enabled on the host for the TAP device to be created. This introduces a security risk that is acceptable for short to mid-term use. Other solutions will be explored.
+* For rootless DPDK pod support, enable the SELinux `container_use_devices` boolean on the host to allow the tap device to be created.
+This introduces an acceptable security risk.
diff --git a/modules/telco-core-service-mesh.adoc b/modules/telco-core-service-mesh.adoc
index ac37352d107f..315bbb3a3650 100644
--- a/modules/telco-core-service-mesh.adoc
+++ b/modules/telco-core-service-mesh.adoc
@@ -1,17 +1,13 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-service-mesh_{context}"]
-= Service Mesh
+= Service mesh
 
 Description::
-{rds-caps} cloud-native functions (CNFs) typically require a service mesh implementation.
-+
-[NOTE]
-====
+Telco core cloud-native functions (CNFs) typically require a service mesh implementation.
 Specific service mesh features and performance requirements are dependent on the application.
 The selection of service mesh implementation and configuration is outside the scope of this documentation.
 You must account for the impact of service mesh on cluster resource usage and performance, including additional latency introduced in pod networking, in your implementation.
-====
diff --git a/modules/telco-core-signaling-workloads.adoc b/modules/telco-core-signaling-workloads.adoc
new file mode 100644
index 000000000000..c9042e6b5a9a
--- /dev/null
+++ b/modules/telco-core-signaling-workloads.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-signaling-workloads_{context}"]
+= Signaling workloads
+
+Signaling workloads typically use SCTP, REST, gRPC or similar TCP or UDP protocols.
+Signaling workloads support hundreds of thousands of transactions per second (TPS) by using a secondary multus CNI configured as MACVLAN or SR-IOV interface.
+These workloads can run in pods with either guaranteed or burstable QoS.
diff --git a/modules/telco-core-software-stack.adoc b/modules/telco-core-software-stack.adoc
index 1d2cd1a7a801..528fad6feb17 100644
--- a/modules/telco-core-software-stack.adoc
+++ b/modules/telco-core-software-stack.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-software-artifacts.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-software-stack_{context}"]
@@ -13,21 +13,27 @@ The Red{nbsp}Hat telco core {product-version} solution has been validated using
 |====
 |Component |Software version
 
+|{rh-rhacm-first}
+|2.12^1^
+
 |Cluster Logging Operator
-|6.0
+|6.1^2^
 
 |{rh-storage}
-|4.17
+|4.18
 
-|SR-IOV Operator
-|4.17
+|SR-IOV Network Operator
+|4.18
 
 |MetalLB
-|4.17
+|4.18
 
 |NMState Operator
-|4.17
+|4.18
 
 |NUMA-aware scheduler
-|4.17
+|4.18
 |====
+[1] This table will be updated when the aligned {rh-rhacm} version 2.13 is released.
+
+[2] This table will be updated when the aligned Cluster Logging Operator 6.2 is released.
diff --git a/modules/telco-core-sr-iov.adoc b/modules/telco-core-sr-iov.adoc
new file mode 100644
index 000000000000..f26bc44961dc
--- /dev/null
+++ b/modules/telco-core-sr-iov.adoc
@@ -0,0 +1,39 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-sr-iov_{context}"]
+= SR-IOV
+
+New in this release::
+// https://issues.redhat.com/browse/CNF-12678
+* You can now create virtual functions for Mellanox NICs with the SR-IOV Network Operator when secure boot is enabled in the cluster host.
+Before you can create the virtual functions, you must first skip the firmware configuration for the Mellanox NIC and manually allocate the number of virtual functions in the firmware before switching the system to secure boot.
+
+Description::
+SR-IOV enables physical functions (PFs) to be divided into multiple virtual functions (VFs).
+VFs can then be assigned to multiple pods to achieve higher throughput performance while keeping the pods isolated.
+The SR-IOV Network Operator provisions and manages SR-IOV CNI, network device plugin, and other components of the SR-IOV stack.
+
+Limits and requirements::
+* Only certain network interfaces are supported.
+See "Supported devices" for more information.
+
+* Enabling SR-IOV and IOMMU: the SR-IOV Network Operator automatically enables IOMMU on the kernel command line.
+
+* SR-IOV VFs do not receive link state updates from the PF.
+If a link down detection is required, it must be done at the protocol level.
+
+* `MultiNetworkPolicy` CRs can be applied to `netdevice` networks only.
+This is because the implementation uses iptables, which cannot manage vfio interfaces.
+
+Engineering considerations::
+* SR-IOV interfaces in `vfio` mode are typically used to enable additional secondary networks for applications that require high throughput or low latency.
+* The `SriovOperatorConfig` CR must be explicitly created.
+This CR is included in the reference configuration policies, which causes it to be created during initial deployment.
+* NICs that do not support firmware updates with UEFI secure boot or kernel lockdown must be preconfigured with sufficient virtual functions (VFs) enabled to support the number of VFs required by the application workload.
+For Mellanox NICs, you must disable the Mellanox vendor plugin in the SR-IOV Network Operator.
+See "Configuring an SR-IOV network device" for more information.
+* To change the MTU value of a VF after the pod has started, do not configure the `SriovNetworkNodePolicy` MTU field.
+Instead, use the Kubernetes NMState Operator to set the MTU of the related PF.
diff --git a/modules/telco-core-sriov.adoc b/modules/telco-core-sriov.adoc
deleted file mode 100644
index 31dd0d5cce81..000000000000
--- a/modules/telco-core-sriov.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-sriov_{context}"]
-= SR-IOV
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-SR-IOV enables physical network interfaces (PFs) to be divided into multiple virtual functions (VFs). VFs can then be assigned to multiple pods to achieve higher throughput performance while keeping the pods isolated. The SR-IOV Network Operator provisions and manages SR-IOV CNI, network device plugin, and other components of the SR-IOV stack.
-
-Limits and requirements::
-* Supported network interface controllers are listed in "Supported devices".
-* The SR-IOV Network Operator automatically enables IOMMU on the kernel command line.
-* SR-IOV VFs do not receive link state updates from PF. If link down detection is needed, it must be done at the protocol level.
-* `MultiNetworkPolicy` CRs can be applied to `netdevice` networks only.
-This is because the implementation uses the `iptables` tool, which cannot manage `vfio` interfaces.
-
-Engineering considerations::
-* SR-IOV interfaces in `vfio` mode are typically used to enable additional secondary networks for applications that require high throughput or low latency.
-
-* If you exclude the `SriovOperatorConfig` CR from your deployment, the CR will not be created automatically.
-
-* NICs that do not support firmware updates under secure boot or kernel lock-down must be pre-configured with enough VFs enabled to support the number of VFs needed by the application workload.
-+
-[NOTE]
-====
-The SR-IOV Network Operator plugin for these NICs might need to be disabled using the undocumented `disablePlugins` option.
-====
diff --git a/modules/telco-core-storage.adoc b/modules/telco-core-storage.adoc
index 9e5a75d7ecc3..6f72cb429afb 100644
--- a/modules/telco-core-storage.adoc
+++ b/modules/telco-core-storage.adoc
@@ -1,32 +1,28 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-storage_{context}"]
 = Storage
 
-Cloud native storage services can be provided by multiple solutions including {rh-storage} from Red Hat or third parties.
-
-[id="telco-core-rh-storage_{context}"]
-== {rh-storage}
-
 New in this release::
 * No reference design updates in this release
 
 Description::
-{rh-storage-first} is a software-defined storage service for containers.
-For {rds-caps} clusters, storage support is provided by {rh-storage} storage services running externally to the application workload cluster.
-
-Limits and requirements::
-* In an IPv4/IPv6 dual-stack networking environment, {rh-storage} uses IPv4 addressing. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.13/html-single/4.13_release_notes/index#support_openshift_dual_stack_with_odf_using_ipv4[Support OpenShift dual stack with {rh-storage} using IPv4].
++
+--
+Cloud native storage services can be provided by {rh-storage-first} or other third-party solutions.
 
-Engineering considerations::
-* {rh-storage} network traffic should be isolated from other traffic on a dedicated network, for example, by using VLAN isolation.
+{rh-storage} is a Ceph-based software-defined storage solution for containers.
+It provides block storage, file system storage, and on-premise object storage, which can be dynamically provisioned for both persistent and non-persistent data requirements.
+Telco core applications require persistent storage.
 
-* Other storage solutions can be used to provide persistent storage for core clusters.
-+
 [NOTE]
 ====
-The configuration and integration of these solutions is outside the scope of the {rds} RDS. Integration of the storage solution into the core cluster must include correct sizing and performance analysis to ensure the storage meets overall performance and resource utilization requirements.
+All storage data might not be encrypted in flight.
+To reduce risk, isolate the storage network from other cluster networks.
+The storage network must not be reachable, or routable, from other cluster networks.
+Only nodes directly attached to the storage network should be allowed to gain access to it.
 ====
+--
diff --git a/modules/telco-core-topology-aware-lifecycle-manager.adoc b/modules/telco-core-topology-aware-lifecycle-manager.adoc
new file mode 100644
index 000000000000..8361c5debf34
--- /dev/null
+++ b/modules/telco-core-topology-aware-lifecycle-manager.adoc
@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-topology-aware-lifecycle-manager_{context}"]
+= Topology Aware Lifecycle Manager
+
+New in this release::
+No reference design updates in this release.
+
+Description::
+{cgu-operator-full} is an Operator which runs only on the hub cluster.
+{cgu-operator} manages how changes including cluster and Operator upgrades, configurations, and so on, are rolled out to managed clusters in the network.
+{cgu-operator} has the following core features:
+* Provides sequenced updates of cluster configurations and upgrades ({product-title} and Operators) as defined by cluster policies.
+* Provides for deferred application of cluster updates.
+* Supports progressive rollout of policy updates to sets of clusters in user configurable batches.
+* Allows for per-cluster actions by adding `ztp-done` or similar user-defined labels to clusters.
+
+Limits and requirements::
+* Supports concurrent cluster deployments in batches of 400.
+
+Engineering considerations::
+* Only policies with the `ran.openshift.io/ztp-deploy-wave` annotation are applied by {cgu-operator} during initial cluster installation.
+* Any policy can be remediated by {cgu-operator} under control of a user created `ClusterGroupUpgrade` CR.
diff --git a/modules/telco-core-yaml-ref-networking.adoc b/modules/telco-core-yaml-ref-networking.adoc
deleted file mode 100644
index bf142d0236a2..000000000000
--- a/modules/telco-core-yaml-ref-networking.adoc
+++ /dev/null
@@ -1,161 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="networking-yaml_{context}"]
-= Networking reference YAML
-
-[id="telco-core-network-yaml"]
-.Network.yaml
-[source,yaml]
-----
-include::snippets/telco-core_Network.yaml[]
-----
-
-[id="telco-core-networkattachmentdefinition-yaml"]
-.networkAttachmentDefinition.yaml
-[source,yaml]
-----
-include::snippets/telco-core_networkAttachmentDefinition.yaml[]
-----
-
-[id="telco-core-addr-pool-yaml"]
-.addr-pool.yaml
-[source,yaml]
-----
-include::snippets/telco-core_addr-pool.yaml[]
-----
-
-[id="telco-core-bfd-profile-yaml"]
-.bfd-profile.yaml
-[source,yaml]
-----
-include::snippets/telco-core_bfd-profile.yaml[]
-----
-
-[id="telco-core-bgp-advr-yaml"]
-.bgp-advr.yaml
-[source,yaml]
-----
-include::snippets/telco-core_bgp-advr.yaml[]
-----
-
-[id="telco-core-bgp-peer-yaml"]
-.bgp-peer.yaml
-[source,yaml]
-----
-include::snippets/telco-core_bgp-peer.yaml[]
-----
-
-[id="telco-core-community-yaml"]
-.community.yaml
-[source,yaml]
-----
-include::snippets/telco-core_community.yaml[]
-----
-
-[id="telco-core-metallb-yaml"]
-.metallb.yaml
-[source,yaml]
-----
-include::snippets/telco-core_metallb.yaml[]
-----
-
-[id="telco-core-metallbns-yaml"]
-.metallbNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_metallbNS.yaml[]
-----
-
-[id="telco-core-metallbopergroup-yaml"]
-.metallbOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_metallbOperGroup.yaml[]
-----
-
-[id="telco-core-metallbsubscription-yaml"]
-.metallbSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_metallbSubscription.yaml[]
-----
-
-[id="telco-core-mc_rootless_pods_selinux-yaml"]
-.mc_rootless_pods_selinux.yaml
-[source,yaml]
-----
-include::snippets/telco-core_mc_rootless_pods_selinux.yaml[]
-----
-
-[id="telco-core-nmstate-yaml"]
-.NMState.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NMState.yaml[]
-----
-
-[id="telco-core-nmstatens-yaml"]
-.NMStateNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NMStateNS.yaml[]
-----
-
-[id="telco-core-nmstateopergroup-yaml"]
-.NMStateOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NMStateOperGroup.yaml[]
-----
-
-[id="telco-core-nmstatesubscription-yaml"]
-.NMStateSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NMStateSubscription.yaml[]
-----
-
-[id="telco-core-sriovnetwork-yaml"]
-.sriovNetwork.yaml
-[source,yaml]
-----
-include::snippets/telco-core_sriovNetwork.yaml[]
-----
-
-[id="telco-core-sriovnetworknodepolicy-yaml"]
-.sriovNetworkNodePolicy.yaml
-[source,yaml]
-----
-include::snippets/telco-core_sriovNetworkNodePolicy.yaml[]
-----
-
-[id="telco-core-sriovoperatorconfig-yaml"]
-.SriovOperatorConfig.yaml
-[source,yaml]
-----
-include::snippets/telco-core_SriovOperatorConfig.yaml[]
-----
-
-[id="telco-core-sriovsubscription-yaml"]
-.SriovSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_SriovSubscription.yaml[]
-----
-
-[id="telco-core-sriovsubscriptionns-yaml"]
-.SriovSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_SriovSubscriptionNS.yaml[]
-----
-
-[id="telco-core-sriovsubscriptionopergroup-yaml"]
-.SriovSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_SriovSubscriptionOperGroup.yaml[]
-----
diff --git a/modules/telco-core-yaml-ref-node-configuration.adoc b/modules/telco-core-yaml-ref-node-configuration.adoc
deleted file mode 100644
index 897146535299..000000000000
--- a/modules/telco-core-yaml-ref-node-configuration.adoc
+++ /dev/null
@@ -1,56 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="node-configuration-yaml_{context}"]
-= Node configuration reference YAML
-
-[id="telco-core-control-plane-load-kernel-modules-yaml"]
-.control-plane-load-kernel-modules.yaml
-[source,yaml]
-----
-include::snippets/telco-core_control-plane-load-kernel-modules.yaml[]
-----
-
-[id="telco-core-sctp_module_mc-yaml"]
-.sctp_module_mc.yaml
-[source,yaml]
-----
-include::snippets/telco-core_sctp_module_mc.yaml[]
-----
-
-[id="telco-core-worker-load-kernel-modules-yaml"]
-.worker-load-kernel-modules.yaml
-[source,yaml]
-----
-include::snippets/telco-core_worker-load-kernel-modules.yaml[]
-----
-
-[id="telco-core-mount_namespace_config_master-yaml"]
-.mount_namespace_config_master.yaml
-[source,yaml]
-----
-include::snippets/telco-core_mount_namespace_config_master.yaml[]
-----
-
-[id="telco-core-mount_namespace_config_worker-yaml"]
-.mount_namespace_config_worker.yaml
-[source,yaml]
-----
-include::snippets/telco-core_mount_namespace_config_worker.yaml[]
-----
-
-[id="telco-core-kdump-master-yaml"]
-.kdump-master.yaml
-[source,yaml]
-----
-include::snippets/telco-core_kdump-master.yaml[]
-----
-
-[id="telco-core-kdump-worker-yaml"]
-.kdump-worker.yaml
-[source,yaml]
-----
-include::snippets/telco-core_kdump-worker.yaml[]
-----
diff --git a/modules/telco-core-yaml-ref-other.adoc b/modules/telco-core-yaml-ref-other.adoc
deleted file mode 100644
index 68542f6ef7c6..000000000000
--- a/modules/telco-core-yaml-ref-other.adoc
+++ /dev/null
@@ -1,91 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="other-yaml_{context}"]
-= Other reference YAML
-
-[id="telco-core-clusterlogforwarder-yaml"]
-.ClusterLogForwarder.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogForwarder.yaml[]
-----
-
-[id="telco-core-clusterlogns-yaml"]
-.ClusterLogNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogNS.yaml[]
-----
-
-[id="telco-core-clusterlogopergroup-yaml"]
-.ClusterLogOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogOperGroup.yaml[]
-----
-
-[id="telco-core-clusterlogserviceaccount-yaml"]
-.ClusterLogServiceAccount.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogServiceAccount.yaml[]
-----
-
-[id="telco-core-clusterlogserviceaccountauditbinding-yaml"]
-.ClusterLogServiceAccountAuditBinding.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogServiceAccountAuditBinding.yaml[]
-----
-
-[id="telco-core-clusterlogserviceaccountinfrastructurebinding-yaml"]
-.ClusterLogServiceAccountInfrastructureBinding.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogServiceAccountInfrastructureBinding.yaml[]
-----
-
-[id="telco-core-clusterlogsubscription-yaml"]
-.ClusterLogSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_ClusterLogSubscription.yaml[]
-----
-
-[id="telco-core-catalog-source-yaml"]
-.catalog-source.yaml
-[source,yaml]
-----
-include::snippets/telco-core_catalog-source.yaml[]
-----
-
-[id="telco-core-icsp-yaml"]
-.icsp.yaml
-[source,yaml]
-----
-include::snippets/telco-core_icsp.yaml[]
-----
-
-[id="telco-core-operator-hub-yaml"]
-.operator-hub.yaml
-[source,yaml]
-----
-include::snippets/telco-core_operator-hub.yaml[]
-----
-
-[id="telco-core-monitoring-config-cm-yaml"]
-.monitoring-config-cm.yaml
-[source,yaml]
-----
-include::snippets/telco-core_monitoring-config-cm.yaml[]
-----
-
-[id="telco-core-performanceprofile-yaml"]
-.PerformanceProfile.yaml
-[source,yaml]
-----
-include::snippets/telco-core_PerformanceProfile.yaml[]
-----
diff --git a/modules/telco-core-yaml-ref-resource-tuning.adoc b/modules/telco-core-yaml-ref-resource-tuning.adoc
deleted file mode 100644
index 280b87534264..000000000000
--- a/modules/telco-core-yaml-ref-resource-tuning.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="resource-tuning-yaml_{context}"]
-= Resource tuning reference YAML
-
-[id="telco-core-control-plane-system-reserved-yaml"]
-.control-plane-system-reserved.yaml
-[source,yaml]
-----
-include::snippets/telco-core_control-plane-system-reserved.yaml[]
-----
diff --git a/modules/telco-core-yaml-ref-scheduling.adoc b/modules/telco-core-yaml-ref-scheduling.adoc
deleted file mode 100644
index 3b2c6fd4b91c..000000000000
--- a/modules/telco-core-yaml-ref-scheduling.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="scheduling-yaml_{context}"]
-= Scheduling reference YAML
-
-[id="telco-core-nrop-yaml"]
-.nrop.yaml
-[source,yaml]
-----
-include::snippets/telco-core_nrop.yaml[]
-----
-
-[id="telco-core-nropsubscription-yaml"]
-.NROPSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NROPSubscription.yaml[]
-----
-
-[id="telco-core-nropsubscriptionns-yaml"]
-.NROPSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NROPSubscriptionNS.yaml[]
-----
-
-[id="telco-core-nropsubscriptionopergroup-yaml"]
-.NROPSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_NROPSubscriptionOperGroup.yaml[]
-----
-
-[id="telco-core-sched-yaml"]
-.sched.yaml
-[source,yaml]
-----
-include::snippets/telco-core_sched.yaml[]
-----
-
-[id="telco-core-scheduler-yaml"]
-.Scheduler.yaml
-[source,yaml]
-----
-include::snippets/telco-core_Scheduler.yaml[]
-----
diff --git a/modules/telco-core-yaml-ref-storage.adoc b/modules/telco-core-yaml-ref-storage.adoc
deleted file mode 100644
index 2c8d9819a2b3..000000000000
--- a/modules/telco-core-yaml-ref-storage.adoc
+++ /dev/null
@@ -1,42 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="storage-yaml_{context}"]
-= Storage reference YAML
-
-[id="telco-core-01-rook-ceph-external-cluster-details.secret-yaml"]
-.01-rook-ceph-external-cluster-details.secret.yaml
-[source,yaml]
-----
-include::snippets/telco-core_01-rook-ceph-external-cluster-details.secret.yaml[]
-----
-
-[id="telco-core-02-ocs-external-storagecluster-yaml"]
-.02-ocs-external-storagecluster.yaml
-[source,yaml]
-----
-include::snippets/telco-core_02-ocs-external-storagecluster.yaml[]
-----
-
-[id="telco-core-odfns-yaml"]
-.odfNS.yaml
-[source,yaml]
-----
-include::snippets/telco-core_odfNS.yaml[]
-----
-
-[id="telco-core-odfopergroup-yaml"]
-.odfOperGroup.yaml
-[source,yaml]
-----
-include::snippets/telco-core_odfOperGroup.yaml[]
-----
-
-[id="telco-core-odfsubscription-yaml"]
-.odfSubscription.yaml
-[source,yaml]
-----
-include::snippets/telco-core_odfSubscription.yaml[]
-----
diff --git a/modules/telco-deviations-from-the-ref-design.adoc b/modules/telco-deviations-from-the-ref-design.adoc
index 7284f7f8cb12..7f657828b254 100644
--- a/modules/telco-deviations-from-the-ref-design.adoc
+++ b/modules/telco-deviations-from-the-ref-design.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
-// * telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+// * scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="telco-deviations-from-the-ref-design_{context}"]
diff --git a/modules/telco-nmstate-operator.adoc b/modules/telco-nmstate-operator.adoc
deleted file mode 100644
index 51ea0495c54b..000000000000
--- a/modules/telco-nmstate-operator.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-core-nmstate-operator_{context}"]
-= NMState Operator
-
-New in this release::
-* No reference design updates in this release
-
-Description::
-The NMState Operator provides a Kubernetes API for performing network configurations across cluster nodes.
-
-Limits and requirements::
-Not applicable
-
-Engineering considerations::
-* The initial networking configuration is applied using `NMStateConfig` content in the installation CRs. The NMState Operator is used only when needed for network updates.
-* When SR-IOV virtual functions are used for host networking, the NMState Operator using `NodeNetworkConfigurationPolicy` is used to configure those VF interfaces, for example, VLANs and the MTU.
diff --git a/modules/telco-observability-key-performance-metrics.adoc b/modules/telco-observability-key-performance-metrics.adoc
index 486e0613578a..6eccabf91c5e 100644
--- a/modules/telco-observability-key-performance-metrics.adoc
+++ b/modules/telco-observability-key-performance-metrics.adoc
@@ -36,7 +36,7 @@ The following tables show some queries that you can explore in the metrics query
 [NOTE]
 ====
 The URL for the console is https://<OpenShift Console FQDN>/monitoring/query-browser.
-You can get the Openshift Console FQDN by running the following command:
+You can get the OpenShift Console FQDN by running the following command:
 [source,terminal]
 ----
 $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
diff --git a/modules/telco-ran-agent-based-installer-abi.adoc b/modules/telco-ran-agent-based-installer-abi.adoc
index 753b5ffccb41..84e29d4861e8 100644
--- a/modules/telco-ran-agent-based-installer-abi.adoc
+++ b/modules/telco-ran-agent-based-installer-abi.adoc
@@ -1,35 +1,25 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-agent-based-installer-abi_{context}"]
-= Agent-based installer
+= Agent-based Installer
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-Agent-based installer (ABI) provides installation capabilities without centralized infrastructure.
+The optional Agent-based Installer component provides installation capabilities without centralized infrastructure.
 The installation program creates an ISO image that you mount to the server.
 When the server boots it installs {product-title} and supplied extra manifests.
-+
-[NOTE]
-====
-You can also use ABI to install {product-title} clusters without a hub cluster.
-An image registry is still required when you use ABI in this manner.
-====
-
-Agent-based installer (ABI) is an optional component.
+The Agent-based Installer allows you to install {product-title} without a hub cluster.
+A container image registry is required for cluster installation.
 
 Limits and requirements::
 * You can supply a limited set of additional manifests at installation time.
-
 * You must include `MachineConfiguration` CRs that are required by the RAN DU use case.
 
 Engineering considerations::
-
-* ABI provides a baseline {product-title} installation.
-
+* The Agent-based Installer provides a baseline {product-title} installation.
 * You install Day 2 Operators and the remainder of the RAN DU use case configurations after installation.
diff --git a/modules/telco-ran-architecture-overview.adoc b/modules/telco-ran-architecture-overview.adoc
deleted file mode 100644
index 7e87be9c1f6e..000000000000
--- a/modules/telco-ran-architecture-overview.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="telco-ran-architecture-overview_{context}"]
-= Deployment architecture overview
-
-You deploy the {rds} {product-version} reference configuration to managed clusters from a centrally managed {rh-rhacm} hub cluster.
-The reference design specification (RDS) includes configuration of the managed clusters and the hub cluster components.
-
-.{rds-caps} deployment architecture overview
-image::474_OpenShift_OpenShift_RAN_RDS_arch_updates_1023.png[A diagram showing two distinctive network far edge deployment processes, one show how the hub cluster uses {gitops-title} to install managed clusters, and the other showing how the hub cluster uses {cgu-operator-full} to apply policies to managed clusters]
diff --git a/modules/telco-ran-bios-tuning.adoc b/modules/telco-ran-bios-tuning.adoc
index 83da0d57de11..72753b56822a 100644
--- a/modules/telco-ran-bios-tuning.adoc
+++ b/modules/telco-ran-bios-tuning.adoc
@@ -1,29 +1,34 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-bios-tuning_{context}"]
 = Host firmware tuning
 
 New in this release::
-//CNF-2026
-* You can now configure host firmware settings for managed clusters that you deploy with {ztp}.
+* No reference design updates in this release
 
 Description::
 Tune host firmware settings for optimal performance during initial cluster deployment.
-The managed cluster host firmware settings are available on the hub cluster as `BareMetalHost` custom resources (CRs) that are created when you deploy the managed cluster with the `SiteConfig` CR and {ztp}.
+For more information, see "Recommended {sno} cluster configuration for vDU application workloads".
+Apply tuning settings in the host firmware during initial deployment.
+See "Managing host firmware settings with {ztp}" for more information.
+The managed cluster host firmware settings are available on the hub cluster as individual `BareMetalHost` custom resources (CRs) that are created when you deploy the managed cluster with the `ClusterInstance` CR and {ztp}.
++
+[NOTE]
+====
+Create the `ClusterInstance` CR based on the provided reference `example-sno.yaml` CR.
+====
 
 Limits and requirements::
-* Hyperthreading must be enabled
+* You must enable Hyper-Threading in the host firmware settings
 
 Engineering considerations::
-* Tune all settings for maximum performance.
-
+* Tune all firmware settings for maximum performance.
 * All settings are expected to be for maximum performance unless tuned for power savings.
-
 * You can tune host firmware for power savings at the expense of performance as required.
-
+// https://issues.redhat.com/browse/CNF-11806
 * Enable secure boot.
-With secure boot enabled, only signed kernel modules are loaded by the kernel.
+When secure boot is enabled, only signed kernel modules are loaded by the kernel.
 Out-of-tree drivers are not supported.
diff --git a/modules/telco-ran-cluster-tuning.adoc b/modules/telco-ran-cluster-tuning.adoc
index e12fef062929..a6d3eff0bff3 100644
--- a/modules/telco-ran-cluster-tuning.adoc
+++ b/modules/telco-ran-cluster-tuning.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-cluster-tuning_{context}"]
@@ -10,14 +10,25 @@ New in this release::
 * No reference design updates in this release
 
 Description::
-See "Cluster capabilities" for a full list of optional components that you can enable or disable before installation.
+See "Cluster capabilities" for a full list of components that can be disabled by using the cluster capabilities feature.
 
 Limits and requirements::
 * Cluster capabilities are not available for installer-provisioned installation methods.
 
-* You must apply all platform tuning configurations.
-The following table lists the required platform tuning configurations:
+Engineering considerations::
+* In clusters running {product-title} 4.16 and later, the cluster does not automatically revert to cgroup v1 when a `PerformanceProfile` is applied.
+If workloads running on the cluster require cgroup v1, the cluster must be configured for cgroup v1.
+For more information, see "Enabling Linux control group version 1 (cgroup v1)".
+You should make this configuration as part of the initial cluster deployment.
 +
+[NOTE]
+====
+Support for cgroup v1 is planned for removal in {product-title} 4.19.
+Clusters running cgroup v1 must transition to cgroup v2.
+====
+
+The following table lists the required platform tuning configurations:
+
 .Cluster capabilities configurations
 [cols=2*, width="90%", options="header"]
 |====
@@ -27,7 +38,7 @@ The following table lists the required platform tuning configurations:
 |Remove optional cluster capabilities
 a|Reduce the {product-title} footprint by disabling optional cluster Operators on {sno} clusters only.
 
-* Remove all optional Operators except the Marketplace and Node Tuning Operators.
+* Remove all optional Operators except the Node Tuning Operator, Operator Lifecycle Manager, and the Ingress Operator.
 
 |Configure cluster monitoring
 a|Configure the monitoring stack for reduced footprint by doing the following:
@@ -55,12 +66,3 @@ Using a single `CatalogSource` fits within the platform CPU budget.
 |If the cluster was deployed with the console disabled, the `Console` CR (`ConsoleOperatorDisable.yaml`) is not needed.
 If the cluster was deployed with the console enabled, you must apply the `Console` CR.
 |====
-
-Engineering considerations::
-* In {product-title} 4.16 and later, clusters do not automatically revert to cgroups v1 when a `PerformanceProfile` CR is applied.
-If workloads running on the cluster require cgroups v1, you need to configure the cluster to use cgroups v1.
-+
-[NOTE]
-====
-If you need to configure cgroups v1, make the configuration as part of the initial cluster deployment.
-====
diff --git a/modules/telco-ran-core-ref-design-spec.adoc b/modules/telco-ran-core-ref-design-spec.adoc
index c8d5046bee46..6ef0d1b256e1 100644
--- a/modules/telco-ran-core-ref-design-spec.adoc
+++ b/modules/telco-ran-core-ref-design-spec.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
-// * telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+// * scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-core-ref-design-spec_{context}"]
diff --git a/modules/telco-ran-crs-cluster-tuning.adoc b/modules/telco-ran-crs-cluster-tuning.adoc
index a3a65c39417a..6551ba464abe 100644
--- a/modules/telco-ran-crs-cluster-tuning.adoc
+++ b/modules/telco-ran-crs-cluster-tuning.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="cluster-tuning-crs_{context}"]
@@ -9,14 +9,14 @@
 .Cluster tuning CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-Composable OpenShift,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-example-sno-yaml[example-sno.yaml],No,No
-Console disable,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-consoleoperatordisable-yaml[ConsoleOperatorDisable.yaml],Yes,No
-Disconnected registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-09-openshift-marketplace-ns-yaml[09-openshift-marketplace-ns.yaml],No,No
-Disconnected registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-defaultcatsrc-yaml[DefaultCatsrc.yaml],No,No
-Disconnected registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disableolmpprof-yaml[DisableOLMPprof.yaml],No,No
-Disconnected registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disconnectedicsp-yaml[DisconnectedICSP.yaml],No,No
-Disconnected registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-operatorhub-yaml[OperatorHub.yaml],"OperatorHub is required for {sno} and optional for multi-node clusters",No
-Monitoring configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-reducemonitoringfootprint-yaml[ReduceMonitoringFootprint.yaml],No,No
-Network diagnostics disable,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disablesnonetworkdiag-yaml[DisableSnoNetworkDiag.yaml],No,No
+Component,Reference CR,Description,Optional
+Cluster capabilities,`example-sno.yaml`,Representative SiteConfig CR to install single-node OpenShift with the RAN DU profile,No
+Console disable,`ConsoleOperatorDisable.yaml`,Disables the Console Operator.,No
+Disconnected registry,`09-openshift-marketplace-ns.yaml`,Defines a dedicated namespace for managing the OpenShift Operator Marketplace.,No
+Disconnected registry,`DefaultCatsrc.yaml`,Configures the catalog source for the disconnected registry.,No
+Disconnected registry,`DisableOLMPprof.yaml`,Disables performance profiling for OLM.,No
+Disconnected registry,`DisconnectedICSP.yaml`,Configures disconnected registry image content source policy.,No
+Disconnected registry,`OperatorHub.yaml`,"Optional, for multi-node clusters only. Configures the OperatorHub in OpenShift, disabling all default Operator sources. Not required for single-node OpenShift installs with marketplace capability disabled.",No
+Monitoring configuration,`ReduceMonitoringFootprint.yaml`,"Reduces the monitoring footprint by disabling Alertmanager and Telemeter, and sets Prometheus retention to 24 hours",No
+Network diagnostics disable,`DisableSnoNetworkDiag.yaml`,Configures the cluster network settings to disable built-in network troubleshooting and diagnostic features.,No
 |====
diff --git a/modules/telco-ran-crs-day-2-operators.adoc b/modules/telco-ran-crs-day-2-operators.adoc
index 71ef8ee3b407..d09c9c107ad2 100644
--- a/modules/telco-ran-crs-day-2-operators.adoc
+++ b/modules/telco-ran-crs-day-2-operators.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="day-2-operators-crs_{context}"]
@@ -9,53 +9,54 @@
 .Day 2 Operators CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogforwarder-yaml[ClusterLogForwarder.yaml],No,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogns-yaml[ClusterLogNS.yaml],No,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogopergroup-yaml[ClusterLogOperGroup.yaml],No,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogserviceaccount-yaml[ClusterLogServiceAccount.yaml],No,Yes
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogserviceaccountauditbinding-yaml[ClusterLogServiceAccountAuditBinding.yaml],No,Yes
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogserviceaccountinfrastructurebinding-yaml[ClusterLogServiceAccountInfrastructureBinding.yaml],No,Yes
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogsubscription-yaml[ClusterLogSubscription.yaml],No,No
-LifeCycle Agent Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-imagebasedupgrade-yaml[ImageBasedUpgrade.yaml],Yes,No
-LifeCycle Agent Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-lcasubscription-yaml[LcaSubscription.yaml],Yes,No
-LifeCycle Agent Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-lcasubscriptionns-yaml[LcaSubscriptionNS.yaml],Yes,No
-LifeCycle Agent Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-lcasubscriptionopergroup-yaml[LcaSubscriptionOperGroup.yaml],Yes,No
-Local Storage Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storageclass-yaml[StorageClass.yaml],Yes,No
-Local Storage Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagelv-yaml[StorageLV.yaml],Yes,No
-Local Storage Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagens-yaml[StorageNS.yaml],Yes,No
-Local Storage Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storageopergroup-yaml[StorageOperGroup.yaml],Yes,No
-Local Storage Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagesubscription-yaml[StorageSubscription.yaml],Yes,No
-LVM Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-lvmoperatorstatus-yaml[LVMOperatorStatus.yaml],Yes,No
-LVM Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagelvmcluster-yaml[StorageLVMCluster.yaml],Yes,No
-LVM Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagelvmsubscription-yaml[StorageLVMSubscription.yaml],Yes,No
-LVM Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagelvmsubscriptionns-yaml[StorageLVMSubscriptionNS.yaml],Yes,No
-LVM Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-storagelvmsubscriptionopergroup-yaml[StorageLVMSubscriptionOperGroup.yaml],Yes,No
-Node Tuning Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-performanceprofile-yaml[PerformanceProfile.yaml],No,No
-Node Tuning Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-tunedperformancepatch-yaml[TunedPerformancePatch.yaml],No,No
-PTP fast event notifications,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigboundaryforevent-yaml[PtpConfigBoundaryForEvent.yaml],Yes,No
-PTP fast event notifications,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigforhaforevent-yaml[PtpConfigForHAForEvent.yaml],Yes,No
-PTP fast event notifications,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigmasterforevent-yaml[PtpConfigMasterForEvent.yaml],Yes,No
-PTP fast event notifications,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigslaveforevent-yaml[PtpConfigSlaveForEvent.yaml],Yes,No
-PTP Operator - high availability,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigboundary-yaml[PtpConfigBoundary.yaml],No,No
-PTP Operator - high availability,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigforha-yaml[PtpConfigForHA.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigdualcardgmwpc-yaml[PtpConfigDualCardGmWpc.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfiggmwpc-yaml[PtpConfigGmWpc.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigslave-yaml[PtpConfigSlave.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpoperatorconfig-yaml[PtpOperatorConfig.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpoperatorconfigforevent-yaml[PtpOperatorConfigForEvent.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpsubscription-yaml[PtpSubscription.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpsubscriptionns-yaml[PtpSubscriptionNS.yaml],No,No
-PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpsubscriptionopergroup-yaml[PtpSubscriptionOperGroup.yaml],No,No
-SR-IOV FEC Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-acceleratorsns-yaml[AcceleratorsNS.yaml],Yes,No
-SR-IOV FEC Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-acceleratorsopergroup-yaml[AcceleratorsOperGroup.yaml],Yes,No
-SR-IOV FEC Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-acceleratorssubscription-yaml[AcceleratorsSubscription.yaml],Yes,No
-SR-IOV FEC Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovfecclusterconfig-yaml[SriovFecClusterConfig.yaml],Yes,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovnetwork-yaml[SriovNetwork.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovnetworknodepolicy-yaml[SriovNetworkNodePolicy.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovoperatorconfigforsno-yaml[SriovOperatorConfigForSNO.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscription-yaml[SriovSubscription.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscriptionns-yaml[SriovSubscriptionNS.yaml],No,No
-SR-IOV Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscriptionopergroup-yaml[SriovSubscriptionOperGroup.yaml],No,No
+Component,Reference CR,Description,Optional
+Cluster Logging Operator,`ClusterLogForwarder.yaml`,Configures log forwarding for the cluster.,No
+Cluster Logging Operator,`ClusterLogNS.yaml`,Configures the namespace for cluster logging.,No
+Cluster Logging Operator,`ClusterLogOperGroup.yaml`,Configures Operator group for cluster logging.,No
+Cluster Logging Operator,`ClusterLogServiceAccount.yaml`,New in 4.18. Configures the cluster logging service account.,No
+Cluster Logging Operator,`ClusterLogServiceAccountAuditBinding.yaml`,New in 4.18. Configures the cluster logging service account.,No
+Cluster Logging Operator,`ClusterLogServiceAccountInfrastructureBinding.yaml`,New in 4.18. Configures the cluster logging service account.,No
+Cluster Logging Operator,`ClusterLogSubscription.yaml`,Manages installation and updates for the Cluster Logging Operator.,No
+Lifecycle Agent,`ImageBasedUpgrade.yaml`,Manage the image-based upgrade process in OpenShift.,Yes
+Lifecycle Agent,`LcaSubscription.yaml`,Manages installation and updates for the LCA Operator.,Yes
+Lifecycle Agent,`LcaSubscriptionNS.yaml`,Configures namespace for LCA subscription.,Yes
+Lifecycle Agent,`LcaSubscriptionOperGroup.yaml`,Configures the Operator group for the LCA subscription.,Yes
+Local Storage Operator,`StorageClass.yaml`,Defines a storage class with a Delete reclaim policy and no dynamic provisioning in the cluster.,No
+Local Storage Operator,`StorageLV.yaml`,"Configures local storage devices for the example-storage-class in the openshift-local-storage namespace, specifying device paths and filesystem type.",No
+Local Storage Operator,`StorageNS.yaml`,Creates the namespace with annotations for workload management and the deployment wave for the Local Storage Operator.,No
+Local Storage Operator,`StorageOperGroup.yaml`,Creates the Operator group for the Local Storage Operator.,No
+Local Storage Operator,`StorageSubscription.yaml`,Creates the namespace for the Local Storage Operator with annotations for workload management and deployment wave.,No
+LVM Operator,`LVMOperatorStatus.yaml`,Verifies the installation or upgrade of the LVM Storage Operator.,Yes
+LVM Operator,`StorageLVMCluster.yaml`,"Defines an LVM cluster configuration, with placeholders for storage device classes and volume group settings. Optional substitute for the Local Storage Operator.",No
+LVM Operator,`StorageLVMSubscription.yaml`,Manages installation and updates of the LVMS Operator. Optional substitute for the Local Storage Operator.,No
+LVM Operator,`StorageLVMSubscriptionNS.yaml`,Creates the namespace for the LVMS Operator with labels and annotations for cluster monitoring and workload management. Optional substitute for the Local Storage Operator.,No
+LVM Operator,`StorageLVMSubscriptionOperGroup.yaml`,Defines the target namespace for the LVMS Operator. Optional substitute for the Local Storage Operator.,No
+Node Tuning Operator,`PerformanceProfile.yaml`,"Configures node performance settings in an OpenShift cluster, optimizing for low latency and real-time workloads.",No
+Node Tuning Operator,`TunedPerformancePatch.yaml`,"Applies performance tuning settings, including scheduler groups and service configurations for nodes in the specific namespace.",No
+PTP fast event notifications,`PtpConfigBoundaryForEvent.yaml`,Configures PTP settings for PTP boundary clocks with additional options for event synchronization. Dependent on cluster role.,No
+PTP fast event notifications,`PtpConfigForHAForEvent.yaml`,Configures PTP for highly available boundary clocks with additional PTP fast event settings. Dependent on cluster role.,No
+PTP fast event notifications,`PtpConfigMasterForEvent.yaml`,Configures PTP for PTP grandmaster clocks with additional PTP fast event settings. Dependent on cluster role.,No
+PTP fast event notifications,`PtpConfigSlaveForEvent.yaml`,Configures PTP for PTP ordinary clocks with additional PTP fast event settings. Dependent on cluster role.,No
+PTP fast event notifications,`PtpOperatorConfigForEvent.yaml`,Overrides the default OperatorConfig. Configures the PTP Operator specifying node selection criteria for running PTP daemons in the openshift-ptp namespace.,No
+PTP Operator,`PtpConfigBoundary.yaml`,Configures PTP settings for PTP boundary clocks. Dependent on cluster role.,No
+PTP Operator,`PtpConfigDualCardGmWpc.yaml`,Configures PTP grandmaster clock settings for hosts that have dual NICs. Dependent on cluster role.,No
+PTP Operator,`PtpConfigGmWpc.yaml`,Configures PTP grandmaster clock settings for hosts that have a single NIC. Dependent on cluster role.,No
+PTP Operator,`PtpConfigSlave.yaml`,Configures PTP settings for a PTP ordinary clock. Dependent on cluster role.,No
+PTP Operator,`PtpOperatorConfig.yaml`,"Configures the PTP Operator settings, specifying node selection criteria for running PTP daemons in the openshift-ptp namespace.",No
+PTP Operator,`PtpSubscription.yaml`,Manages installation and updates of the PTP Operator in the openshift-ptp namespace.,No
+PTP Operator,`PtpSubscriptionNS.yaml`,Configures the namespace for the PTP Operator.,No
+PTP Operator,`PtpSubscriptionOperGroup.yaml`,Configures the Operator group for the PTP Operator.,No
+PTP Operator (high availability),`PtpConfigBoundary.yaml`,Configures PTP settings for highly available PTP boundary clocks.,No
+PTP Operator (high availability),`PtpConfigForHA.yaml`,Configures PTP settings for highly available PTP boundary clocks.,No
+SR-IOV FEC Operator,`AcceleratorsNS.yaml`,Configures namespace for the VRAN Acceleration Operator. Optional part of application workload.,Yes
+SR-IOV FEC Operator,`AcceleratorsOperGroup.yaml`,Configures the Operator group for the VRAN Acceleration Operator. Optional part of application workload.,Yes
+SR-IOV FEC Operator,`AcceleratorsSubscription.yaml`,Manages installation and updates for the VRAN Acceleration Operator. Optional part of application workload.,Yes
+SR-IOV FEC Operator,`SriovFecClusterConfig.yaml`,"Configures SR-IOV FPGA Ethernet Controller (FEC) settings for nodes, specifying drivers, VF amount, and node selection.",Yes
+SR-IOV Operator,`SriovNetwork.yaml`,"Defines an SR-IOV network configuration, with placeholders for various network settings.",No
+SR-IOV Operator,`SriovNetworkNodePolicy.yaml`,"Configures SR-IOV network settings for specific nodes, including device type, RDMA support, physical function names, and the number of virtual functions.",No
+SR-IOV Operator,`SriovOperatorConfig.yaml`,"Configures SR-IOV Network Operator settings, including node selection, injector, and webhook options.",No
+SR-IOV Operator,`SriovOperatorConfigForSNO.yaml`,"Configures the SR-IOV Network Operator settings for single-node OpenShift, including node selection, injector, webhook options, and disabling node drain, in the openshift-sriov-network-operator namespace.",No
+SR-IOV Operator,`SriovSubscription.yaml`,Manages the installation and updates of the SR-IOV Network Operator.,No
+SR-IOV Operator,`SriovSubscriptionNS.yaml`,Creates the namespace for the SR-IOV Network Operator with specific annotations for workload management and deployment waves.,No
+SR-IOV Operator,`SriovSubscriptionOperGroup.yaml`,"Defines the target namespace for the SR-IOV Network Operators, enabling their management and deployment within this namespace.",No
 |====
diff --git a/modules/telco-ran-crs-machine-configuration.adoc b/modules/telco-ran-crs-machine-configuration.adoc
index fdf7dc1c58e4..6a38c7e5dd4a 100644
--- a/modules/telco-ran-crs-machine-configuration.adoc
+++ b/modules/telco-ran-crs-machine-configuration.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="machine-configuration-crs_{context}"]
@@ -9,21 +9,20 @@
 .Machine configuration CRs
 [cols="4*", options="header", format=csv]
 |====
-Component,Reference CR,Optional,New in this release
-Container runtime (crun),xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-enable-crun-master-yaml[enable-crun-master.yaml],No,No
-Container runtime (crun),xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-enable-crun-worker-yaml[enable-crun-worker.yaml],No,No
-Disable CRI-O wipe,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-crio-disable-wipe-master-yaml[99-crio-disable-wipe-master.yaml],No,No
-Disable CRI-O wipe,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-crio-disable-wipe-worker-yaml[99-crio-disable-wipe-worker.yaml],No,No
-Kdump enable,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-06-kdump-master-yaml[06-kdump-master.yaml],No,No
-Kdump enable,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-06-kdump-worker-yaml[06-kdump-worker.yaml],No,No
-Kubelet configuration / Container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-master-yaml[01-container-mount-ns-and-kubelet-conf-master.yaml],No,No
-Kubelet configuration / Container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-worker-yaml[01-container-mount-ns-and-kubelet-conf-worker.yaml],No,No
-One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-master-yaml[99-sync-time-once-master.yaml],No,No
-One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-worker-yaml[99-sync-time-once-worker.yaml],No,No
-SCTP,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-03-sctp-machine-config-master-yaml[03-sctp-machine-config-master.yaml],Yes,No
-SCTP,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-03-sctp-machine-config-worker-yaml[03-sctp-machine-config-worker.yaml],Yes,No
-Set RCU normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-master-yaml[08-set-rcu-normal-master.yaml],No,No
-Set RCU normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-worker-yaml[08-set-rcu-normal-worker.yaml],No,No
-SR-IOV-related kernel arguments,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-07-sriov-related-kernel-args-master-yaml[07-sriov-related-kernel-args-master.yaml],No,No
-SR-IOV-related kernel arguments,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-07-sriov-related-kernel-args-worker-yaml[07-sriov-related-kernel-args-worker.yaml],No,No
+Component,Reference CR,Description,Optional
+Container runtime (crun),`enable-crun-master.yaml`,Configures the container runtime (crun) for control plane nodes.,No
+Container runtime (crun),`enable-crun-worker.yaml`,Configures the container runtime (crun) for worker nodes.,No
+CRI-O wipe disable,`99-crio-disable-wipe-master.yaml`,Disables automatic CRI-O cache wipe following a reboot for on control plane nodes.,No
+CRI-O wipe disable,`99-crio-disable-wipe-worker.yaml`,Disables automatic CRI-O cache wipe following a reboot for on worker nodes.,No
+Kdump enable,`06-kdump-master.yaml`,Configures kdump crash reporting on master nodes.,No
+Kdump enable,`06-kdump-worker.yaml`,Configures kdump crash reporting on worker nodes.,No
+Kubelet configuration and container mount hiding,`01-container-mount-ns-and-kubelet-conf-master.yaml`,Configures a mount namespace for sharing container-specific mounts between kubelet and CRI-O on control plane nodes.,No
+Kubelet configuration and container mount hiding,`01-container-mount-ns-and-kubelet-conf-worker.yaml`,Configures a mount namespace for sharing container-specific mounts between kubelet and CRI-O on worker nodes.,No
+One-shot time sync,`99-sync-time-once-master.yaml`,Synchronizes time once on master nodes.,No
+One-shot time sync,`99-sync-time-once-worker.yaml`,Synchronizes time once on worker nodes.,No
+SCTP,`03-sctp-machine-config-master.yaml`,Loads the SCTP kernel module on master nodes.,Yes
+SCTP,`03-sctp-machine-config-worker.yaml`,Loads the SCTP kernel module on worker nodes.,Yes
+Set RCU normal,`08-set-rcu-normal-master.yaml`,Disables rcu_expedited by setting rcu_normal after the control plane node has booted.,No
+Set RCU normal,`08-set-rcu-normal-worker.yaml`,Disables rcu_expedited by setting rcu_normal after the worker node has booted.,No
+SRIOV-related kernel arguments,`07-sriov-related-kernel-args-master.yaml`,Enables SR-IOV support on master nodes.,No
 |====
diff --git a/modules/telco-ran-crs-networking.adoc b/modules/telco-ran-crs-networking.adoc
deleted file mode 100644
index 51c2ef1c4220..000000000000
--- a/modules/telco-ran-crs-networking.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="networking-crs_{context}"]
-= Networking reference CRs
-
-.Networking CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-Baseline,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-network-yaml[Network.yaml],No,No
-Baseline,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscriptionns-yaml[SriovSubscriptionNS.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscriptionopergroup-yaml[SriovSubscriptionOperGroup.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovsubscription-yaml[SriovSubscription.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovnetworknodepolicy-yaml[sriovNetworkNodePolicy.yaml],No,No
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sriovnetwork-yaml[sriovNetwork.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-metallbns-yaml[metallbNS.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-metallbopergroup-yaml[metallbOperGroup.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-metallbsubscription-yaml[metallbSubscription.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-metallb-yaml[metallb.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-bgp-peer-yaml[bgp-peer.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-bfd-profile-yaml[bfd-profile.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-addr-pool-yaml[addr-pool.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-bgp-advr-yaml[bgp-advr.yaml],No,No
-Multus - Tap CNI for rootless DPDK pod,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],Yes,No
-|====
diff --git a/modules/telco-ran-crs-other.adoc b/modules/telco-ran-crs-other.adoc
deleted file mode 100644
index 77187c5fc6c7..000000000000
--- a/modules/telco-ran-crs-other.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="other-crs_{context}"]
-= Other reference CRs
-
-.Other CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-Disconnected configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-catalog-source-yaml[catalog-source.yaml],No,No
-Disconnected configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-icsp-yaml[icsp.yaml],No,No
-Disconnected configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-operator-hub-yaml[operator-hub.yaml],No,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogns-yaml[ClusterLogNS.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogopergroup-yaml[ClusterLogOperGroup.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogsubscription-yaml[ClusterLogSubscription.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogforwarder-yaml[ClusterLogForwarder.yaml],Yes,No
-Cluster logging,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-clusterlogging-yaml[ClusterLogging.yaml],Yes,No
-Additional kernel modules,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-control-plane-load-kernel-modules-yaml[control-plane-load-kernel-modules.yaml],Yes,No
-Additional kernel modules,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-worker-load-kernel-modules-yaml[worker-load-kernel-modules.yaml],Yes,No
-Additional kernel modules,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sctp_module_mc-yaml[sctp_module_mc.yaml],Yes,No
-Power management,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-performanceprofile-yaml[PerformanceProfile.yaml],No,No
-|====
diff --git a/modules/telco-ran-crs-resource-tuning.adoc b/modules/telco-ran-crs-resource-tuning.adoc
deleted file mode 100644
index 266e87fbeac3..000000000000
--- a/modules/telco-ran-crs-resource-tuning.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="resource-tuning-crs_{context}"]
-= Resource Tuning reference CRs
-
-.Resource Tuning CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-System reserved capacity,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-pid-limits-cr-yaml[pid-limits-cr.yaml],Yes,No
-System reserved capacity,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-control-plane-system-reserved-yaml[control-plane-system-reserved.yaml],Yes,No
-|====
diff --git a/modules/telco-ran-crs-scheduling.adoc b/modules/telco-ran-crs-scheduling.adoc
deleted file mode 100644
index b75fac12f254..000000000000
--- a/modules/telco-ran-crs-scheduling.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="scheduling-crs_{context}"]
-= Scheduling reference CRs
-
-.Scheduling CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-nropsubscriptionns-yaml[NROPSubscriptionNS.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-nropsubscriptionopergroup-yaml[NROPSubscriptionOperGroup.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-nropsubscription-yaml[NROPSubscription.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-nropsubscriptionns-yaml[NROPSubscriptionNS.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-sched-yaml[sched.yaml],No,No
-NUMA-aware scheduler,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-nrop-yaml[nrop.yaml],No,No
-|====
diff --git a/modules/telco-ran-crs-storage.adoc b/modules/telco-ran-crs-storage.adoc
deleted file mode 100644
index 5b3c354ffe05..000000000000
--- a/modules/telco-ran-crs-storage.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="storage-crs_{context}"]
-= Storage reference CRs
-
-.Storage CRs
-[cols="4*", options="header", format=csv]
-|====
-Component,Reference CR,Optional,New in this release
-External ODF configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-odffns-yaml[odffNS.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-odfopergroup-yaml[odfOperGroup.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-odfsubscription-yaml[odfSubscription.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-rook-ceph-external-cluster-details.secret-yaml[01-rook-ceph-external-cluster-details.secret.yaml],No,No
-External ODF configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-02-ocs-external-storagecluster-yaml[02-ocs-external-storagecluster.yaml],No,No
-|====
diff --git a/modules/telco-ran-du-application-workloads.adoc b/modules/telco-ran-du-application-workloads.adoc
index fb6df1f0fec9..303da63aad04 100644
--- a/modules/telco-ran-du-application-workloads.adoc
+++ b/modules/telco-ran-du-application-workloads.adoc
@@ -1,28 +1,24 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
-[id="telco-du-workloads_{context}"]
-= {rds-caps} application workloads
+[id="telco-ran-du-application-workloads_{context}"]
+= Telco RAN DU application workloads
 
-DU worker nodes must have 3rd Generation Xeon (Ice Lake) 2.20 GHz or better CPUs with firmware tuned for maximum performance.
-
-5G RAN DU user applications and workloads should conform to the following best practices and application limits:
-
-* Develop cloud-native network functions (CNFs) that conform to the latest version of the link:https://redhat-best-practices-for-k8s.github.io/guide/[Red{nbsp}Hat Best Practices for Kubernetes].
+Develop RAN DU applications that are subject to the following requirements and limitations.
 
+Description and limits::
++
+--
+* Develop cloud-native network functions (CNFs) that conform to the latest version of link:https://redhat-best-practices-for-k8s.github.io/guide/[Red Hat best practices for Kubernetes].
 * Use SR-IOV for high performance networking.
-
-* Use exec probes sparingly and only when no other suitable options are available
-
+* Use exec probes sparingly and only when no other suitable options are available.
 ** Do not use exec probes if a CNF uses CPU pinning.
 Use other probe implementations, for example, `httpGet` or `tcpSocket`.
-
 ** When you need to use exec probes, limit the exec probe frequency and quantity.
 The maximum number of exec probes must be kept below 10, and frequency must not be set to less than 10 seconds.
-
-* Avoid using exec probes unless there is absolutely no viable alternative.
+Exec probes cause much higher CPU usage on management cores compared to other probe types because they require process forking.
 +
 [NOTE]
 ====
@@ -30,4 +26,8 @@ Startup probes require minimal resources during steady-state operation.
 The limitation on exec probes applies primarily to liveness and readiness probes.
 ====
 
+[NOTE]
+====
 A test workload that conforms to the dimensions of the reference DU application workload described in this specification can be found at link:https://github.com/openshift-kni/du-test-workloads/tree/v1.0[openshift-kni/du-test-workloads].
+====
+--
diff --git a/modules/telco-ran-du-reference-components.adoc b/modules/telco-ran-du-reference-components.adoc
deleted file mode 100644
index ca488324f14b..000000000000
--- a/modules/telco-ran-du-reference-components.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-ran-du-reference-components_{context}"]
-= {rds-caps} RDS components
-
-The following sections describe the various {product-title} components and configurations that you use to configure and deploy clusters to run {rds} workloads.
-
-.{rds-caps} reference design components
-image::telco-ran-du-reference-design-components-417.png[A diagram describing the {rds} component stack.]
-
-[NOTE]
-====
-Ensure that components that are not included in the {rds} profile do not affect the CPU resources allocated to workload applications.
-====
-
-[IMPORTANT]
-====
-Out of tree drivers are not supported.
-====
diff --git a/modules/telco-ran-du-reference-design-components.adoc b/modules/telco-ran-du-reference-design-components.adoc
new file mode 100644
index 000000000000..6f6c02015f27
--- /dev/null
+++ b/modules/telco-ran-du-reference-design-components.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-ran-du-reference-design-components_{context}"]
+= Telco RAN DU reference design components
+
+The following sections describe the various {product-title} components and configurations that you use to configure and deploy clusters to run RAN DU workloads.
+
+.Telco RAN DU reference design components
+image::telco-ran-du-reference-design-components.png[Diagram showing telco RAN DU RDS components]
+
+[NOTE]
+====
+Ensure that additional components you include that are not specified in the telco RAN DU profile do not affect the CPU resources allocated to workload applications.
+====
+
+[IMPORTANT]
+====
+Out of tree drivers are not supported.
+5G RAN application components are not included in the RAN DU profile and must be engineered against resources (CPU) allocated to applications.
+====
diff --git a/modules/telco-ran-engineering-considerations-for-the-ran-du-use-model.adoc b/modules/telco-ran-engineering-considerations-for-the-ran-du-use-model.adoc
new file mode 100644
index 000000000000..7b5e571f1686
--- /dev/null
+++ b/modules/telco-ran-engineering-considerations-for-the-ran-du-use-model.adoc
@@ -0,0 +1,99 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-ran-engineering-considerations-for-the-ran-du-use-model_{context}"]
+= Engineering considerations for the RAN DU use model
+
+The RAN DU use model configures an {product-title} cluster running on commodity hardware for hosting RAN distributed unit (DU) workloads.
+Model and system level considerations are described below.
+Specific limits, requirements and engineering considerations for individual components are detailed in later sections.
+
+[NOTE]
+====
+For details of the RAN DU KPI test results, see the link:https://access.redhat.com/articles/7107302[Telco RAN DU reference design specification KPI test results for OpenShift {product-version}].
+This information is only available to customers and partners.
+====
+
+Workloads::
+* DU workloads are described in "Telco RAN DU application workloads".
+* DU worker nodes are Intel 3rd Generation Xeon (IceLake) 2.20 GHz or better with host firmware tuned for maximum performance.
+
+Resources::
+The maximum number of running pods in the system, inclusive of application workload and {product-title} pods, is 120.
+
+Resource utilization::
++
+--
+{product-title} resource utilization varies depending on many factors such as the following application workload characteristics:
+
+* Pod count
+* Type and frequency of probes
+* Messaging rates on the primary or secondary CNI with kernel networking
+* API access rate
+* Logging rates
+* Storage IOPS
+
+Resource utilization is measured for clusters configured as follows:
+
+. The cluster is a single host with {sno} installed.
+. The cluster runs the representative application workload described in "Reference application workload characteristics".
+. The cluster is managed under the constraints detailed in "Hub cluster management characteristics".
+. Components noted as "optional" in the use model configuration are not included.
+
+[NOTE]
+====
+Configuration outside the scope of the RAN DU RDS that do not meet these criteria requires additional analysis to determine the impact on resource utilization and ability to meet KPI targets.
+You might need to allocate additional cluster resources to meet these requirements.
+====
+--
+
+Reference application workload characteristics::
+. Uses 15 pods and 30 containers for the vRAN application including its management and control functions
+. Uses an average of 2 `ConfigMap` and 4 `Secret` CRs per pod
+. Uses a maximum of 10 exec probes with a frequency of not less than 10 seconds
+. Incremental application load on the kube-apiserver is less than or equal to 10% of the cluster platform usage
++
+[NOTE]
+====
+You can extract CPU load can from the platform metrics.
+For example:
+[source,terminal]
+----
+$ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
+----
+====
+. Application logs are not collected by the platform log collector
+. Aggregate traffic on the primary CNI is less than 8 MBps
+
+Hub cluster management characteristics::
++
+--
+{rh-rhacm}  is the recommended cluster management solution and is configured to these limits:
+
+. Use a maximum of 5 {rh-rhacm} configuration policies with a compliant evaluation interval of not less than 10 minutes.
+. Use a minimal number (up to 10) of managed cluster templates in cluster policies.
+Use hub-side templating.
+. Disable {rh-rhacm} addons with the exception of the `policyController` and configure observability with the default configuration.
+
+The following table describes resource utilization under reference application load.
+
+.Resource utilization under reference application load
+[cols="1,2,3", width="90%", options="header"]
+|====
+|Metric
+|Limits
+|Notes
+
+|OpenShift platform CPU usage
+|Less than 4000mc – 2 cores (4HT)
+|Platform CPU is pinned to reserved cores, including both hyper-threads of each reserved core.
+The system is engineered to 3 CPUs (3000mc) at steady-state to allow for periodic system tasks and spikes.
+
+|OpenShift Platform memory
+|Less than 16G
+|
+
+|====
+--
diff --git a/modules/telco-ran-gitops-operator-and-ztp-plugins.adoc b/modules/telco-ran-gitops-operator-and-ztp-plugins.adoc
index 603188d3cf54..bef6647ffc0c 100644
--- a/modules/telco-ran-gitops-operator-and-ztp-plugins.adoc
+++ b/modules/telco-ran-gitops-operator-and-ztp-plugins.adoc
@@ -1,62 +1,52 @@
 // Module included in the following assemblies:
 //
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 // * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-gitops-operator-and-ztp-plugins_{context}"]
-= {gitops-shortname} and {ztp} plugins
+= GitOps Operator and {ztp}
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-{gitops-shortname} and {ztp} plugins provide a {gitops-shortname}-based infrastructure for managing cluster deployment and configuration.
++
+--
+GitOps Operator and {ztp} provide a GitOps-based infrastructure for managing cluster deployment and configuration.
 Cluster definitions and configurations are maintained as a declarative state in Git.
 You can apply `ClusterInstance` CRs to the hub cluster where the `SiteConfig` Operator renders them as installation CRs.
-Alternatively, you can use the {ztp} plugin to generate installation CRs directly from `SiteConfig` CRs.
-The {ztp} plugin supports automatic wrapping of configuration CRs in policies based on `PolicyGenTemplate` CRs.
-+
-[NOTE]
-====
-You can deploy and manage multiple versions of {product-title} on managed clusters using the baseline reference configuration CRs.
-You can use custom CRs alongside the baseline CRs.
-
-To maintain multiple per-version policies simultaneously, use Git to manage the versions of the source CRs and policy CRs (`PolicyGenTemplate` or `PolicyGenerator`).
-
-Keep reference CRs and custom CRs under different directories.
-Doing this allows you to patch and update the reference CRs by simple replacement of all directory contents without touching the custom CRs.
-====
-
-Limits::
-* 300 `SiteConfig` CRs per ArgoCD application.
-You can use multiple applications to achieve the maximum number of clusters supported by a single hub cluster.
+In earlier releases, a {ztp} plugin supported the generation of installation CRs from `SiteConfig` CRs.
+This plugin is now deprecated.
+A separate {ztp} plugin is available to enable automatic wrapping of configuration CRs into policies based on the `PolicyGenerator` or `PolicyGenTemplate` CR.
 
-* Content in the `/source-crs` folder in Git overrides content provided in the {ztp} plugin container.
-Git takes precedence in the search path.
-
-* Add the `/source-crs` folder in the same directory as the `kustomization.yaml` file, which includes the `PolicyGenTemplate` as a generator.
-+
-[NOTE]
-====
-Alternative locations for the `/source-crs` directory are not supported in this context.
-====
+You can deploy and manage multiple versions of {product-title} on managed clusters by using the baseline reference configuration CRs.
+You can use custom CRs alongside the baseline CRs.
+To maintain multiple per-version policies simultaneously, use Git to manage the versions of the source and policy CRs by using `PolicyGenerator` or `PolicyGenTemplate` CRs.
+--
 
-* The `extraManifestPath` field of the `SiteConfig` CR is deprecated from {product-title} 4.15 and later.
-Use the new `extraManifests.searchPaths` field instead.
+Limits and requirements::
+* 300 `ClusterInstance` CRs per ArgoCD application.
+Multiple applications can be used to achieve the maximum number of clusters supported by a single hub cluster
+* Content in the `source-crs/` directory in Git overrides content provided in the ZTP plugin container, as Git takes precedence in the search path.
+* The `source-crs/` directory is specifically expected to be located in the same directory as the `kustomization.yaml` file, which includes `PolicyGenerator` or `PolicyGenTemplate` CRs as a generator.
+Alternative locations for the `source-crs/` directory are not supported in this context.
 
 Engineering considerations::
 * For multi-node cluster upgrades, you can pause `MachineConfigPool` (`MCP`) CRs during maintenance windows by setting the `paused` field to `true`.
-You can increase the number of nodes per `MCP` updated simultaneously by configuring the `maxUnavailable` setting in the `MCP` CR.
+You can increase the number of simultaneously updated nodes per `MCP` CR by configuring the `maxUnavailable` setting in the `MCP` CR.
 The `MaxUnavailable` field defines the percentage of nodes in the pool that can be simultaneously unavailable during a `MachineConfig` update.
 Set `maxUnavailable` to the maximum tolerable value.
 This reduces the number of reboots in a cluster during upgrades which results in shorter upgrade times.
 When you finally unpause the `MCP` CR, all the changed configurations are applied with a single reboot.
-
-* During cluster installation, you can pause custom `MCP` CRs by setting the `paused` field to `true` and setting `maxUnavailable` to 100% to improve installation times.
-
-* To avoid confusion or unintentional overwriting of files when updating content, use unique and distinguishable names for user-provided CRs in the `/source-crs` folder and extra manifests in Git.
-
-* The `SiteConfig` CR allows multiple extra-manifest paths. When files with the same name are found in multiple directory paths, the last file found takes precedence.
-This allows you to put the full set of version-specific Day 0 manifests (extra-manifests) in Git and reference them from the `SiteConfig` CR.
-With this feature, you can deploy multiple {product-title} versions to managed clusters simultaneously.
+* During cluster installation, you can pause custom MCP CRs by setting the paused field to true and setting `maxUnavailable` to 100% to improve installation times.
+* Keep reference CRs and custom CRs under different directories.
+Doing this allows you to patch and update the reference CRs by simple replacement of all directory contents without touching the custom CRs.
+When managing multiple versions, the following best practices are recommended:
+** Keep all source CRs and policy creation CRs in Git repositories to ensure consistent generation of policies for each {product-title} version based solely on the contents in Git.
+** Keep reference source CRs in a separate directory from custom CRs.
+This facilitates easy update of reference CRs as required.
+* To avoid confusion or unintentional overwrites when updating content, it is highly recommended to use unique and distinguishable names for custom CRs in the `source-crs/` directory and extra manifests in Git.
+* Extra installation manifests are referenced in the `ClusterInstance` CR through a `ConfigMap` CR.
+The `ConfigMap` CR should be stored alongside the `ClusterInstance` CR in Git, serving as the single source of truth for the cluster.
+If needed, you can use a `ConfigMap` generator to create the `ConfigMap` CR.
diff --git a/modules/telco-ran-hub-cluster-management.adoc b/modules/telco-ran-hub-cluster-management.adoc
deleted file mode 100644
index 168eaa74555e..000000000000
--- a/modules/telco-ran-hub-cluster-management.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-ran-hub-cluster-management_{context}"]
-= Hub cluster management characteristics
-
-{rh-rhacm-first} is the recommended cluster management solution.
-Configure it to the following limits on the hub cluster:
-
-* Configure a maximum of 5 {rh-rhacm} policies with a compliant evaluation interval of at least 10 minutes.
-
-* Use a maximum of 10 managed cluster templates in policies.
-Where possible, use hub-side templating.
-
-* Disable all {rh-rhacm} add-ons except for the `policy-controller` and `observability-controller` add-ons.
-Set `Observability` to the default configuration.
-+
-[IMPORTANT]
-====
-Configuring optional components or enabling additional features will result in additional resource usage and can reduce overall system performance.
-
-For more information, see xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc#telco-reference-ran-du-deployment-components_ran-ref-design-components[Reference design deployment components].
-====
-
-.OpenShift platform resource utilization under reference application load
-[cols="1,2,3", width="90%", options="header"]
-|====
-|Metric
-|Limit
-|Notes
-
-|CPU usage
-|Less than 4000 mc – 2 cores (4 hyperthreads)
-|Platform CPU is pinned to reserved cores, including both hyperthreads in each reserved core. The system is engineered to use 3 CPUs (3000mc) at steady-state to allow for periodic system tasks and spikes.
-
-|Memory used
-|Less than 16G
-|
-|====
diff --git a/modules/telco-ran-lca-operator.adoc b/modules/telco-ran-lca-operator.adoc
index 173a570acb44..1935f163c9be 100644
--- a/modules/telco-ran-lca-operator.adoc
+++ b/modules/telco-ran-lca-operator.adoc
@@ -1,19 +1,18 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-lca-operator_{context}"]
-= {lcao}
+= Lifecycle Agent
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-The {lcao} provides local lifecycle management services for {sno} clusters.
+The Lifecycle Agent provides local lifecycle management services for {sno} clusters.
 
 Limits and requirements::
-* The {lcao} is not applicable in multi-node clusters or {SNO} clusters with an additional worker.
-
-* Requires a persistent volume that you create when installing the cluster.
-See "Configuring a shared container directory between ostree stateroots when using {ztp}" for partition requirements.
+* The Lifecycle Agent is not applicable in multi-node clusters or {sno} clusters with an additional worker.
+* The Lifecycle Agent requires a persistent volume that you create when installing the cluster.
+For descriptions of partition requirements, see "Configuring a shared container directory between ostree stateroots when using {ztp}".
diff --git a/modules/telco-ran-local-storage-operator.adoc b/modules/telco-ran-local-storage-operator.adoc
index 30ecf78842ca..68127e9989af 100644
--- a/modules/telco-ran-local-storage-operator.adoc
+++ b/modules/telco-ran-local-storage-operator.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-local-storage-operator_{context}"]
@@ -16,7 +16,5 @@ The number and type of `PV` resources that you create depends on your requiremen
 Engineering considerations::
 * Create backing storage for `PV` CRs before creating the `PV`.
 This can be a partition, a local volume, LVM volume, or full disk.
-* Refer to the device listing in `LocalVolume` CRs by the hardware path used to access each device to ensure correct allocation of disks and partitions.
+* Refer to the device listing in `LocalVolume` CRs by the hardware path used to access each device to ensure correct allocation of disks and partitions, for example, `/dev/disk/by-path/<id>`.
 Logical names (for example, `/dev/sda`) are not guaranteed to be consistent across node reboots.
-+
-For more information, see the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_file_systems/assembly_overview-of-persistent-naming-attributes_managing-file-systems#device-identifiers_assembly_overview-of-persistent-naming-attributes[{op-system-base} 9 documentation on device identifiers].
diff --git a/modules/telco-ran-logging.adoc b/modules/telco-ran-logging.adoc
index 921bde81ecde..7a480b4269ae 100644
--- a/modules/telco-ran-logging.adoc
+++ b/modules/telco-ran-logging.adoc
@@ -1,23 +1,19 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-logging_{context}"]
 = Logging
 
 New in this release::
-* Cluster Logging Operator 6.0 is new in this release.
-Update your existing implementation to adapt to the new version of the API.
+* No reference design updates in this release
 
 Description::
-Use logging to collect logs from the far edge node for remote analysis. The recommended log collector is Vector.
+Use logging to collect logs from the far edge node for remote analysis.
+The recommended log collector is Vector.
 
 Engineering considerations::
 * Handling logs beyond the infrastructure and audit logs, for example, from the application workload requires additional CPU and network bandwidth based on additional logging rate.
 * As of {product-title} 4.14, Vector is the reference log collector.
-+
-[NOTE]
-====
-Use of fluentd in the RAN use model is deprecated.
-====
+Use of fluentd in the RAN use models is deprecated.
diff --git a/modules/telco-ran-lvms-operator.adoc b/modules/telco-ran-lvms-operator.adoc
index 7b7a8abe12e1..4e1c1435dc22 100644
--- a/modules/telco-ran-lvms-operator.adoc
+++ b/modules/telco-ran-lvms-operator.adoc
@@ -1,27 +1,19 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-lvms-operator_{context}"]
-= {lvms}
+= Logical Volume Manager Storage
 
 New in this release::
 * No reference design updates in this release
 
-[NOTE]
-====
-{lvms-first} is an optional component.
-
-When you use {lvms} as the storage solution, it replaces the Local Storage Operator.
-CPU resources are assigned to the management partition as platform overhead.
-The reference configuration must include one of these storage solutions, but not both.
-====
-
 Description::
-{lvms} provides dynamic provisioning of block and file storage.
-{lvms} creates logical volumes from local devices that can be used as `PVC` resources by applications.
+{lvms-first} is an optional component.
+It provides dynamic provisioning of both block and file storage by creating logical volumes from local devices that can be consumed as persistent volume claim (PVC) resources by applications.
 Volume expansion and snapshots are also possible.
+An example configuration is provided in the RDS with the `StorageLVMCluster.yaml` file.
 
 Limits and requirements::
 * In {sno} clusters, persistent storage must be provided by either {lvms} or local storage, not both.
diff --git a/modules/telco-ran-machine-configuration.adoc b/modules/telco-ran-machine-configuration.adoc
index 26217dea031e..112a5af7ee16 100644
--- a/modules/telco-ran-machine-configuration.adoc
+++ b/modules/telco-ran-machine-configuration.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-machine-configuration_{context}"]
@@ -10,43 +10,37 @@ New in this release::
 * No reference design updates in this release
 
 Limits and requirements::
-* The CRI-O wipe disable `MachineConfig` assumes that images on disk are static other than during scheduled maintenance in defined maintenance windows.
+The CRI-O wipe disable `MachineConfig` CR assumes that images on disk are static other than during scheduled maintenance in defined maintenance windows.
 To ensure the images are static, do not set the pod `imagePullPolicy` field to `Always`.
-+
+
 .Machine configuration options
-[cols=2*, width="90%", options="header"]
+[cols="1,2", width="90%", options="header"]
 |====
 |Feature
 |Description
 
-|Container runtime
+|Container Runtime
 |Sets the container runtime to `crun` for all node roles.
 
-|kubelet config and container mount hiding
-|Reduces the frequency of kubelet housekeeping and eviction monitoring to reduce CPU usage.
-Create a container mount namespace, visible to kubelet and CRI-O, to reduce system mount scanning resource usage.
+|Kubelet config and container mount namespace hiding
+|Reduces the frequency of kubelet housekeeping and eviction monitoring, which reduces CPU usage
 
 |SCTP
 |Optional configuration (enabled by default)
-Enables SCTP. SCTP is required by RAN applications but disabled by default in {op-system}.
 
-|kdump
-a|Optional configuration (enabled by default)
+|Kdump
+|Optional configuration (enabled by default)
 Enables kdump to capture debug information when a kernel panic occurs.
-
-[NOTE]
-====
-The reference CRs which enable kdump have an increased memory reservation based on the set of drivers and kernel modules included in the reference configuration.
-====
+The reference CRs that enable kdump have an increased memory reservation based on the set of drivers and kernel modules included in the reference configuration.
 
 |CRI-O wipe disable
-|Disables automatic wiping of the CRI-O image cache after unclean shutdown.
+|Disables automatic wiping of the CRI-O image cache after unclean shutdown
 
 |SR-IOV-related kernel arguments
-|Includes additional SR-IOV related arguments in the kernel command line.
+|Include additional SR-IOV-related arguments in the kernel command line
 
-|RCU Normal systemd service
-|Sets `rcu_normal` after the system is fully started.
+|Set RCU Normal
+|Systemd service that sets `rcu_normal` after the system finishes startup
 
 |One-shot time sync
 |Runs a one-time NTP system time synchronization job for control plane or worker nodes.
diff --git a/modules/telco-ran-managed-cluster-resources.adoc b/modules/telco-ran-managed-cluster-resources.adoc
deleted file mode 100644
index 9d3be0effd74..000000000000
--- a/modules/telco-ran-managed-cluster-resources.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-ran-managed-cluster-resources_{context}"]
-= {rds-caps} worker node cluster resource utilization
-
-The maximum number of running pods in the system, inclusive of application workloads and {product-title} pods, is 120.
-
-Resource utilization::
-{product-title} resource utilization varies depending on many factors including application workload characteristics such as:
-
-* Pod count
-
-* Type and frequency of probes
-
-* Messaging rates on primary CNI or secondary CNI with kernel networking
-
-* API access rate
-
-* Logging rates
-
-* Storage IOPS
-
-Cluster resource requirements are applicable under the following conditions:
-
-* The cluster is running the described representative application workload.
-
-* The cluster is managed with the constraints described in "{rds-caps} worker node cluster resource utilization".
-
-* Components noted as optional in the RAN DU use model configuration are not applied.
-
-[IMPORTANT]
-====
-You will need to do additional analysis to determine the impact on resource utilization and ability to meet KPI targets for configurations outside the scope of the {rds-caps} reference design.
-You might have to allocate additional resources in the cluster depending on your requirements.
-====
diff --git a/modules/telco-ran-node-tuning-operator.adoc b/modules/telco-ran-node-tuning-operator.adoc
index b3ff36f83da6..460c24b7a2f7 100644
--- a/modules/telco-ran-node-tuning-operator.adoc
+++ b/modules/telco-ran-node-tuning-operator.adoc
@@ -1,57 +1,52 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-node-tuning-operator_{context}"]
-= Node Tuning Operator
+= CPU partitioning and performance tuning
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-You tune the cluster performance by creating a performance profile.
-+
-[IMPORTANT]
-====
+The RAN DU use model includes cluster performance tuning via `PerformanceProfile` CRs for low-latency performance.
+The `PerformanceProfile` CRs are reconciled by the Node Tuning Operator.
 The RAN DU use case requires the cluster to be tuned for low-latency performance.
-====
+For more details about node tuning with the `PerformanceProfile` CR, see "Tuning nodes for low latency with the performance profile".
 
 Limits and requirements::
-The Node Tuning Operator uses the `PerformanceProfile` CR to configure the cluster. You need to configure the following settings in the RAN DU profile `PerformanceProfile` CR:
-
-* Select reserved and isolated cores and ensure that you allocate at least 4 hyperthreads (equivalent to 2 cores) on Intel 3rd Generation Xeon (Ice Lake) 2.20 GHz CPUs or better with firmware tuned for maximum performance.
-
-* Set the reserved `cpuset` to include both hyperthread siblings for each included core.
-Unreserved cores are available as allocatable CPU for scheduling workloads.
-Ensure that hyperthread siblings are not split across reserved and isolated cores.
-
-* Configure reserved and isolated CPUs to include all threads in all cores based on what you have set as reserved and isolated CPUs.
-
-* Set core 0 of each NUMA node to be included in the reserved CPU set.
-
-* Set the huge page size to 1G.
-
+The Node Tuning Operator uses the `PerformanceProfile` CR to configure the cluster.
+You need to configure the following settings in the telco RAN DU profile `PerformanceProfile` CR:
++
+--
+* Set a reserved `cpuset` of 4 or more, equating to 4 hyper-threads (2 cores) for either of the following CPUs:
+** Intel 3rd Generation Xeon (IceLake) 2.20 GHz or better CPUs with host firmware tuned for maximum performance
+** AMD EPYC Zen 4 CPUs (Genoa, Bergamo, or newer)
++
 [NOTE]
 ====
-You should not add additional workloads to the management partition.
-Only those pods which are part of the OpenShift management platform should be annotated into the management partition.
+AMD EPYC Zen 4 CPUs (Genoa, Bergamo, or newer) are fully supported.
+Power consumption evaluations are ongoing.
+It is recommended to evaluate features, such as per-pod power management, to determine any potential impact on performance.
 ====
 
-Engineering considerations::
-* You should use the RT kernel to meet performance requirements. However, you can use the non-RT kernel with a corresponding impact to cluster performance if required.
+* Set the reserved `cpuset` to include both hyper-thread siblings for each included core.
+Unreserved cores are available as allocatable CPU for scheduling workloads.
+* Ensure that hyper-thread siblings are not split across reserved and isolated cores.
+* Ensure that reserved and isolated CPUs include all the threads for all cores in the CPU.
+* Include Core 0 for each NUMA node in the reserved CPU set.
+* Set the huge page size to 1G.
+* Only pin {product-title} pods which are by default configured as part of the management workload partition to reserved cores.
+--
 
-* The number of huge pages that you configure depends on the application workload requirements.
+Engineering considerations::
+* Meeting the full performance metrics requires use of the RT kernel.
+If required, you can use the non-RT kernel with corresponding impact to performance.
+* The number of hugepages you configure depends on application workload requirements.
 Variation in this parameter is expected and allowed.
-
 * Variation is expected in the configuration of reserved and isolated CPU sets based on selected hardware and additional components in use on the system.
-Variation must still meet the specified limits.
-
-* Hardware without IRQ affinity support impacts isolated CPUs.
-To ensure that pods with guaranteed whole CPU QoS have full use of the allocated CPU, all hardware in the server must support IRQ affinity.
-For more information, see "Finding the effective IRQ affinity setting for a node".
-
-When you enable workload partitioning during cluster deployment with the `cpuPartitioningMode: AllNodes` setting, the reserved CPU set in the `PerformanceProfile` CR must include enough CPUs for the operating system, interrupts, and OpenShift platform pods.
-
-:FeatureName: cgroups v1
-include::snippets/deprecated-feature.adoc[]
+The variation must still meet the specified limits.
+* Hardware without IRQ affinity support affects isolated CPUs.
+To ensure that pods with guaranteed whole CPU QoS have full use of allocated CPUs, all hardware in the server must support IRQ affinity.
+* When workload partitioning is enabled by setting `cpuPartitioningMode` to `AllNodes` during deployment, you must allocate enough CPUs to support the operating system, interrupts, and {product-title} pods in the `PerformanceProfile` CR.
diff --git a/modules/telco-ran-ptp-operator.adoc b/modules/telco-ran-ptp-operator.adoc
index 5cd5aa622776..c46ea79eb1ab 100644
--- a/modules/telco-ran-ptp-operator.adoc
+++ b/modules/telco-ran-ptp-operator.adoc
@@ -1,40 +1,26 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-ptp-operator_{context}"]
 = PTP Operator
 
 New in this release::
-* A new version two of the Precision Time Protocol (PTP) fast event REST API is available.
-Consumer applications can now subscribe directly to the events REST API in the PTP events producer sidecar.
-The PTP fast event REST API v2 is compliant with the link:https://orandownloadsweb.azurewebsites.net/download?id=344[O-RAN O-Cloud Notification API Specification for Event Consumers 3.0].
-You can change the API version by setting the `ptpEventConfig.apiVersion` field in the `PtpOperatorConfig` resource.
+* No reference design updates in this release
 
 Description::
-See "Recommended {sno} cluster configuration for vDU application workloads" for details of support and configuration of PTP in cluster nodes.
-The DU node can run in the following modes:
-+
-* As an ordinary clock (OC) synced to a grandmaster clock or boundary clock (T-BC).
-
-* As a grandmaster clock (T-GM) synced from GPS with support for single or dual card E810 NICs.
-
-* As dual boundary clocks (one per NIC) with support for E810 NICs.
-
-* As a T-BC with a highly available (HA) system clock when there are multiple time sources on different NICs.
-
-* Optional: as a boundary clock for radio units (RUs).
+Configure PTP in cluster nodes with `PTPConfig` CRs for the RAN DU use case with features like Grandmaster clock (T-GM) support via GPS, ordinary clock (OC), boundary clocks (T-BC), dual boundary clocks, high availability (HA), and optional fast event notification over HTTP.
+PTP ensures precise timing and reliability in the RAN environment.
 
 Limits and requirements::
-* Limited to two boundary clocks for dual NIC and HA.
-
-* Limited to two card E810 configurations for T-GM.
+* Limited to two boundary clocks for nodes with dual NICs and HA
+* Limited to two Westport channel NIC configurations for T-GM
 
 Engineering considerations::
-* Configurations are provided for ordinary clock, boundary clock, boundary clock with highly available system clock, and grandmaster clock.
-
-* PTP fast event notifications uses `ConfigMap` CRs to store PTP event subscriptions.
-
-*  The PTP events REST API v2 does not have a global subscription for all lower hierarchy resources contained in the resource path.
-You subscribe consumer applications to the various available event types separately.
+* RAN DU RDS configurations are provided for ordinary clocks, boundary clocks, grandmaster clocks, and highly available dual NIC boundary clocks.
+* PTP fast event notifications use `ConfigMap` CRs to persist subscriber details.
+* Hierarchical event subscription as described in the O-RAN specification is not supported for PTP events.
+* Use the PTP fast events REST API v2.
+The PTP fast events REST API v1 is deprecated.
+The REST API v2 is O-RAN Release 3 compliant.
diff --git a/modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc b/modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc
index de1f10690948..0c2f438e0aaf 100644
--- a/modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc
+++ b/modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc
@@ -1,34 +1,33 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-red-hat-advanced-cluster-management-rhacm_{context}"]
-= {rh-rhacm-title}
+= Red Hat Advanced Cluster Management
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-{rh-rhacm-first} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters.
-You manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
-+
-You apply policies with the {rh-rhacm} policy controller as managed by {cgu-operator-first}.
-The policy controller handles configuration, upgrades, and cluster statuses.
 +
-When installing managed clusters, {rh-rhacm} applies labels and initial ignition configuration to individual nodes in support of custom disk partitioning, allocation of roles, and allocation to machine config pools.
-You define these configurations with `SiteConfig` or `ClusterInstance` CRs.
+--
+{rh-rhacm} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters.
+You manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
+
+{rh-rhacm} provides the following functionality:
+
+* Zero touch provisioning (ZTP) of clusters using the MCE component in {rh-rhacm}.
+* Configuration, upgrades, and cluster status through the {rh-rhacm} policy controller.
+* During managed cluster installation, {rh-rhacm} can apply labels to individual nodes as configured through the `ClusterInstance` CR.
+--
 
 Limits and requirements::
-* 300 `SiteConfig` CRs per ArgoCD application.
-You can use multiple applications to achieve the maximum number of clusters supported by a single hub cluster.
 * A single hub cluster supports up to 3500 deployed {sno} clusters with 5 `Policy` CRs bound to each cluster.
 
 Engineering considerations::
 * Use {rh-rhacm} policy hub-side templating to better scale cluster configuration.
 You can significantly reduce the number of policies by using a single group policy or small number of general group policies where the group and per-cluster values are substituted into templates.
-
 * Cluster specific configuration: managed clusters typically have some number of configuration values that are specific to the individual cluster.
 These configurations should be managed using {rh-rhacm} policy hub-side templating with values pulled from `ConfigMap` CRs based on the cluster name.
-
 * To save CPU resources on managed clusters, policies that apply static configurations should be unbound from managed clusters after {ztp} installation of the cluster.
diff --git a/modules/telco-ran-ref-design-features.adoc b/modules/telco-ran-ref-design-features.adoc
deleted file mode 100644
index d6bfd4f9f8cf..000000000000
--- a/modules/telco-ran-ref-design-features.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="telco-ran-ref-design-features_{context}"]
-= {product-title} {product-version} features for {rds}
-
-The {product-version} version of the {rds} reference design specification (RDS) has the same feature set as the 4.14 version of the {rds} RDS.
-
-See link:https://docs.openshift.com/container-platform/4.14/telco_ref_design_specs/ran/telco-ran-ref-design-spec.html#telco-ran-ref-design-features_ran-ref-design-spec[{product-title} 4.14 {rds} features] for more information.
diff --git a/modules/telco-ran-siteconfig-operator.adoc b/modules/telco-ran-siteconfig-operator.adoc
new file mode 100644
index 000000000000..411b8f7da7a1
--- /dev/null
+++ b/modules/telco-ran-siteconfig-operator.adoc
@@ -0,0 +1,38 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-ran-siteconfig-operator_{context}"]
+= SiteConfig Operator
+
+New in this release::
+* No RDS updates in this release
+
+Description::
++
+--
+The SiteConfig Operator is a template-driven solution designed to provision clusters through various installation methods.
+It introduces the unified `ClusterInstance` API, which replaces the deprecated `SiteConfig` API.
+By leveraging the `ClusterInstance` API, the SiteConfig Operator improves cluster provisioning by providing the following:
+
+* Better isolation of definitions from installation methods
+* Unification of Git and non-Git workflows
+* Consistent APIs across installation methods
+* Enhanced scalability
+* Increased flexibility with custom installation templates
+* Valuable insights for troubleshooting deployment issues
+
+The SiteConfig Operator provides validated default installation templates to facilitate cluster deployment through both the Assisted Installer and Image-based Installer provisioning methods:
+
+* **Assisted Installer** automates the deployment of {product-title} clusters by leveraging predefined configurations and validated host setups.
+It ensures that the target infrastructure meets {product-title} requirements.
+The Assisted Installer streamlines the installation process while minimizing time and complexity compared to manual setup.
+
+* **Image-based Installer** expedites the deployment of {sno} clusters by utilizing preconfigured and validated {product-title} seed images.
+Seed images are preinstalled on target hosts, enabling rapid reconfiguration and deployment.
+The Image-based Installer is particularly well-suited for remote or disconnected environments, because it simplifies the cluster creation process and significantly reduces deployment time.
+--
+
+Limits and requirements::
+* A single hub cluster supports up to 3500 deployed {sno} clusters.
diff --git a/modules/telco-ran-sr-iov-operator.adoc b/modules/telco-ran-sr-iov-operator.adoc
index 2dc52e760eb5..379b4884c592 100644
--- a/modules/telco-ran-sr-iov-operator.adoc
+++ b/modules/telco-ran-sr-iov-operator.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-sr-iov-operator_{context}"]
@@ -11,28 +11,33 @@ New in this release::
 
 Description::
 The SR-IOV Operator provisions and configures the SR-IOV CNI and device plugins.
-Both `netdevice` (kernel VFs) and `vfio` (DPDK) devices are supported and applicable to the RAN use models.
+Both `netdevice` (kernel VFs) and `vfio` (DPDK) devices are supported and applicable to the RAN DU use models.
 
 Limits and requirements::
-* Use {product-title} supported devices
-* SR-IOV and IOMMU enablement in BIOS: The SR-IOV Network Operator will automatically enable IOMMU on the kernel command line.
-* SR-IOV VFs do not receive link state updates from the PF. If link down detection is needed you must configure this at the protocol level.
-* NICs which do not support firmware updates using Secure Boot or kernel lockdown must be pre-configured with sufficient virtual functions (VFs) to support the number of VFs required by the application workload.
-+
-[NOTE]
-====
-You might need to disable the SR-IOV Operator plugin for unsupported NICs using the undocumented `disablePlugins` option.
-====
+* Use devices that are supported for {product-title}.
+See "Supported devices".
+* SR-IOV and IOMMU enablement in host firmware settings: The SR-IOV Network Operator automatically enables IOMMU on the kernel command line.
+* SR-IOV VFs do not receive link state updates from the PF.
+If link down detection is required you must configure this at the protocol level.
 
 Engineering considerations::
 * SR-IOV interfaces with the `vfio` driver type are typically used to enable additional secondary networks for applications that require high throughput or low latency.
-
 * Customer variation on the configuration and number of `SriovNetwork` and `SriovNetworkNodePolicy` custom resources (CRs) is expected.
-
-* IOMMU kernel command line settings are applied with a `MachineConfig` CR at install time. This ensures that the `SriovOperator` CR does not cause a reboot of the node when adding them.
-
+* IOMMU kernel command line settings are applied with a `MachineConfig` CR at install time.
+This ensures that the `SriovOperator` CR does not cause a reboot of the node when adding them.
 * SR-IOV support for draining nodes in parallel is not applicable in a {sno} cluster.
-
-* If you exclude the `SriovOperatorConfig` CR from your deployment, the CR will not be created automatically.
-
-* In scenarios where you pin or restrict workloads to specific nodes, the SR-IOV parallel node drain feature will not result in the rescheduling of pods. In these scenarios, the SR-IOV Operator disables the parallel node drain functionality.
+* You must include the `SriovOperatorConfig` CR in your deployment; the CR is not created automatically.
+This CR is included in the reference configuration policies which are applied during initial deployment.
+* In scenarios where you pin or restrict workloads to specific nodes, the SR-IOV parallel node drain feature will not result in the rescheduling of pods.
+In these scenarios, the SR-IOV Operator disables the parallel node drain functionality.
+* NICs which do not support firmware updates under secure boot or kernel lockdown must be pre-configured with sufficient virtual functions (VFs) to support the number of VFs needed by the application workload.
+For Mellanox NICs, the Mellanox vendor plugin must be disabled in the SR-IOV Network Operator.
+For more information, see "Configuring an SR-IOV network device".
+* To change the MTU value of a virtual function after the pod has started, do not configure the MTU field in the `SriovNetworkNodePolicy` CR.
+Instead, configure the Network Manager or use a custom systemd script to set the MTU of the physical function to an appropriate value.
+For example:
++
+[source,terminal]
+----
+# ip link set dev <physical_function> mtu 9000
+----
diff --git a/modules/telco-ran-sriov-fec-operator.adoc b/modules/telco-ran-sriov-fec-operator.adoc
index 66e58e2781b9..a66ee2127e61 100644
--- a/modules/telco-ran-sriov-fec-operator.adoc
+++ b/modules/telco-ran-sriov-fec-operator.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-sriov-fec-operator_{context}"]
@@ -14,13 +14,10 @@ SRIOV-FEC Operator is an optional 3rd party Certified Operator supporting FEC ac
 
 Limits and requirements::
 * Starting with FEC Operator v2.7.0:
-
-** `SecureBoot` is supported
-
-** The `vfio` driver for the `PF` requires the usage of `vfio-token` that is injected into Pods.
-Applications in the pod can pass the `VF` token to DPDK by using the EAL parameter `--vfio-vf-token`.
+** Secure boot is supported
+** `vfio` drivers for PFs require the usage of a `vfio-token` that is injected into the pods.
+Applications in the pod can pass the VF token to DPDK by using EAL parameter `--vfio-vf-token`.
 
 Engineering considerations::
-* The SRIOV-FEC Operator uses CPU cores from the `isolated` CPU set.
-
+* The SRIOV-FEC Operator uses CPU cores from the isolated CPU set.
 * You can validate FEC readiness as part of the pre-checks for application deployment, for example, by extending the validation policy.
diff --git a/modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc b/modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc
index 56adeae2410a..63cea403fa6b 100644
--- a/modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc
+++ b/modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc
@@ -1,24 +1,34 @@
 // Module included in the following assemblies:
 //
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 // * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-topology-aware-lifecycle-manager-talm_{context}"]
-= {cgu-operator-full}
+= Topology Aware Lifecycle Manager
 
 New in this release::
 * No reference design updates in this release
 
 Description::
-{cgu-operator-first} is an Operator that runs only on the hub cluster for managing how changes including cluster and Operator upgrades, configuration, and so on are rolled out to the network.
+{cgu-operator-full} is an Operator that runs only on the hub cluster for managing how changes like cluster upgrades, Operator upgrades, and cluster configuration are rolled out to the network.
+{cgu-operator} supports the following features:
 
-Limits and requirements::
-* {cgu-operator} supports concurrent cluster deployment in batches of 400.
+* Progressive rollout of policy updates to fleets of clusters in user configurable batches.
+* Per-cluster actions add `ztp-done` labels or other user-configurable labels following configuration changes to managed clusters.
+* Precaching of {sno} clusters images: {cgu-operator} supports optional pre-caching of OpenShift, OLM Operator, and additional user images to {sno} clusters before initiating an upgrade.
+The precaching feature is not applicable when using the recommended image-based upgrade method for upgrading {sno} clusters.
+** Specifying optional pre-caching configurations with `PreCachingConfig` CRs.
+Review the link:https://github.com/openshift-kni/cluster-group-upgrades-operator/blob/main/config/pre-cache/precachingconfig.yaml[sample reference `PreCachingConfig` CR] for more information.
+** Excluding unused images with configurable filtering.
+** Enabling before and after pre-caching storage space validations with configurable space-required parameters.
 
-* Precaching and backup features are for {sno} clusters only.
+Limits and requirements::
+* Supports concurrent cluster deployment in batches of 400
+* Pre-caching and backup are limited to {sno} clusters only
 
 Engineering considerations::
-* Only policies that have the `ran.openshift.io/ztp-deploy-wave` annotation are automatically applied by {cgu-operator} during initial cluster installation.
-
-* You can create further `ClusterGroupUpgrade` CRs to control the policies that {cgu-operator} remediates.
+* The `PreCachingConfig` CR is optional and does not need to be created if you only need to precache platform-related OpenShift and OLM Operator images.
+* The `PreCachingConfig` CR must be applied before referencing it in the `ClusterGroupUpgrade` CR.
+* Only policies with the `ran.openshift.io/ztp-deploy-wave` annotation are automatically applied by {cgu-operator} during cluster installation.
+* Any policy can be remediated by {cgu-operator} under control of a user created `ClusterGroupUpgrade` CR.
diff --git a/modules/telco-ran-workload-partitioning.adoc b/modules/telco-ran-workload-partitioning.adoc
index 0f1edce6663e..411da42690cf 100644
--- a/modules/telco-ran-workload-partitioning.adoc
+++ b/modules/telco-ran-workload-partitioning.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-ran-workload-partitioning_{context}"]
@@ -10,17 +10,18 @@ New in this release::
 * No reference design updates in this release
 
 Description::
-Workload partitioning pins OpenShift platform and Day 2 Operator pods that are part of the DU profile to the reserved CPU set and removes the reserved CPU from node accounting.
+Workload partitioning pins {product-title} and Day 2 Operator pods that are part of the DU profile to the reserved CPU set and removes the reserved CPU from node accounting.
 This leaves all unreserved CPU cores available for user workloads.
+This leaves all non-reserved CPU cores available for user workloads.
+Workload partitioning is enabled through a capability set in installation parameters: `cpuPartitioningMode: AllNodes`.
+The set of management partition cores are set with the reserved CPU set that you configure in the `PerformanceProfile` CR.
 
 Limits and requirements::
 * `Namespace` and `Pod` CRs must be annotated to allow the pod to be applied to the management partition
-
 * Pods with CPU limits cannot be allocated to the partition.
 This is because mutation can change the pod QoS.
-
-* For more information about the minimum number of CPUs that can be allocated to the management partition, see xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc#telco-ran-node-tuning-operator_ran-ref-design-components[Node Tuning Operator].
+* For more information about the minimum number of CPUs that can be allocated to the management partition, see "Node Tuning Operator".
 
 Engineering considerations::
-* Workload Partitioning pins all management pods to reserved cores.
+* Workload partitioning pins all management pods to reserved cores.
 A sufficient number of cores must be allocated to the reserved set to account for operating system, management pods, and expected spikes in CPU use that occur when the workload starts, the node reboots, or other system events happen.
diff --git a/modules/telco-ran-yaml-ref-cluster-tuning.adoc b/modules/telco-ran-yaml-ref-cluster-tuning.adoc
deleted file mode 100644
index c3f3b9d962c7..000000000000
--- a/modules/telco-ran-yaml-ref-cluster-tuning.adoc
+++ /dev/null
@@ -1,70 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="cluster-tuning-yaml_{context}"]
-= Cluster tuning reference YAML
-
-[id="ztp-example-sno-yaml"]
-.example-sno.yaml
-[source,yaml]
-----
-include::snippets/ztp_example-sno.yaml[]
-----
-
-[id="ztp-consoleoperatordisable-yaml"]
-.ConsoleOperatorDisable.yaml
-[source,yaml]
-----
-include::snippets/ztp_ConsoleOperatorDisable.yaml[]
-----
-
-[id="ztp-09-openshift-marketplace-ns-yaml"]
-.09-openshift-marketplace-ns.yaml
-[source,yaml]
-----
-include::snippets/ztp_09-openshift-marketplace-ns.yaml[]
-----
-
-[id="ztp-defaultcatsrc-yaml"]
-.DefaultCatsrc.yaml
-[source,yaml]
-----
-include::snippets/ztp_DefaultCatsrc.yaml[]
-----
-
-[id="ztp-disableolmpprof-yaml"]
-.DisableOLMPprof.yaml
-[source,yaml]
-----
-include::snippets/ztp_DisableOLMPprof.yaml[]
-----
-
-[id="ztp-disconnectedicsp-yaml"]
-.DisconnectedICSP.yaml
-[source,yaml]
-----
-include::snippets/ztp_DisconnectedICSP.yaml[]
-----
-
-[id="ztp-operatorhub-yaml"]
-.OperatorHub.yaml
-[source,yaml]
-----
-include::snippets/ztp_OperatorHub.yaml[]
-----
-
-[id="ztp-reducemonitoringfootprint-yaml"]
-.ReduceMonitoringFootprint.yaml
-[source,yaml]
-----
-include::snippets/ztp_ReduceMonitoringFootprint.yaml[]
-----
-
-[id="ztp-disablesnonetworkdiag-yaml"]
-.DisableSnoNetworkDiag.yaml
-[source,yaml]
-----
-include::snippets/ztp_DisableSnoNetworkDiag.yaml[]
-----
diff --git a/modules/telco-ran-yaml-ref-day-2-operators.adoc b/modules/telco-ran-yaml-ref-day-2-operators.adoc
deleted file mode 100644
index cdb9cc5c4109..000000000000
--- a/modules/telco-ran-yaml-ref-day-2-operators.adoc
+++ /dev/null
@@ -1,343 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="day-2-operators-yaml_{context}"]
-= Day 2 Operators reference YAML
-
-[id="ztp-clusterlogforwarder-yaml"]
-.ClusterLogForwarder.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogForwarder.yaml[]
-----
-
-[id="ztp-clusterlogns-yaml"]
-.ClusterLogNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogNS.yaml[]
-----
-
-[id="ztp-clusterlogopergroup-yaml"]
-.ClusterLogOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogOperGroup.yaml[]
-----
-
-[id="ztp-clusterlogserviceaccount-yaml"]
-.ClusterLogServiceAccount.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogServiceAccount.yaml[]
-----
-
-[id="ztp-clusterlogserviceaccountauditbinding-yaml"]
-.ClusterLogServiceAccountAuditBinding.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogServiceAccountAuditBinding.yaml[]
-----
-
-[id="ztp-clusterlogserviceaccountinfrastructurebinding-yaml"]
-.ClusterLogServiceAccountInfrastructureBinding.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogServiceAccountInfrastructureBinding.yaml[]
-----
-
-[id="ztp-clusterlogsubscription-yaml"]
-.ClusterLogSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogSubscription.yaml[]
-----
-
-[id="ztp-imagebasedupgrade-yaml"]
-.ImageBasedUpgrade.yaml
-[source,yaml]
-----
-include::snippets/ztp_ImageBasedUpgrade.yaml[]
-----
-
-[id="ztp-lcasubscription-yaml"]
-.LcaSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_LcaSubscription.yaml[]
-----
-
-[id="ztp-lcasubscriptionns-yaml"]
-.LcaSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_LcaSubscriptionNS.yaml[]
-----
-
-[id="ztp-lcasubscriptionopergroup-yaml"]
-.LcaSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_LcaSubscriptionOperGroup.yaml[]
-----
-
-[id="ztp-storageclass-yaml"]
-.StorageClass.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageClass.yaml[]
-----
-
-[id="ztp-storagelv-yaml"]
-.StorageLV.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageLV.yaml[]
-----
-
-[id="ztp-storagens-yaml"]
-.StorageNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageNS.yaml[]
-----
-
-[id="ztp-storageopergroup-yaml"]
-.StorageOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageOperGroup.yaml[]
-----
-
-[id="ztp-storagesubscription-yaml"]
-.StorageSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageSubscription.yaml[]
-----
-
-[id="ztp-lvmoperatorstatus-yaml"]
-.LVMOperatorStatus.yaml
-[source,yaml]
-----
-include::snippets/ztp_LVMOperatorStatus.yaml[]
-----
-
-[id="ztp-storagelvmcluster-yaml"]
-.StorageLVMCluster.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageLVMCluster.yaml[]
-----
-
-[id="ztp-storagelvmsubscription-yaml"]
-.StorageLVMSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageLVMSubscription.yaml[]
-----
-
-[id="ztp-storagelvmsubscriptionns-yaml"]
-.StorageLVMSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageLVMSubscriptionNS.yaml[]
-----
-
-[id="ztp-storagelvmsubscriptionopergroup-yaml"]
-.StorageLVMSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_StorageLVMSubscriptionOperGroup.yaml[]
-----
-
-[id="ztp-performanceprofile-yaml"]
-.PerformanceProfile.yaml
-[source,yaml]
-----
-include::snippets/ztp_PerformanceProfile.yaml[]
-----
-
-[id="ztp-tunedperformancepatch-yaml"]
-.TunedPerformancePatch.yaml
-[source,yaml]
-----
-include::snippets/ztp_TunedPerformancePatch.yaml[]
-----
-
-[id="ztp-ptpconfigboundaryforevent-yaml"]
-.PtpConfigBoundaryForEvent.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigBoundaryForEvent.yaml[]
-----
-
-[id="ztp-ptpconfigforhaforevent-yaml"]
-.PtpConfigForHAForEvent.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigForHAForEvent.yaml[]
-----
-
-[id="ztp-ptpconfigmasterforevent-yaml"]
-.PtpConfigMasterForEvent.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigMasterForEvent.yaml[]
-----
-
-[id="ztp-ptpconfigslaveforevent-yaml"]
-.PtpConfigSlaveForEvent.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigSlaveForEvent.yaml[]
-----
-
-[id="ztp-ptpconfigboundary-yaml"]
-.PtpConfigBoundary.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigBoundary.yaml[]
-----
-
-[id="ztp-ptpconfigforha-yaml"]
-.PtpConfigForHA.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigForHA.yaml[]
-----
-
-[id="ztp-ptpconfigdualcardgmwpc-yaml"]
-.PtpConfigDualCardGmWpc.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigDualCardGmWpc.yaml[]
-----
-
-[id="ztp-ptpconfiggmwpc-yaml"]
-.PtpConfigGmWpc.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigGmWpc.yaml[]
-----
-
-[id="ztp-ptpconfigslave-yaml"]
-.PtpConfigSlave.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpConfigSlave.yaml[]
-----
-
-[id="ztp-ptpoperatorconfig-yaml"]
-.PtpOperatorConfig.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpOperatorConfig.yaml[]
-----
-
-[id="ztp-ptpoperatorconfigforevent-yaml"]
-.PtpOperatorConfigForEvent.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpOperatorConfigForEvent.yaml[]
-----
-
-[id="ztp-ptpsubscription-yaml"]
-.PtpSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpSubscription.yaml[]
-----
-
-[id="ztp-ptpsubscriptionns-yaml"]
-.PtpSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpSubscriptionNS.yaml[]
-----
-
-[id="ztp-ptpsubscriptionopergroup-yaml"]
-.PtpSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_PtpSubscriptionOperGroup.yaml[]
-----
-
-[id="ztp-acceleratorsns-yaml"]
-.AcceleratorsNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_AcceleratorsNS.yaml[]
-----
-
-[id="ztp-acceleratorsopergroup-yaml"]
-.AcceleratorsOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_AcceleratorsOperGroup.yaml[]
-----
-
-[id="ztp-acceleratorssubscription-yaml"]
-.AcceleratorsSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_AcceleratorsSubscription.yaml[]
-----
-
-[id="ztp-sriovfecclusterconfig-yaml"]
-.SriovFecClusterConfig.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovFecClusterConfig.yaml[]
-----
-
-[id="ztp-sriovnetwork-yaml"]
-.SriovNetwork.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovNetwork.yaml[]
-----
-
-[id="ztp-sriovnetworknodepolicy-yaml"]
-.SriovNetworkNodePolicy.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovNetworkNodePolicy.yaml[]
-----
-
-[id="ztp-sriovoperatorconfig-yaml"]
-.SriovOperatorConfig.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovOperatorConfig.yaml[]
-----
-
-[id="ztp-sriovoperatorconfigforsno-yaml"]
-.SriovOperatorConfigForSNO.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovOperatorConfigForSNO.yaml[]
-----
-
-[id="ztp-sriovsubscription-yaml"]
-.SriovSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscription.yaml[]
-----
-
-[id="ztp-sriovsubscriptionns-yaml"]
-.SriovSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscriptionNS.yaml[]
-----
-
-[id="ztp-sriovsubscriptionopergroup-yaml"]
-.SriovSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscriptionOperGroup.yaml[]
-----
diff --git a/modules/telco-ran-yaml-ref-machine-configuration.adoc b/modules/telco-ran-yaml-ref-machine-configuration.adoc
deleted file mode 100644
index 6064dec41467..000000000000
--- a/modules/telco-ran-yaml-ref-machine-configuration.adoc
+++ /dev/null
@@ -1,120 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="machine-configuration-yaml_{context}"]
-= Machine configuration reference YAML
-
-[id="ztp-enable-crun-master-yaml"]
-.enable-crun-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_enable-crun-master.yaml[]
-----
-
-[id="ztp-enable-crun-worker-yaml"]
-.enable-crun-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_enable-crun-worker.yaml[]
-----
-
-[id="ztp-99-crio-disable-wipe-master-yaml"]
-.99-crio-disable-wipe-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_99-crio-disable-wipe-master.yaml[]
-----
-
-[id="ztp-99-crio-disable-wipe-worker-yaml"]
-.99-crio-disable-wipe-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_99-crio-disable-wipe-worker.yaml[]
-----
-
-[id="ztp-06-kdump-master-yaml"]
-.06-kdump-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_06-kdump-master.yaml[]
-----
-
-[id="ztp-06-kdump-worker-yaml"]
-.06-kdump-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_06-kdump-worker.yaml[]
-----
-
-[id="ztp-01-container-mount-ns-and-kubelet-conf-master-yaml"]
-.01-container-mount-ns-and-kubelet-conf-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_01-container-mount-ns-and-kubelet-conf-master.yaml[]
-----
-
-[id="ztp-01-container-mount-ns-and-kubelet-conf-worker-yaml"]
-.01-container-mount-ns-and-kubelet-conf-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_01-container-mount-ns-and-kubelet-conf-worker.yaml[]
-----
-
-[id="ztp-99-sync-time-once-master-yaml"]
-.99-sync-time-once-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_99-sync-time-once-master.yaml[]
-----
-
-[id="ztp-99-sync-time-once-worker-yaml"]
-.99-sync-time-once-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_99-sync-time-once-worker.yaml[]
-----
-
-[id="ztp-03-sctp-machine-config-master-yaml"]
-.03-sctp-machine-config-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_03-sctp-machine-config-master.yaml[]
-----
-
-[id="ztp-03-sctp-machine-config-worker-yaml"]
-.03-sctp-machine-config-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_03-sctp-machine-config-worker.yaml[]
-----
-
-[id="ztp-08-set-rcu-normal-master-yaml"]
-.08-set-rcu-normal-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_08-set-rcu-normal-master.yaml[]
-----
-
-[id="ztp-08-set-rcu-normal-worker-yaml"]
-.08-set-rcu-normal-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_08-set-rcu-normal-worker.yaml[]
-----
-
-[id="ztp-07-sriov-related-kernel-args-master-yaml"]
-.07-sriov-related-kernel-args-master.yaml
-[source,yaml]
-----
-include::snippets/ztp_07-sriov-related-kernel-args-master.yaml[]
-----
-
-[id="ztp-07-sriov-related-kernel-args-worker-yaml"]
-.07-sriov-related-kernel-args-worker.yaml
-[source,yaml]
-----
-include::snippets/ztp_07-sriov-related-kernel-args-worker.yaml[]
-----
-
diff --git a/modules/telco-ran-yaml-ref-networking.adoc b/modules/telco-ran-yaml-ref-networking.adoc
deleted file mode 100644
index 3a9338d7a78c..000000000000
--- a/modules/telco-ran-yaml-ref-networking.adoc
+++ /dev/null
@@ -1,127 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="networking-yaml_{context}"]
-= Networking reference YAML
-
-[id="ztp-network-yaml"]
-.Network.yaml
-[source,yaml]
-----
-include::snippets/ztp_Network.yaml[]
-----
-
-[id="ztp-networkattachmentdefinition-yaml"]
-.networkAttachmentDefinition.yaml
-[source,yaml]
-----
-include::snippets/ztp_networkAttachmentDefinition.yaml[]
-----
-
-[id="ztp-sriovsubscriptionns-yaml"]
-.SriovSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscriptionNS.yaml[]
-----
-
-[id="ztp-sriovsubscriptionopergroup-yaml"]
-.SriovSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscriptionOperGroup.yaml[]
-----
-
-[id="ztp-sriovsubscription-yaml"]
-.SriovSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovSubscription.yaml[]
-----
-
-[id="ztp-sriovoperatorconfig-yaml"]
-.SriovOperatorConfig.yaml
-[source,yaml]
-----
-include::snippets/ztp_SriovOperatorConfig.yaml[]
-----
-
-[id="ztp-sriovnetworknodepolicy-yaml"]
-.sriovNetworkNodePolicy.yaml
-[source,yaml]
-----
-include::snippets/ztp_sriovNetworkNodePolicy.yaml[]
-----
-
-[id="ztp-sriovnetwork-yaml"]
-.sriovNetwork.yaml
-[source,yaml]
-----
-include::snippets/ztp_sriovNetwork.yaml[]
-----
-
-[id="ztp-metallbns-yaml"]
-.metallbNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_metallbNS.yaml[]
-----
-
-[id="ztp-metallbopergroup-yaml"]
-.metallbOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_metallbOperGroup.yaml[]
-----
-
-[id="ztp-metallbsubscription-yaml"]
-.metallbSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_metallbSubscription.yaml[]
-----
-
-[id="ztp-metallb-yaml"]
-.metallb.yaml
-[source,yaml]
-----
-include::snippets/ztp_metallb.yaml[]
-----
-
-[id="ztp-bgp-peer-yaml"]
-.bgp-peer.yaml
-[source,yaml]
-----
-include::snippets/ztp_bgp-peer.yaml[]
-----
-
-[id="ztp-bfd-profile-yaml"]
-.bfd-profile.yaml
-[source,yaml]
-----
-include::snippets/ztp_bfd-profile.yaml[]
-----
-
-[id="ztp-addr-pool-yaml"]
-.addr-pool.yaml
-[source,yaml]
-----
-include::snippets/ztp_addr-pool.yaml[]
-----
-
-[id="ztp-bgp-advr-yaml"]
-.bgp-advr.yaml
-[source,yaml]
-----
-include::snippets/ztp_bgp-advr.yaml[]
-----
-
-[id="ztp-mc_rootless_pods_selinux-yaml"]
-.mc_rootless_pods_selinux.yaml
-[source,yaml]
-----
-include::snippets/ztp_mc_rootless_pods_selinux.yaml[]
-----
-
diff --git a/modules/telco-ran-yaml-ref-other.adoc b/modules/telco-ran-yaml-ref-other.adoc
deleted file mode 100644
index 1becee383953..000000000000
--- a/modules/telco-ran-yaml-ref-other.adoc
+++ /dev/null
@@ -1,84 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="other-yaml_{context}"]
-= Other reference YAML
-
-[id="ztp-catalog-source-yaml"]
-.catalog-source.yaml
-[source,yaml]
-----
-include::snippets/ztp_catalog-source.yaml[]
-----
-
-[id="ztp-icsp-yaml"]
-.icsp.yaml
-[source,yaml]
-----
-include::snippets/ztp_icsp.yaml[]
-----
-
-[id="ztp-operator-hub-yaml"]
-.operator-hub.yaml
-[source,yaml]
-----
-include::snippets/ztp_operator-hub.yaml[]
-----
-
-[id="ztp-clusterlogns-yaml"]
-.ClusterLogNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogNS.yaml[]
-----
-
-[id="ztp-clusterlogopergroup-yaml"]
-.ClusterLogOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogOperGroup.yaml[]
-----
-
-[id="ztp-clusterlogsubscription-yaml"]
-.ClusterLogSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogSubscription.yaml[]
-----
-
-[id="ztp-clusterlogforwarder-yaml"]
-.ClusterLogForwarder.yaml
-[source,yaml]
-----
-include::snippets/ztp_ClusterLogForwarder.yaml[]
-----
-
-[id="ztp-control-plane-load-kernel-modules-yaml"]
-.control-plane-load-kernel-modules.yaml
-[source,yaml]
-----
-include::snippets/ztp_control-plane-load-kernel-modules.yaml[]
-----
-
-[id="ztp-worker-load-kernel-modules-yaml"]
-.worker-load-kernel-modules.yaml
-[source,yaml]
-----
-include::snippets/ztp_worker-load-kernel-modules.yaml[]
-----
-
-[id="ztp-sctp_module_mc-yaml"]
-.sctp_module_mc.yaml
-[source,yaml]
-----
-include::snippets/ztp_sctp_module_mc.yaml[]
-----
-
-[id="ztp-performanceprofile-yaml"]
-.PerformanceProfile.yaml
-[source,yaml]
-----
-include::snippets/ztp_PerformanceProfile.yaml[]
-----
diff --git a/modules/telco-ran-yaml-ref-resource-tuning.adoc b/modules/telco-ran-yaml-ref-resource-tuning.adoc
deleted file mode 100644
index a808ce145221..000000000000
--- a/modules/telco-ran-yaml-ref-resource-tuning.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="resource-tuning-yaml_{context}"]
-= Resource Tuning reference YAML
-
-[id="ztp-pid-limits-cr-yaml"]
-.pid-limits-cr.yaml
-[source,yaml]
-----
-include::snippets/ztp_pid-limits-cr.yaml[]
-----
-
-[id="ztp-control-plane-system-reserved-yaml"]
-.control-plane-system-reserved.yaml
-[source,yaml]
-----
-include::snippets/ztp_control-plane-system-reserved.yaml[]
-----
-
diff --git a/modules/telco-ran-yaml-ref-scheduling.adoc b/modules/telco-ran-yaml-ref-scheduling.adoc
deleted file mode 100644
index 598373fb6e59..000000000000
--- a/modules/telco-ran-yaml-ref-scheduling.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="scheduling-yaml_{context}"]
-= Scheduling reference YAML
-
-[id="ztp-nropsubscriptionns-yaml"]
-.NROPSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_NROPSubscriptionNS.yaml[]
-----
-
-[id="ztp-nropsubscriptionopergroup-yaml"]
-.NROPSubscriptionOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_NROPSubscriptionOperGroup.yaml[]
-----
-
-[id="ztp-nropsubscription-yaml"]
-.NROPSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_NROPSubscription.yaml[]
-----
-
-[id="ztp-nropsubscriptionns-yaml"]
-.NROPSubscriptionNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_NROPSubscriptionNS.yaml[]
-----
-
-[id="ztp-sched-yaml"]
-.sched.yaml
-[source,yaml]
-----
-include::snippets/ztp_sched.yaml[]
-----
-
-[id="ztp-nrop-yaml"]
-.nrop.yaml
-[source,yaml]
-----
-include::snippets/ztp_nrop.yaml[]
-----
-
diff --git a/modules/telco-ran-yaml-ref-storage.adoc b/modules/telco-ran-yaml-ref-storage.adoc
deleted file mode 100644
index 94669c05557d..000000000000
--- a/modules/telco-ran-yaml-ref-storage.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-// Module included in the following assemblies:
-//
-// *
-
-:_mod-docs-content-type: REFERENCE
-[id="storage-yaml_{context}"]
-= Storage reference YAML
-
-[id="ztp-odffns-yaml"]
-.odffNS.yaml
-[source,yaml]
-----
-include::snippets/ztp_odffNS.yaml[]
-----
-
-[id="ztp-odfopergroup-yaml"]
-.odfOperGroup.yaml
-[source,yaml]
-----
-include::snippets/ztp_odfOperGroup.yaml[]
-----
-
-[id="ztp-odfsubscription-yaml"]
-.odfSubscription.yaml
-[source,yaml]
-----
-include::snippets/ztp_odfSubscription.yaml[]
-----
-
-[id="ztp-01-rook-ceph-external-cluster-details.secret-yaml"]
-.01-rook-ceph-external-cluster-details.secret.yaml
-[source,yaml]
-----
-include::snippets/ztp_01-rook-ceph-external-cluster-details.secret.yaml[]
-----
-
-[id="ztp-02-ocs-external-storagecluster-yaml"]
-.02-ocs-external-storagecluster.yaml
-[source,yaml]
-----
-include::snippets/ztp_02-ocs-external-storagecluster.yaml[]
-----
-
diff --git a/modules/telco-ref-design-overview.adoc b/modules/telco-ref-design-overview.adoc
index 40b5f7e715f7..b272d2754b6a 100644
--- a/modules/telco-ref-design-overview.adoc
+++ b/modules/telco-ref-design-overview.adoc
@@ -1,9 +1,11 @@
 // Module included in the following assemblies:
 //
-// *
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+// * scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc
+
 :_mod-docs-content-type: CONCEPT
 [id="telco-ref-design-overview_{context}"]
-= Reference design specifications for telco 5G deployments
+= Reference design specifications for telco RAN DU 5G deployments
 
 Red Hat and certified partners offer deep technical expertise and support for networking and operational capabilities required to run telco applications on {product-title} {product-version} clusters.
 
@@ -15,3 +17,10 @@ Following the RDS minimizes high severity escalations and improves application s
 
 5G use cases are evolving and your workloads are continually changing.
 Red Hat is committed to iterating over the telco core and RAN DU RDS to support evolving requirements based on customer and partner feedback.
+
+The reference configuration includes the configuration of the far edge clusters and hub cluster components.
+
+The reference configurations in this document are deployed using a centrally managed hub cluster infrastructure as shown in the following image.
+
+.Telco RAN DU deployment architecture
+image::474_OpenShift_OpenShift_RAN_RDS_arch_updates_1023.png[A diagram showing two distinctive network far edge deployment processes, one showing how the hub cluster uses {ztp} to install managed clusters, and the other showing how the hub cluster uses TALM to apply policies to managed clusters]
diff --git a/modules/telco-reference-application-workload-characteristics.adoc b/modules/telco-reference-application-workload-characteristics.adoc
deleted file mode 100644
index 02d4e502c310..000000000000
--- a/modules/telco-reference-application-workload-characteristics.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// Module included in the following assemblies:
-//
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
-
-:_mod-docs-content-type: REFERENCE
-[id="telco-reference-application-workload-characteristics_{context}"]
-= {rds-caps} representative reference application workload characteristics
-
-The representative reference application workload has the following characteristics:
-
-* Has a maximum of 15 pods and 30 containers for the vRAN application including its management and control functions
-
-* Uses a maximum of 2 `ConfigMap` and 4 `Secret` CRs per pod
-
-* Uses a maximum of 10 exec probes with a frequency of not less than 10 seconds
-
-* Incremental application load on the `kube-apiserver` is less than 10% of the cluster platform usage
-+
-[NOTE]
-====
-You can extract CPU load can from the platform metrics.
-For example:
-
-[source,text]
-----
-query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
-----
-====
-
-* Application logs are not collected by the platform log collector
-
-* Aggregate traffic on the primary CNI is less than 1 MBps
diff --git a/modules/telco-update-acknowledging-the-update.adoc b/modules/telco-update-acknowledging-the-update.adoc
index 945397aac435..d2a1fddef48a 100644
--- a/modules/telco-update-acknowledging-the-update.adoc
+++ b/modules/telco-update-acknowledging-the-update.adoc
@@ -11,7 +11,7 @@ When you update to all versions from 4.11 and later, you must manually acknowled
 [IMPORTANT]
 ====
 Before you acknowledge the update, verify that there are no Kubernetes APIs in use that are removed in the version you are updating to.
-For example, in {product-title} 4.17, there are no API removals.
+For example, in {product-title} 4.18, there are no API removals.
 See "Kubernetes API removals" for more information.
 ====
 
diff --git a/modules/telco-update-acknowledging-the-y-stream-release-update.adoc b/modules/telco-update-acknowledging-the-y-stream-release-update.adoc
index f49b25bc099b..419d1afc57b5 100644
--- a/modules/telco-update-acknowledging-the-y-stream-release-update.adoc
+++ b/modules/telco-update-acknowledging-the-y-stream-release-update.adoc
@@ -12,7 +12,8 @@ In the output of the `oc adm upgrade` command, a URL is provided that shows the
 [IMPORTANT]
 ====
 Before you acknowledge the update, verify that there are no Kubernetes APIs in use that are removed in the version you are updating to.
-For example, in {product-title} 4.17, there are no API removals. See "Kubernetes API removals" for more information.
+For example, in {product-title} 4.18, there are no API removals.
+See "Kubernetes API removals" for more information.
 ====
 
 .Procedure
diff --git a/modules/telco-update-upgrading-the-worker-nodes.adoc b/modules/telco-update-upgrading-the-worker-nodes.adoc
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/modules/telemetry-showing-data-collected-from-the-cluster.adoc b/modules/telemetry-showing-data-collected-from-the-cluster.adoc
index 749e5581f9c9..6eb8ebc4c1bd 100644
--- a/modules/telemetry-showing-data-collected-from-the-cluster.adoc
+++ b/modules/telemetry-showing-data-collected-from-the-cluster.adoc
@@ -18,12 +18,12 @@ ifndef::openshift-enterprise,openshift-webscale,openshift-origin[]
 OpenShift Container Platform
 endif::openshift-enterprise,openshift-webscale,openshift-origin[]
 CLI (`oc`).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role or the `cluster-monitoring-view` role.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 .Procedure
 
diff --git a/modules/telemetry-what-information-is-collected.adoc b/modules/telemetry-what-information-is-collected.adoc
index 9bb5fd72d6c7..57ab5a237a4b 100644
--- a/modules/telemetry-what-information-is-collected.adoc
+++ b/modules/telemetry-what-information-is-collected.adoc
@@ -40,4 +40,3 @@ endif::openshift-dedicated[]
 * Usage details about Technology Previews and unsupported configurations
 
 Telemetry does not collect identifying information such as usernames or passwords. Red Hat does not intend to collect personal information. If Red Hat discovers that personal information has been inadvertently received, Red Hat will delete such information. To the extent that any telemetry data constitutes personal data, please refer to the link:https://www.redhat.com/en/about/privacy-policy[Red Hat Privacy Statement] for more information about Red Hat's privacy practices.
-
diff --git a/modules/templates-rails-creating-route-for-application.adoc b/modules/templates-rails-creating-route-for-application.adoc
index f6dca3f74c79..297964f26e66 100644
--- a/modules/templates-rails-creating-route-for-application.adoc
+++ b/modules/templates-rails-creating-route-for-application.adoc
@@ -16,6 +16,7 @@ ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 ----
 $ oc expose service rails-app --hostname=www.example.com
 ----
+endif::[]
 
 
 ifdef::openshift-online[]
diff --git a/modules/tls-profiles-kubelet-configuring.adoc b/modules/tls-profiles-kubelet-configuring.adoc
index 4a7b7f936bb8..0faf8842799d 100644
--- a/modules/tls-profiles-kubelet-configuring.adoc
+++ b/modules/tls-profiles-kubelet-configuring.adoc
@@ -20,9 +20,9 @@ endif::[]
 .Sample `KubeletConfig` CR that configures the `Old` TLS security profile on worker nodes
 [source,yaml]
 ----
-apiVersion: config.openshift.io/v1
+apiVersion: machineconfiguration.openshift.io/v1
 kind: KubeletConfig
- ...
+# ...
 spec:
   tlsSecurityProfile:
     old: {}
@@ -30,10 +30,10 @@ spec:
   machineConfigPoolSelector:
     matchLabels:
       pools.operator.machineconfiguration.openshift.io/worker: ""
-#...
+# ...
 ----
 
-You can see the ciphers and the minimum TLS version of the configured TLS security profile in the `kubelet.conf` file on a configured node.
+You can see the ciphers and the minimum TLS version of the configured TLS security profile in the `kubelet.conf` file on a configured node. 
 
 .Prerequisites
 
diff --git a/modules/troubleshooting-enabling-kdump-day-one.adoc b/modules/troubleshooting-enabling-kdump-day-one.adoc
index 3c4a1fdd6ae0..9d0dca5a85bf 100644
--- a/modules/troubleshooting-enabling-kdump-day-one.adoc
+++ b/modules/troubleshooting-enabling-kdump-day-one.adoc
@@ -70,14 +70,15 @@ systemd:
 
 [NOTE]
 ====
-To export the dumps to NFS targets, the `nfs` kernel module must be explicitly added to the configuration file:
+To export the dumps to NFS targets, some kernel modules must be explicitly added to the configuration file:
 
 .Example `/etc/kdump.conf` file
 [source,text]
 ----
 nfs server.example.com:/export/cores
 core_collector makedumpfile -l --message-level 7 -d 31
-extra_modules nfs
+extra_bins /sbin/mount.nfs 
+extra_modules nfs nfsv3 nfs_layout_nfsv41_files blocklayoutdriver nfs_layout_flexfiles nfs_layout_nfsv41_files
 ----
 ====
 
diff --git a/modules/understanding-agent-install.adoc b/modules/understanding-agent-install.adoc
index fe39119524ac..2faaeba70424 100644
--- a/modules/understanding-agent-install.adoc
+++ b/modules/understanding-agent-install.adoc
@@ -65,6 +65,7 @@ In the `install-config.yaml`, specify the platform on which to perform the insta
 
 * `baremetal`
 * `vsphere`
+* `external`
 * `none`
 +
 [IMPORTANT]
diff --git a/modules/update-preparing-ack.adoc b/modules/update-preparing-ack.adoc
index 26b558305c45..19223c1b1eca 100644
--- a/modules/update-preparing-ack.adoc
+++ b/modules/update-preparing-ack.adoc
@@ -6,7 +6,7 @@
 [id="update-preparing-ack_{context}"]
 = Providing the administrator acknowledgment
 
-After you have evaluated your cluster for any removed APIs and have migrated any removed APIs, you can acknowledge that your cluster is ready to upgrade from {product-title} 4.16 to 4.17.
+After you have evaluated your cluster for any removed APIs and have migrated any removed APIs, you can acknowledge that your cluster is ready to upgrade from {product-title} {ocp-nminus1} to {product-version}.
 
 [WARNING]
 ====
@@ -19,9 +19,9 @@ Be aware that all responsibility falls on the administrator to ensure that all u
 
 .Procedure
 
-* Run the following command to acknowledge that you have completed the evaluation and your cluster is ready for the Kubernetes API removals in {product-title} 4.17:
+* Run the following command to acknowledge that you have completed the evaluation and your cluster is ready for the Kubernetes API removals in {product-title} {product-version}:
 +
 [source,terminal]
 ----
-$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.15-kube-1.29-api-removals-in-4.17":"true"}}' --type=merge
+$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.15-kube-1.29-api-removals-in-4.18":"true"}}' --type=merge
 ----
diff --git a/modules/update-restricted.adoc b/modules/update-restricted.adoc
index f1a6e0925fba..c0225387eddc 100644
--- a/modules/update-restricted.adoc
+++ b/modules/update-restricted.adoc
@@ -54,5 +54,5 @@ Where:
 * If you used an `ImageContentSourcePolicy` or `ImageDigestMirrorSet`, you can use the canonical registry and repository names instead of the names you defined.
 The canonical registry name is `quay.io` and the canonical repository name is `openshift-release-dev/ocp-release`.
 
-* You can only configure global pull secrets for clusters that have an `ImageContentSourcePolicy` object. You cannot add a pull secret to a project.
+* You can only configure global pull secrets for clusters that have an `ImageContentSourcePolicy`, `ImageDigestMirrorSet`, or `ImageTagMirrorSet` object. You cannot add a pull secret to a project.
 ====
diff --git a/modules/update-upgrading-oc-adm-upgrade-status.adoc b/modules/update-upgrading-oc-adm-upgrade-status.adoc
index 9b4bb08b4d0a..936936984afe 100644
--- a/modules/update-upgrading-oc-adm-upgrade-status.adoc
+++ b/modules/update-upgrading-oc-adm-upgrade-status.adoc
@@ -41,42 +41,35 @@ $ oc adm upgrade status
 ----
 = Control Plane =
 Assessment:      Progressing
-Target Version:  4.14.1 (from 4.14.0)
-Completion:      97%
-Duration:        54m
+Target Version:  4.17.1 (from 4.17.0)
+Updating:        machine-config
+Completion:      97% (32 operators updated, 1 updating, 0 waiting)
+Duration:        54m (Est. Time Remaining: <10m)
 Operator Status: 32 Healthy, 1 Unavailable
 
 Control Plane Nodes
 NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
-ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
-ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
-ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
+ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.17.0    +10m
+ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?
+ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?
 
 = Worker Upgrade =
 
-= Worker Pool =
-Worker Pool:     worker
-Assessment:      Progressing
-Completion:      0%
-Worker Status:   3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded
-
-Worker Pool Nodes
-NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
-ip-10-0-4-159.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
-ip-10-0-20-162.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
-ip-10-0-99-40.us-east-2.compute.internal    Outdated      Pending    4.14.0    ?
+WORKER POOL   ASSESSMENT    COMPLETION   STATUS
+worker        Progressing   0% (0/2)     1 Available, 1 Progressing, 1 Draining
+infra         Progressing   50% (1/2)    1 Available, 1 Progressing, 1 Draining
 
-= Worker Pool =
-Worker Pool:     infra
-Assessment:      Progressing
-Completion:      0%
-Worker Status:   1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded
+Worker Pool Nodes: Worker
+NAME                                       ASSESSMENT    PHASE      VERSION   EST    MESSAGE
+ip-10-0-4-159.us-east-2.compute.internal   Progressing   Draining   4.17.0    +10m 
+ip-10-0-99-40.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?
 
-Worker Pool Node
+Worker Pool Nodes: infra
 NAME                                             ASSESSMENT    PHASE      VERSION   EST    MESSAGE
-ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.14.0    +10m
+ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.17.0    +10m
+ip-10-0-20-162.us-east-2.compute.internal        Completed     Updated    4.17.1    - 
 
 = Update Health =
 SINCE   LEVEL   IMPACT   MESSAGE
-14m4s   Info    None     Update is proceeding well
+54m4s   Info    None     Update is proceeding well
 ----
\ No newline at end of file
diff --git a/modules/updating-role-arn-oadp-rosa-sts.adoc b/modules/updating-role-arn-oadp-rosa-sts.adoc
new file mode 100644
index 000000000000..2928b9697bf0
--- /dev/null
+++ b/modules/updating-role-arn-oadp-rosa-sts.adoc
@@ -0,0 +1,163 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/application_backup_and_restore/oadp-rosa/oadp-rosa-backing-up-applications.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="updating-role-arn-oadp-rosa-sts_{context}"]
+= Updating the IAM role ARN in the {oadp-short} Operator subscription
+
+While installing the {oadp-short} Operator on a ROSA Security Token Service (STS) cluster, if you provide an incorrect IAM role Amazon Resource Name (ARN), the `openshift-adp-controller` pod gives an error. The credential requests that are generated contain the wrong IAM role ARN. To update the credential requests object with the correct IAM role ARN, you can edit the {oadp-short} Operator subscription and patch the IAM role ARN with the correct value. By editing the {oadp-short} Operator subscription, you do not have to uninstall and reinstall {oadp-short} to update the IAM role ARN.
+
+.Prerequisites
+
+ifdef::openshift-enterprise[]
+* You have a {product-rosa} STS cluster with the required access and tokens.
+endif::openshift-enterprise[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
+* You have a {product-title} STS cluster with the required access and tokens.
+endif::openshift-rosa,openshift-rosa-hcp[]
+* You have installed {oadp-short} on the ROSA STS cluster.
+
+.Procedure
+
+. To verify that the {oadp-short} subscription has the wrong IAM role ARN environment variable set, run the following command:
++
+[source,terminal]
+----
+$ oc get sub -o yaml redhat-oadp-operator
+----
++
+.Example subscription 
+[source,yaml]
+----
+apiVersion: operators.coreos.com/v1alpha1
+kind: Subscription
+metadata:
+  annotations:
+  creationTimestamp: "2025-01-15T07:18:31Z"
+  generation: 1
+  labels:
+    operators.coreos.com/redhat-oadp-operator.openshift-adp: ""
+  name: redhat-oadp-operator
+  namespace: openshift-adp
+  resourceVersion: "77363"
+  uid: 5ba00906-5ad2-4476-ae7b-ffa90986283d
+spec:
+  channel: stable-1.4
+  config:
+    env:
+    - name: ROLEARN
+      value: arn:aws:iam::11111111:role/wrong-role-arn # <1>
+  installPlanApproval: Manual
+  name: redhat-oadp-operator
+  source: prestage-operators
+  sourceNamespace: openshift-marketplace
+  startingCSV: oadp-operator.v1.4.2
+----
+<1> Verify the value of `ROLEARN` you want to update.
+
+. Update the `ROLEARN` field of the subscription with the correct role ARN by running the following command:
++
+[source,terminal]
+----
+$ oc patch subscription redhat-oadp-operator -p '{"spec": {"config": {"env": [{"name": "ROLEARN", "value": "<role_arn>"}]}}}' --type='merge'
+----
++
+where:
+
+`<role_arn>`:: Specifies the IAM role ARN to be updated. For example, `arn:aws:iam::160.....6956:role/oadprosa.....8wlf`.
+
+. Verify that the `secret` object is updated with correct role ARN value by running the following command:
++
+[source,terminal]
+----
+$ oc get secret cloud-credentials -o jsonpath='{.data.credentials}' | base64 -d
+----
++
+.Example output
++
+[source,terminal]
+----
+[default]
+sts_regional_endpoints = regional
+role_arn = arn:aws:iam::160.....6956:role/oadprosa.....8wlf
+web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
+----
+
+. Configure the `DataProtectionApplication` custom resource (CR) manifest file as shown in the following example:
++
+[source,yaml]
+----
+apiVersion: oadp.openshift.io/v1alpha1
+kind: DataProtectionApplication
+metadata:
+  name: test-rosa-dpa
+  namespace: openshift-adp
+spec:
+  backupLocations:
+  - bucket:
+      config:
+        region: us-east-1
+      cloudStorageRef:
+        name: <cloud_storage> # <1>
+      credential:
+        name: cloud-credentials
+        key: credentials
+      prefix: velero
+      default: true
+  configuration:
+    velero:
+      defaultPlugins:
+      - aws
+      - openshift
+----
+<1> Specify the `CloudStorage` CR.
+
+. Create the `DataProtectionApplication` CR by running the following command:
++
+[source,terminal]
+----
+$ oc create -f <dpa_manifest_file>
+----
+
+. Verify that the `DataProtectionApplication` CR is reconciled and the `status` is set to `"True"` by running the following command:
++
+[source,terminal]
+----
+$  oc get dpa -n openshift-adp -o yaml
+----
++
+.Example `DataProtectionApplication`
++
+[source,yaml]
+----
+apiVersion: oadp.openshift.io/v1alpha1
+kind: DataProtectionApplication
+...
+status:
+    conditions:
+    - lastTransitionTime: "2023-07-31T04:48:12Z"
+      message: Reconcile complete
+      reason: Complete
+      status: "True"
+      type: Reconciled
+----
+
+. Verify that the `BackupStorageLocation` CR is in an available state by running the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ oc get {oadp-bsl-api} -n openshift-adp
+----
++
+.Example `BackupStorageLocation`
++
+[source,terminal]
+----
+NAME       PHASE       LAST VALIDATED   AGE   DEFAULT
+ts-dpa-1   Available   3s               6s    true
+----
+
+
+
+
diff --git a/modules/upgrade-auto.adoc b/modules/upgrade-auto.adoc
index d3c335457fa2..2fa3ac16ddcc 100644
--- a/modules/upgrade-auto.adoc
+++ b/modules/upgrade-auto.adoc
@@ -20,7 +20,12 @@ You can use {cluster-manager} to schedule recurring, automatic upgrades for z-st
 . To schedule recurring upgrades, select *Recurring updates*.
 
 . Provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
-
++
+[IMPORTANT]
+====
+Before upgrading a Workload Identity Federation (WIF)-enabled {product-title} on {GCP} cluster, you must update the wif-config. For more information, see "Cluster upgrades with Workload Identity Federation (WIF)".
+====
++
 . Specify the day of the week and the time you want your cluster to upgrade.
 
 . Click *Save*.
diff --git a/modules/upgrade-manual.adoc b/modules/upgrade-manual.adoc
index 1a11c3621c62..45c6e1f88239 100644
--- a/modules/upgrade-manual.adoc
+++ b/modules/upgrade-manual.adoc
@@ -26,7 +26,12 @@ You can use {cluster-manager} to manually upgrade your {product-title} cluster o
 . Select the version you want to upgrade your cluster to. Recommended cluster upgrades appear in the UI. To learn more about each available upgrade version, click *View release notes*.
 
 . If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
-
++
+[IMPORTANT]
+====
+Before upgrading a Workload Identity Federation (WIF)-enabled {product-title} on {GCP} cluster, you must update the wif-config. For more information, see "Cluster upgrades with Workload Identity Federation (WIF)".
+====
++
 . Click *Next*.
 
 . To schedule your upgrade:
diff --git a/modules/upgrade.adoc b/modules/upgrade.adoc
index eec11dbf85d2..3b84101e42ca 100644
--- a/modules/upgrade.adoc
+++ b/modules/upgrade.adoc
@@ -9,6 +9,11 @@
 
 When upgrades are made available for your {product-title} cluster, you can upgrade to the newest version through {cluster-manager-first} or {cluster-manager} CLI. You can set your upgrade policies on existing clusters or during cluster creation, and upgrades can be scheduled to occur automatically or manually.
 
+[IMPORTANT]
+====
+Before upgrading a Workload Identity Federation (WIF)-enabled {product-title} on {GCP} cluster, you must update the wif-config. For more information, see "Cluster upgrades with Workload Identity Federation (WIF)".
+====
+
 Red Hat Site Reliability Engineers (SRE) will provide a curated list of available versions for your {product-title} clusters. For each cluster you will be able to review the full list of available releases, as well as the corresponding release notes. {cluster-manager} will enable installation of clusters at the latest supported versions, and upgrades can be canceled at any time.
 
 You can also set a grace period for how long `PodDisruptionBudget` protected workloads are respected during upgrades. After this grace period, any workloads protected by  `PodDisruptionBudget` that have not been successfully drained from a node, will be forcibly deleted.
@@ -62,3 +67,13 @@ For recurring upgrades, you will also receive email notifications before the upg
 * 1 week notice
 * 1 day notice
 ====
+
+[id="wif-upgrades_{context}"]
+== Cluster upgrades with Workload Identity Federation (WIF)
+Before upgrading an {product-title} on {GCP} cluster with WIF authentication type to a newer y-stream version, you must update the WIF configuration to that version as well. Failure to do so before attempting to upgrade the cluster version will result in an error.
+For more information on how to update a WIF configuration, see the  _Additional resources_ section.
+
+[NOTE]
+====
+The update path to a brand new release of {product-title} is not available in the stable channel until 45 to 90 days after the initial GA of a newer y-stream version.
+====
\ No newline at end of file
diff --git a/modules/using-aws-cli-create-iam-role-alb-controller.adoc b/modules/using-aws-cli-create-iam-role-alb-controller.adoc
index c3fccfa3b248..1516834abb98 100644
--- a/modules/using-aws-cli-create-iam-role-alb-controller.adoc
+++ b/modules/using-aws-cli-create-iam-role-alb-controller.adoc
@@ -30,7 +30,7 @@ $ cat <<EOF > albo-controller-trust-policy.json
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {
                 "StringEquals": {
-                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster" <2>
+                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" <2>
                 }
             }
         }
@@ -54,7 +54,7 @@ $ aws iam create-role --role-name albo-controller --assume-role-policy-document
 ROLE	arn:aws:iam::<aws_account_number>:role/albo-controller	2023-08-02T12:13:22Z <1>
 ASSUMEROLEPOLICYDOCUMENT	2012-10-17
 STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
-STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster
+STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager
 PRINCIPAL	arn:aws:iam:<aws_account_number>:oidc-provider/<cluster_oidc_endpoint>
 ----
 <1> Note the ARN of an {aws-short} IAM role for the {aws-short} Load Balancer Controller, such as `arn:aws:iam::777777777777:role/albo-controller`.
diff --git a/modules/using-aws-cli-create-iam-role-alb-operator.adoc b/modules/using-aws-cli-create-iam-role-alb-operator.adoc
index fda3c900a4b6..ed440bcf3b9e 100644
--- a/modules/using-aws-cli-create-iam-role-alb-operator.adoc
+++ b/modules/using-aws-cli-create-iam-role-alb-operator.adoc
@@ -30,7 +30,7 @@ $ cat <<EOF > albo-operator-trust-policy.json
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {
                 "StringEquals": {
-                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster" <2>
+                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" <2>
                 }
             }
         }
diff --git a/modules/using-cluster-compare-telco-core.adoc b/modules/using-cluster-compare-telco-core.adoc
new file mode 100644
index 000000000000..2eec787173fe
--- /dev/null
+++ b/modules/using-cluster-compare-telco-core.adoc
@@ -0,0 +1,158 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="using-cluster-compare-telco_core_{context}"]
+= Comparing a cluster with the {rds} reference configuration
+
+After you deploy a {rds} cluster, you can use the `cluster-compare` plugin to assess the cluster's compliance with the {rds} reference design specifications (RDS). The `cluster-compare` plugin is an OpenShift CLI (`oc`) plugin. The plugin uses a {rds} reference configuration to validate the cluster with the {rds} custom resources (CRs).
+
+The plugin-specific reference configuration for {rds} is packaged in a container image with the {rds} CRs.
+
+For further information about the `cluster-compare` plugin, see "Understanding the cluster-compare plugin".
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` role.
+
+* You have credentials to access the `registry.redhat.io` container image registry.
+
+* You installed the `cluster-compare` plugin.
+
+.Procedure
+
+. Log on to the container image registry with your credentials by running the following command:
++
+[source,terminal]
+----
+$ podman login registry.redhat.io
+----
+
+. Extract the content from the `telco-core-rds-rhel9` container image by running the following commands:
++
+[source,terminal]
+----
+$ mkdir -p ./out
+----
++
+[source,terminal]
+----
+$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out
+----
++
+You can view the reference configuration in the `reference-crs-kube-compare/` directory.
++
+[source,text]
+----
+out/telco-core-rds/configuration/reference-crs-kube-compare/
+├── metadata.yaml <1>
+├── optional <2>
+│   ├── logging
+│   ├── networking
+│   ├── other
+│   └── tuning
+└── required <3>
+    ├── networking
+    ├── other
+    ├── performance
+    ├── scheduling
+    └── storage
+----
+<1> Configuration file for the reference configuration.
+<2> Directory for optional templates.
+<3> Directory for required templates.
+
+. Compare the configuration for your cluster to the telco core reference configuration by running the following command:
++
+[source,terminal]
+----
+$ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml
+----
++
+.Example output
+[source,terminal]
+----
+W1212 14:13:06.281590   36629 compare.go:425] Reference Contains Templates With Types (kind) Not Supported By Cluster: BFDProfile, BGPAdvertisement, BGPPeer, ClusterLogForwarder, Community, IPAddressPool, MetalLB, MultiNetworkPolicy, NMState, NUMAResourcesOperator, NUMAResourcesScheduler, NodeNetworkConfigurationPolicy, SriovNetwork, SriovNetworkNodePolicy, SriovOperatorConfig, StorageCluster
+
+...
+
+**********************************
+
+Cluster CR: config.openshift.io/v1_OperatorHub_cluster <1>
+Reference File: required/other/operator-hub.yaml <2>
+Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
+--- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
++++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
+@@ -1,6 +1,6 @@
+ apiVersion: config.openshift.io/v1
+ kind: OperatorHub
+ metadata:
++  annotations: <3>
++    include.release.openshift.io/hypershift: "true"
+   name: cluster
+-spec:
+-  disableAllDefaultSources: true
+
+**********************************
+
+Summary <4>
+CRs with diffs: 3/4 <5>
+CRs in reference missing from the cluster: 22 <6>
+other:
+  other:
+    Missing CRs: <7>
+    - optional/other/control-plane-load-kernel-modules.yaml
+    - optional/other/worker-load-kernel-modules.yaml
+required-networking:
+  networking-root:
+    Missing CRs:
+    - required/networking/nodeNetworkConfigurationPolicy.yaml
+  networking-sriov:
+    Missing CRs:
+    - required/networking/sriov/sriovNetwork.yaml
+    - required/networking/sriov/sriovNetworkNodePolicy.yaml
+    - required/networking/sriov/SriovOperatorConfig.yaml
+    - required/networking/sriov/SriovSubscription.yaml
+    - required/networking/sriov/SriovSubscriptionNS.yaml
+    - required/networking/sriov/SriovSubscriptionOperGroup.yaml
+required-other:
+  scheduling:
+    Missing CRs:
+    - required/other/catalog-source.yaml
+    - required/other/icsp.yaml
+required-performance:
+  performance:
+    Missing CRs:
+    - required/performance/PerformanceProfile.yaml
+required-scheduling:
+  scheduling:
+    Missing CRs:
+    - required/scheduling/nrop.yaml
+    - required/scheduling/NROPSubscription.yaml
+    - required/scheduling/NROPSubscriptionNS.yaml
+    - required/scheduling/NROPSubscriptionOperGroup.yaml
+    - required/scheduling/sched.yaml
+required-storage:
+  storage-odf:
+    Missing CRs:
+    - required/storage/odf-external/01-rook-ceph-external-cluster-details.secret.yaml
+    - required/storage/odf-external/02-ocs-external-storagecluster.yaml
+    - required/storage/odf-external/odfNS.yaml
+    - required/storage/odf-external/odfOperGroup.yaml
+    - required/storage/odf-external/odfSubscription.yaml
+No CRs are unmatched to reference CRs <8>
+Metadata Hash: fe41066bac56517be02053d436c815661c9fa35eec5922af25a1be359818f297 <9>
+No patched CRs <10>
+----
+<1> The CR under comparison. The plugin displays each CR with a difference from the corresponding template.
+<2> The template matching with the CR for comparison.
+<3> The output in Linux diff format shows the difference between the template and the cluster CR.
+<4> After the plugin reports the line diffs for each CR, the summary of differences are reported.
+<5> The number of CRs in the comparison with differences from the corresponding templates.
+<6> The number of CRs represented in the reference configuration, but missing from the live cluster.
+<7> The list of CRs represented in the reference configuration, but missing from the live cluster.
+<8> The CRs that did not match to a corresponding template in the reference configuration.
+<9> The metadata hash identifies the reference configuration.
+<10> The list of patched CRs.
diff --git a/modules/using-cluster-compare-telco-ran.adoc b/modules/using-cluster-compare-telco-ran.adoc
new file mode 100644
index 000000000000..34dddbbbcace
--- /dev/null
+++ b/modules/using-cluster-compare-telco-ran.adoc
@@ -0,0 +1,130 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// *scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+// *scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+// *scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="using-cluster-compare-telco-ran_{context}"]
+= Comparing a cluster with the {rds} reference configuration
+
+After you deploy a {rds} cluster, you can use the `cluster-compare` plugin to assess the cluster's compliance with the {rds} reference design specifications (RDS). The `cluster-compare` plugin is an OpenShift CLI (`oc`) plugin. The plugin uses a {rds} reference configuration to validate the cluster with the {rds} custom resources (CRs).
+
+The plugin-specific reference configuration for {rds} is packaged in a container image with the {rds} CRs.
+
+For further information about the `cluster-compare` plugin, see "Understanding the cluster-compare plugin".
+
+.Prerequisites
+
+* You have access to the cluster as a user with the `cluster-admin` role.
+
+* You have credentials to access the `registry.redhat.io` container image registry.
+
+* You installed the `cluster-compare` plugin.
+
+.Procedure
+
+. Log on to the container image registry with your credentials by running the following command:
++
+[source,terminal]
+----
+$ podman login registry.redhat.io
+----
+
+. Extract the content from the `ztp-site-generate-rhel8` container image by running the following commands::
++
+[source,terminal,subs="attributes+"]
+----
+$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version}
+----
++
+[source,terminal]
+----
+$ mkdir -p ./out
+----
++
+[source,terminal,subs="attributes+"]
+----
+$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
+----
+
+. Compare the configuration for your cluster to the reference configuration by running the following command:
++
+[source,terminal]
+----
+$ oc cluster-compare -r out/reference/metadata.yaml
+----
++
+.Example output
+[source,terminal]
+----
+...
+
+**********************************
+
+Cluster CR: config.openshift.io/v1_OperatorHub_cluster <1>
+Reference File: required/other/operator-hub.yaml <2>
+Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
+--- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
++++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
+@@ -1,6 +1,6 @@
+ apiVersion: config.openshift.io/v1
+ kind: OperatorHub
+ metadata:
++  annotations: <3>
++    include.release.openshift.io/hypershift: "true"
+   name: cluster
+-spec:
+-  disableAllDefaultSources: true
+
+**********************************
+
+Summary <4>
+CRs with diffs: 11/12 <5>
+CRs in reference missing from the cluster: 40 <6>
+optional-image-registry:
+  image-registry:
+    Missing CRs: <7>
+    - optional/image-registry/ImageRegistryPV.yaml
+optional-ptp-config:
+  ptp-config:
+    One of the following is required:
+    - optional/ptp-config/PtpConfigBoundary.yaml
+    - optional/ptp-config/PtpConfigGmWpc.yaml
+    - optional/ptp-config/PtpConfigDualCardGmWpc.yaml
+    - optional/ptp-config/PtpConfigForHA.yaml
+    - optional/ptp-config/PtpConfigMaster.yaml
+    - optional/ptp-config/PtpConfigSlave.yaml
+    - optional/ptp-config/PtpConfigSlaveForEvent.yaml
+    - optional/ptp-config/PtpConfigForHAForEvent.yaml
+    - optional/ptp-config/PtpConfigMasterForEvent.yaml
+    - optional/ptp-config/PtpConfigBoundaryForEvent.yaml
+  ptp-operator-config:
+    One of the following is required:
+    - optional/ptp-config/PtpOperatorConfig.yaml
+    - optional/ptp-config/PtpOperatorConfigForEvent.yaml
+optional-storage:
+  storage:
+    Missing CRs:
+    - optional/local-storage-operator/StorageLV.yaml
+
+...
+
+No CRs are unmatched to reference CRs <8>
+Metadata Hash: 09650c31212be9a44b99315ec14d2e7715ee194a5d68fb6d24f65fd5ddbe3c3c <9>
+No patched CRs <10>
+----
+<1> The CR under comparison. The plugin displays each CR with a difference from the corresponding template.
+<2> The template matching with the CR for comparison.
+<3> The output in Linux diff format shows the difference between the template and the cluster CR.
+<4> After the plugin reports the line diffs for each CR, the summary of differences are reported.
+<5> The number of CRs in the comparison with differences from the corresponding templates.
+<6> The number of CRs represented in the reference configuration, but missing from the live cluster.
+<7> The list of CRs represented in the reference configuration, but missing from the live cluster.
+<8> The CRs that did not match to a corresponding template in the reference configuration.
+<9> The metadata hash identifies the reference configuration.
+<10> The list of patched CRs.
diff --git a/modules/using-cluster-compare-telco-ref.adoc b/modules/using-cluster-compare-telco-ref.adoc
index 8c82dcaa2545..73453bbab692 100644
--- a/modules/using-cluster-compare-telco-ref.adoc
+++ b/modules/using-cluster-compare-telco-ref.adoc
@@ -1,46 +1,19 @@
 // Module included in the following assemblies:
-
-// *scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
-// *scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+//
 // *scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
 
 :_mod-docs-content-type: PROCEDURE
 
-ifeval::["{context}" == "using-cluster-compare-plugin"]
-:cluster-compare:
-endif::[]
-
-ifeval::["{context}" == "ran-core-ref-design-crs"]
-:cluster-compare-core:
-endif::[]
-
-ifeval::["{context}" == "ran-ref-design-crs"]
-:cluster-compare-ran:
-endif::[]
-
 [id="using-cluster-compare-telco_ref_{context}"]
-ifdef::cluster-compare[= Example: Comparing a cluster with the telco core reference configuration]
-ifdef::cluster-compare-core,cluster-compare-ran[= Comparing a cluster with the {rds} reference configuration]
-
-//Intro for procedure in telco core/RAN RDS assembly
-ifdef::cluster-compare-core,cluster-compare-ran[]
-After you deploy a {rds} cluster, you can use the `cluster-compare` plugin to assess the cluster's compliance with the {rds} reference design specification (RDS). The `cluster-compare` plugin is an OpenShift CLI (`oc`) plugin. The plugin uses a {rds} reference configuration to validate the cluster with the {rds} custom resources (CRs). 
+= Example: Comparing a cluster with the telco core reference configuration
 
-The plugin-specific reference configuration for {rds} is packaged in a container image with the {rds} CRs. 
-
-For further information about the `cluster-compare` plugin, see "Understanding the cluster-compare plugin".
-endif::cluster-compare-core,cluster-compare-ran[]
-
-//Intro for procedure in cluster-compare assembly
-ifdef::cluster-compare[]
-You can use the `cluster-compare` plugin to compare a reference configuration with a configuration from a live cluster or `must-gather` data. 
+You can use the `cluster-compare` plugin to compare a reference configuration with a configuration from a live cluster or `must-gather` data.
 
 This example compares a configuration from a live cluster with the telco core reference configuration. The telco core reference configuration is derived from the telco core reference design specifications (RDS). The telco core RDS is designed for clusters to support large scale telco applications including control plane and some centralized data plane functions.
 
-The reference configuration is packaged in a container image with the telco core RDS. 
+The reference configuration is packaged in a container image with the telco core RDS.
 
 For further examples of using the `cluster-compare` plugin with the telco core and telco RAN distributed unit (DU) profiles, see the "Additional resources" section.
-endif::cluster-compare[]
 
 .Prerequisites
 
@@ -52,14 +25,13 @@ endif::cluster-compare[]
 
 .Procedure
 
-. Login to the container image registry with your credentials by running the following command:
+. Log on to the container image registry with your credentials by running the following command:
 +
 [source,terminal]
 ----
 $ podman login registry.redhat.io
 ----
 
-ifdef::cluster-compare-core,cluster-compare[]
 . Extract the content from the `telco-core-rds-rhel9` container image by running the following commands:
 +
 [source,terminal]
@@ -69,7 +41,7 @@ $ mkdir -p ./out
 +
 [source,terminal]
 ----
-$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
+$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out
 ----
 +
 You can view the reference configuration in the `reference-crs-kube-compare/` directory.
@@ -186,111 +158,3 @@ No patched CRs <10>
 <8> The CRs that did not match to a corresponding template in the reference configuration.
 <9> The metadata hash identifies the reference configuration.
 <10> The list of patched CRs.
-endif::cluster-compare-core,cluster-compare[]
-ifdef::cluster-compare-ran[]
-. Extract the content from the `ztp-site-generate-rhel8` container image by running the following commands::
-+
-[source,terminal,subs="attributes+"]
-----
-$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version}
-----
-+
-[source,terminal]
-----
-$ mkdir -p ./out
-----
-+
-[source,terminal,subs="attributes+"]
-----
-$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
-----
-
-. Compare the configuration for your cluster to the reference configuration by running the following command:
-+
-[source,terminal]
-----
-$ oc cluster-compare -r out/reference/metadata.yaml
-----
-+
-.Example output
-[source,terminal]
-----
-...
-
-**********************************
-
-Cluster CR: config.openshift.io/v1_OperatorHub_cluster <1>
-Reference File: required/other/operator-hub.yaml <2>
-Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
---- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
-+++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
-@@ -1,6 +1,6 @@
- apiVersion: config.openshift.io/v1
- kind: OperatorHub
- metadata:
-+  annotations: <3>
-+    include.release.openshift.io/hypershift: "true"
-   name: cluster
--spec:
--  disableAllDefaultSources: true
-
-**********************************
-
-Summary <4>
-CRs with diffs: 11/12 <5>
-CRs in reference missing from the cluster: 40 <6>
-optional-image-registry:
-  image-registry:
-    Missing CRs: <7>
-    - optional/image-registry/ImageRegistryPV.yaml
-optional-ptp-config:
-  ptp-config:
-    One of the following is required:
-    - optional/ptp-config/PtpConfigBoundary.yaml
-    - optional/ptp-config/PtpConfigGmWpc.yaml
-    - optional/ptp-config/PtpConfigDualCardGmWpc.yaml
-    - optional/ptp-config/PtpConfigForHA.yaml
-    - optional/ptp-config/PtpConfigMaster.yaml
-    - optional/ptp-config/PtpConfigSlave.yaml
-    - optional/ptp-config/PtpConfigSlaveForEvent.yaml
-    - optional/ptp-config/PtpConfigForHAForEvent.yaml
-    - optional/ptp-config/PtpConfigMasterForEvent.yaml
-    - optional/ptp-config/PtpConfigBoundaryForEvent.yaml
-  ptp-operator-config:
-    One of the following is required:
-    - optional/ptp-config/PtpOperatorConfig.yaml
-    - optional/ptp-config/PtpOperatorConfigForEvent.yaml
-optional-storage:
-  storage:
-    Missing CRs:
-    - optional/local-storage-operator/StorageLV.yaml
-
-...
-
-No CRs are unmatched to reference CRs <8>
-Metadata Hash: 09650c31212be9a44b99315ec14d2e7715ee194a5d68fb6d24f65fd5ddbe3c3c <9>
-No patched CRs <10>
-----
-<1> The CR under comparison. The plugin displays each CR with a difference from the corresponding template.
-<2> The template matching with the CR for comparison.
-<3> The output in Linux diff format shows the difference between the template and the cluster CR.
-<4> After the plugin reports the line diffs for each CR, the summary of differences are reported.
-<5> The number of CRs in the comparison with differences from the corresponding templates.
-<6> The number of CRs represented in the reference configuration, but missing from the live cluster.
-<7> The list of CRs represented in the reference configuration, but missing from the live cluster.
-<8> The CRs that did not match to a corresponding template in the reference configuration.
-<9> The metadata hash identifies the reference configuration.
-<10> The list of patched CRs.
-endif::cluster-compare-ran[]
-
-ifeval::["{context}" == "cluster-compare"]
-:!cluster-compare:
-endif::[]
-
-ifeval::["{context}" == "cluster-compare-core"]
-:!cluster-compare-core:
-endif::[]
-
-ifeval::["{context}" == "cluster-compare-ran"]
-:!cluster-compare-ran:
-endif::[]
diff --git a/modules/using-pull-secret.adoc b/modules/using-pull-secret.adoc
new file mode 100644
index 000000000000..4592ecd4df21
--- /dev/null
+++ b/modules/using-pull-secret.adoc
@@ -0,0 +1,83 @@
+// Module included in the following assemblies:
+// * openshift_images/using-image-pull-secrets
+// * openshift_images/managing-image-streams.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="using-pull-secret_{context}"]
+= Using a pull secret in a workload
+
+You can use a pull secret to allow workloads to pull images from a private registry with one of the following methods:
+
+* By linking the secret to a `ServiceAccount`, which automatically applies the secret to all pods using that service account.
+* By defining `imagePullSecrets` directly in workload configurations, which is useful for environments like GitOps or ArgoCD.
+
+.Procedure
+
+* You can use a secret for pulling images for pods by adding the secret to your service account. Note that the name of the service account should match the name of the service account that pod uses. The default service account is `default`.
+
+** Enter the following command to link the pull secret to a `ServiceAccount`:
++
+[source,terminal]
+----
+$ oc secrets link default <pull_secret_name> --for=pull
+----
+
+** To verify the change, enter the following command:
++
+[source,terminal]
+----
+$ oc get serviceaccount default -o yaml
+----
++
+.Example output
++
+[source,yaml]
+----
+apiVersion: v1
+imagePullSecrets:
+- name: default-dockercfg-123456
+- name: <pull_secret_name>
+kind: ServiceAccount
+metadata:
+  annotations:
+    openshift.io/internal-registry-pull-secret-ref: <internal_registry_pull_secret>
+  creationTimestamp: "2025-03-03T20:07:52Z"
+  name: default
+  namespace: default
+  resourceVersion: "13914"
+  uid: 9f62dd88-110d-4879-9e27-1ffe269poe3
+secrets:
+- name: <pull_secret_name>
+----
+
+* Instead of linking the secret to a service account, you can alternatively reference it directly in your pod or workload definition. This is useful for GitOps workflows such as ArgoCD. For example:
++
+.Example pod specification
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: <secure_pod_name>
+spec:
+  containers:
+  - name: <container_name>
+    image: quay.io/my-private-image
+  imagePullSecrets:
+  - name: <pull_secret_name>
+----
++
+.Example ArgoCD workflow
++
+[source,yaml]
+----
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+  generateName: <example_workflow>
+spec:
+  entrypoint: <main_task>
+  imagePullSecrets:
+  - name: <pull_secret_name>
+----
\ No newline at end of file
diff --git a/modules/velero-oadp-version-relationship.adoc b/modules/velero-oadp-version-relationship.adoc
index 8b1c02b6228b..46c1cd0e3de0 100644
--- a/modules/velero-oadp-version-relationship.adoc
+++ b/modules/velero-oadp-version-relationship.adoc
@@ -1,3 +1,9 @@
+// Module included in the following assemblies:
+//
+// backup_and_restore/application_backup_and_restore/installing/oadp-installing-operator.adoc
+// backup_and_restore/application_backup_and_restore/troubleshooting.adoc
+//
+
 :_mod-docs-content-type: CONCEPT
 [id="velero-oadp-version-relationship_{context}"]
 = OADP-Velero-{product-title} version relationship
@@ -5,21 +11,14 @@
 [cols="3", options="header"]
 |===
 |OADP version |Velero version |{product-title} version
-| 1.1.0 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.1 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.2 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.3 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.4 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.5 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.9 and later
-| 1.1.6 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.11 and later
-| 1.1.7 | link:https://{velero-domain}/docs/v1.9]/[1.9] | 4.11 and later
-| 1.2.0 | link:https://{velero-domain}/docs/v1.11/[1.11] | 4.11 and later
-| 1.2.1 | link:https://{velero-domain}/docs/v1.11/[1.11] | 4.11 and later
-| 1.2.2 | link:https://{velero-domain}/docs/v1.11/[1.11] | 4.11 and later
-| 1.2.3 | link:https://{velero-domain}/docs/v1.11/[1.11] | 4.11 and later
-| 1.3.0 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.10 - 4.15
-| 1.3.1 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.10 - 4.15
-| 1.3.2 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.10 - 4.15
-| 1.4.0 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14 and later
-| 1.4.1 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14 and later
+| 1.3.0 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.3.1 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.3.2 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.3.3 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.3.4 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.3.5 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
+| 1.4.0 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
+| 1.4.1 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
+| 1.4.2 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
+| 1.4.3 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
 |===
diff --git a/modules/verifying-cluster-install-oci-agent-based.adoc b/modules/verifying-cluster-install-oci-agent-based.adoc
index 78d2059c02d6..113d731c1917 100644
--- a/modules/verifying-cluster-install-oci-agent-based.adoc
+++ b/modules/verifying-cluster-install-oci-agent-based.adoc
@@ -2,7 +2,43 @@
 //
 // * installing/installing_oci/installing-oci-agent-based-installer.adoc
 
+ifeval::["{context}" == "installing-c3-agent-based-installer"]
+:c3:
+endif::[]
+
+ifeval::["{context}" == "installing-pca-agent-based-installer"]
+:pca:
+endif::[]
+
 :_mod-docs-content-type: PROCEDURE
+
+ifdef::c3[]
+[id="verifying-cluster-install-oci-agent-based_{context}"]
+= Verifying that your Agent-based cluster installation runs on {oci-c3-short}
+
+Verify that your cluster was installed and is running effectively on {oci-c3-short}.
+
+.Prerequisites
+
+* You created all the required {oci-c3} resources and services. See the "Creating {oci-c3-no-rt} infrastructure resources and services" section.
+* You created `install-config.yaml` and `agent-config.yaml` configuration files. See the "Creating configuration files for installing a cluster on {oci-c3-short}" section.
+* You uploaded the agent ISO image to a default Oracle Object Storage bucket, and you created a compute instance on {oci-c3-short}. For more information, see "Running a cluster on {oci-c3-short}".
+endif::c3[]
+
+ifdef::pca[]
+[id="verifying-cluster-install-oci-agent-based_{context}"]
+= Verifying that your Agent-based cluster installation runs on {oci-pca-short}
+
+Verify that your cluster was installed and is running effectively on {oci-pca-short}.
+
+.Prerequisites
+
+* You created all the required {oci-pca} resources and services. See the "Creating {oci-pca-no-rt} infrastructure resources and services" section.
+* You created `install-config.yaml` and `agent-config.yaml` configuration files. See the "Creating configuration files for installing a cluster on {oci-pca-short}" section.
+* You uploaded the agent ISO image to a default Oracle Object Storage bucket, and you created a compute instance on {oci-pca-short}. For more information, see "Running a cluster on {oci-pca-short}".
+endif::pca[]
+
+ifndef::pca,c3[]
 [id="verifying-cluster-install-oci-agent-based_{context}"]
 = Verifying that your Agent-based cluster installation runs on {oci}
 
@@ -12,7 +48,8 @@ Verify that your cluster was installed and is running effectively on {oci-first}
 
 * You created all the required {oci} resources and services. See the "Creating OCI infrastructure resources and services" section.
 * You created `install-config.yaml` and `agent-config.yaml` configuration files. See the "Creating configuration files for installing a cluster on OCI" section.
-* You uploaded the agent ISO image to Oracle’s default Object Storage bucket, and you created a compute instance on {oci}. For more information, see "Running a cluster on OCI".
+* You uploaded the agent ISO image to a default Oracle Object Storage bucket, and you created a compute instance on {oci}. For more information, see "Running a cluster on OCI".
+endif::pca,c3[]
 
 .Procedure
 
@@ -63,8 +100,16 @@ $ oc get co
 [source,terminal]
 ----
 NAME           VERSION     AVAILABLE  PROGRESSING    DEGRADED   SINCE   MESSAGE
-authentication 4.17.0-0    True       False          False      6m18s
-baremetal      4.17.0-0    True       False          False      2m42s
-network        4.17.0-0    True       True           False      5m58s  Progressing: …
+authentication 4.18.0-0    True       False          False      6m18s
+baremetal      4.18.0-0    True       False          False      2m42s
+network        4.18.0-0    True       True           False      5m58s  Progressing: …
     …
 ----
+
+ifeval::["{context}" == "installing-c3-agent-based-installer"]
+:!c3:
+endif::[]
+
+ifeval::["{context}" == "installing-pca-agent-based-installer"]
+:!pca:
+endif::[]
\ No newline at end of file
diff --git a/modules/virt-about-aaq-operator.adoc b/modules/virt-about-aaq-operator.adoc
index 35db16c73e44..2c2eb4f74b58 100644
--- a/modules/virt-about-aaq-operator.adoc
+++ b/modules/virt-about-aaq-operator.adoc
@@ -51,10 +51,10 @@ metadata:
 spec:
   quota:
     hard:
-    requests.memory: 1Gi
-    limits.memory: 1Gi
-    requests.cpu/vmi: "1"
-    requests.memory/vmi: 1Gi
+      requests.memory: 1Gi
+      limits.memory: 1Gi
+      requests.cpu/vmi: "1"
+      requests.memory/vmi: 1Gi
   selector:
     annotations: null
     labels:
diff --git a/modules/virt-about-auto-bootsource-updates.adoc b/modules/virt-about-auto-bootsource-updates.adoc
index 7ac395ffb649..948962070e28 100644
--- a/modules/virt-about-auto-bootsource-updates.adoc
+++ b/modules/virt-about-auto-bootsource-updates.adoc
@@ -15,4 +15,4 @@ When the `enableCommonBootImageImport` feature gate is disabled, `DataSource` ob
 
 _Custom_ boot sources that are not provided by {VirtProductName} are not controlled by the feature gate. You must manage them individually by editing the `HyperConverged` custom resource (CR). You can also use this method to manage individual system-defined boot sources.
 
-Cluster administrators can enable automatic subscription for {op-system-base-full} virtual machines in the {VirtProductName} web console.
\ No newline at end of file
+Cluster administrators can enable automatic subscription for {op-system-base-full} virtual machines in the {product-title} web console.
\ No newline at end of file
diff --git a/modules/virt-about-control-plane-only-updates.adoc b/modules/virt-about-control-plane-only-updates.adoc
index 62f423a6902b..4dcc786f1349 100644
--- a/modules/virt-about-control-plane-only-updates.adoc
+++ b/modules/virt-about-control-plane-only-updates.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="virt-about-control-plane-only-updates_{context}"]
-= About Control Plane Only updates
+= Control Plane Only updates
 
 Every even-numbered minor version of {product-title}, including 4.10 and 4.12, is an Extended Update Support (EUS) version. However, because Kubernetes design mandates serial minor version updates, you cannot directly update from one EUS version to the next.
 
@@ -12,8 +12,10 @@ After you update from the source EUS version to the next odd-numbered minor vers
 
 When the {product-title} update succeeds, the corresponding update for {VirtProductName} becomes available. You can now update {VirtProductName} to the target EUS version.
 
-[id="preparing-to-update_{context}"]
-== Preparing to update
+For more information about EUS versions, see the link:https://access.redhat.com/support/policy/updates/openshift[Red Hat OpenShift Container Platform Life Cycle Policy].
+
+[id="prerequisites_{context}"]
+== Prerequisites
 
 Before beginning a Control Plane Only update, you must:
 
diff --git a/modules/virt-about-services.adoc b/modules/virt-about-services.adoc
index 9c2f89f2e9a2..b38b6d09a72f 100644
--- a/modules/virt-about-services.adoc
+++ b/modules/virt-about-services.adoc
@@ -15,9 +15,16 @@ NodePort:: Exposes the service on the same port of each selected node in the clu
 
 LoadBalancer:: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP address to the service.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [NOTE]
 ====
 For on-premise clusters, you can configure a load-balancing service by deploying the MetalLB Operator.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+[NOTE]
+====
+For {product-rosa}, you must use `externalTrafficPolicy: Cluster` when configuring a load-balancing service, to minimize the network downtime during live migration.
+====
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/modules/virt-about-storage-volumes-for-vm-disks.adoc b/modules/virt-about-storage-volumes-for-vm-disks.adoc
index 733d947f9c19..d7f4f9b1a028 100644
--- a/modules/virt-about-storage-volumes-for-vm-disks.adoc
+++ b/modules/virt-about-storage-volumes-for-vm-disks.adoc
@@ -14,10 +14,10 @@ For best results, use the `ReadWriteMany` (RWX) access mode and the `Block` volu
 * `ReadWriteMany` (RWX) access mode is required for live migration.
 
 * The `Block` volume mode performs significantly better than the `Filesystem` volume mode. This is because the `Filesystem` volume mode uses more storage layers, including a file system layer and a disk image file. These layers are not necessary for VM disk storage.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 For example, if you use {rh-storage-first}, Ceph RBD volumes are preferable to CephFS volumes.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [IMPORTANT]
 ====
diff --git a/modules/virt-about-upgrading-virt.adoc b/modules/virt-about-upgrading-virt.adoc
index fa6e6c0fce7e..a78f9fed6f84 100644
--- a/modules/virt-about-upgrading-virt.adoc
+++ b/modules/virt-about-upgrading-virt.adoc
@@ -6,36 +6,53 @@
 [id="virt-about-upgrading-virt_{context}"]
 = About updating {VirtProductName}
 
-* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
+When you install {VirtProductName}, you select an update channel and an approval strategy. The update channel determines the versions that {VirtProductName} will be updated to. The approval strategy setting determines whether updates occur automatically or require manual approval. Both settings can impact supportability.
+
+[id="recommended-settings_{context}"]
+== Recommended settings
+
+To maintain a supportable environment, use the following settings:
 
-* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you update {product-title} to the next minor version. You cannot update {VirtProductName} to the next minor version without first updating {product-title}.
+* Update channel: *stable* 
+* Approval strategy: *Automatic* 
 
-* {VirtProductName} subscriptions use a single update channel that is named *stable*. The *stable* channel ensures that your {VirtProductName} and {product-title} versions are compatible.
+With these settings, the update process automatically starts when a new version of the Operator is available in the *stable* channel. This ensures that your {VirtProductName} and {product-title} versions remain compatible, and that your version of {VirtProductName} is suitable for production environments.
 
-* If your subscription's approval strategy is set to *Automatic*, the update process starts as soon as a new version of the Operator is available in the *stable* channel. It is highly recommended to use the *Automatic* approval strategy to maintain a supportable environment. Each minor version of {VirtProductName} is only supported if you run the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
+[NOTE]
+====
+Each minor version of {VirtProductName} is supported only if you run the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
+====
 
-** Though it is possible to select the *Manual* approval strategy, this is not recommended because it risks the supportability and functionality of your cluster. With the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported.
+[id="what-to-expect_{context}"]
+== What to expect
 
 * The amount of time an update takes to complete depends on your network
 connection. Most automatic updates complete within fifteen minutes.
 
 * Updating {VirtProductName} does not interrupt network connections.
 
-* Data volumes and their associated persistent volume claims are preserved during update.
+* Data volumes and their associated persistent volume claims are preserved during an update.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 If you have virtual machines running that use hostpath provisioner storage, they cannot be live migrated and might block an {product-title} cluster update.
 
 As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
 ====
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 If you have virtual machines running that use AWS Elastic Block Store (EBS) storage, they cannot be live migrated and might block an {product-title} cluster update.
 
 As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+[id="how-updates-work_{context}"]
+== How updates work
+
+* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
+
+* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you update {product-title} to the next minor version. You cannot update {VirtProductName} to the next minor version without first updating {product-title}.
\ No newline at end of file
diff --git a/modules/virt-about-vm-snapshots.adoc b/modules/virt-about-vm-snapshots.adoc
index b559f538487e..12ac47075686 100644
--- a/modules/virt-about-vm-snapshots.adoc
+++ b/modules/virt-about-vm-snapshots.adoc
@@ -18,7 +18,13 @@ The snapshot stores a copy of each Container Storage Interface (CSI) volume atta
 You can perform the following snapshot actions:
 
 * Create a new snapshot
-* Create a copy of a virtual machine from a snapshot
+* Create a clone of a virtual machine from a snapshot
++
+[IMPORTANT]
+====
+Cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
+====
+
 * List all snapshots attached to a specific VM
 * Restore a VM from a snapshot
 * Delete an existing VM snapshot
diff --git a/modules/virt-about-vtpm-devices.adoc b/modules/virt-about-vtpm-devices.adoc
index 7b83ee1aae60..46d926fd1b0d 100644
--- a/modules/virt-about-vtpm-devices.adoc
+++ b/modules/virt-about-vtpm-devices.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/virt-using-vtpm-devices.adoc
+// * virt/managing_vms/virt-using-vtpm-devices.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="virt-about-vtpm-devices_{context}"]
@@ -8,14 +8,10 @@
 
 A virtual Trusted Platform Module (vTPM) device functions like a
 physical Trusted Platform Module (TPM) hardware chip.
-
 You can use a vTPM device with any operating system, but Windows 11 requires
 the presence of a TPM chip to install or boot. A vTPM device allows VMs created
 from a Windows 11 image to function without a physical TPM chip.
 
-If you do not enable vTPM, then the VM does not recognize a TPM device, even if
-the node has one.
-
 A vTPM device also protects virtual machines by storing secrets without physical hardware. {VirtProductName} supports persisting vTPM device state by using Persistent Volume Claims (PVCs) for VMs. You must specify the storage class to be used by the PVC by setting the `vmStateStorageClass` attribute in the `HyperConverged` custom resource (CR):
 
 [source,yaml]
@@ -29,7 +25,6 @@ spec:
 # ...
 ----
 
-[NOTE]
-====
-The storage class must be of type `Filesystem` and support the `ReadWriteMany` (RWX) access mode.
-====
+If you do not enable vTPM, then the VM does not recognize a TPM device, even if
+the node has one.
+
diff --git a/modules/virt-about-workload-updates.adoc b/modules/virt-about-workload-updates.adoc
index 770dceefacb5..470b3abd8fa9 100644
--- a/modules/virt-about-workload-updates.adoc
+++ b/modules/virt-about-workload-updates.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="virt-about-workload-updates_{context}"]
-= About workload updates
+= VM workload updates
 
 When you update {VirtProductName}, virtual machine workloads, including `libvirt`, `virt-launcher`, and `qemu`, update automatically if they support live migration.
 
diff --git a/modules/virt-accessing-rdp-console.adoc b/modules/virt-accessing-rdp-console.adoc
index 4e0aa7436bba..ec5c2feb29b9 100644
--- a/modules/virt-accessing-rdp-console.adoc
+++ b/modules/virt-accessing-rdp-console.adoc
@@ -25,7 +25,7 @@ metadata:
   name: vm-ephemeral
   namespace: example-namespace
 spec:
-  running: false
+  runStrategy: Halted
   template:
     metadata:
       labels:
diff --git a/modules/virt-adding-vtpm-to-vm.adoc b/modules/virt-adding-vtpm-to-vm.adoc
index 9cc3ce6226c5..5ca4c7f1aa8f 100644
--- a/modules/virt-adding-vtpm-to-vm.adoc
+++ b/modules/virt-adding-vtpm-to-vm.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/virt-using-vtpm-devices.adoc
+// * virt/managing_vms/virt-using-vtpm-devices.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-adding-vtpm-to-vm_{context}"]
@@ -12,7 +12,6 @@ TPM device. A vTPM device also stores secrets for that VM.
 
 .Prerequisites
 * You have installed the OpenShift CLI (`oc`).
-* You have configured a Persistent Volume Claim (PVC) to use a storage class of type `Filesystem` that supports the `ReadWriteMany` (RWX) access mode. This is necessary for the vTPM device data to persist across VM reboots.
 
 .Procedure
 
diff --git a/modules/virt-applying-node-placement-rules.adoc b/modules/virt-applying-node-placement-rules.adoc
index be324d2f6178..68affff54142 100644
--- a/modules/virt-applying-node-placement-rules.adoc
+++ b/modules/virt-applying-node-placement-rules.adoc
@@ -22,7 +22,7 @@ endif::openshift-rosa,openshift-dedicated[]
 
 . Edit the object in your default editor by running the following command:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
 $ oc edit <resource_type> <resource_name> -n {CNVNamespace}
 ----
diff --git a/modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc b/modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc
index 987774ce0661..10e5b2180330 100644
--- a/modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc
+++ b/modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc
@@ -22,7 +22,7 @@ kind: VirtualMachine
 metadata:
   name: vm-server
 spec:
-  running: true
+  runStrategy: Always
   template:
     spec:
       domain:
diff --git a/modules/virt-attaching-vm-to-primary-udn.adoc b/modules/virt-attaching-vm-to-primary-udn.adoc
new file mode 100644
index 000000000000..d9033e202df7
--- /dev/null
+++ b/modules/virt-attaching-vm-to-primary-udn.adoc
@@ -0,0 +1,50 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc
+
+:_mod-docs-content-type: PROCEDURE                                
+[id="virt-attaching-vm-to-primary-udn_{context}"]                                  
+= Attaching a virtual machine to the primary user-defined network by using the CLI
+
+You can connect a virtual machine (VM) to the primary user-defined network (UDN) by requesting the pod network attachment, and configuring the interface binding.
+
+.Prerequisites
+* You have installed the OpenShift CLI (`oc`).
+
+.Procedure
+. Edit the `VirtualMachine` manifest to add the UDN interface details, as in the following example:
++
+.Example `VirtualMachine` manifest
+[source,yaml]
+----
+apiVersion: kubevirt.io/v1
+kind: VirtualMachine
+metadata:
+  name: example-vm
+  namespace: my-namespace # <1>
+spec:
+  template:
+    spec:
+      domain:
+        devices:
+          interfaces:
+            - name: udn-l2-net # <2>
+              binding: 
+                name: l2bridge # <3>
+# ...
+      networks:
+      - name: udn-l2-net # <4>
+        pod: {}
+# ...
+----
+<1> The namespace in which the VM is located. This value must match the namespace in which the UDN is defined.
+<2> The name of the user-defined network interface.
+<3> The name of the binding plugin that is used to connect the interface to the VM. The required value is `l2bridge`.
+<4> The name of the network. This must match the value of the `spec.template.spec.domain.devices.interfaces.name` field.
+
+. Apply the `VirtualMachine` manifest by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/virt-aws-bm.adoc b/modules/virt-aws-bm.adoc
index 54eaab5bbf34..bb5e24514d68 100644
--- a/modules/virt-aws-bm.adoc
+++ b/modules/virt-aws-bm.adoc
@@ -1,7 +1,7 @@
 // Module included in the following assemblies:
 //
 // * virt/install/preparing-cluster-for-virt.adoc
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 :_mod-docs-content-type: CONCEPT
 [id="virt-aws-bm_{context}"]
 = {VirtProductName} on AWS bare metal
@@ -12,29 +12,29 @@ You can run {VirtProductName} on an Amazon Web Services (AWS) bare-metal {produc
 ====
 {VirtProductName} is also supported on {product-rosa} (ROSA) Classic clusters, which have the same configuration requirements as AWS bare-metal clusters.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 :_mod-docs-content-type: CONCEPT
 [id="virt-aws-bm_{context}"]
 = {VirtProductName} on {product-title}
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 You can run {VirtProductName} on a {product-rosa} (ROSA) Classic cluster.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated[]
 You can run {VirtProductName} on a {product-dedicated} cluster.
 endif::openshift-dedicated[]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 Before you set up your cluster, review the following summary of supported features and limitations:
 
 Installing::
 --
 *  You can install the cluster by using installer-provisioned infrastructure, ensuring that you specify bare-metal instance types for the worker nodes. For example, you can use the `c5n.metal` type value for a machine based on x86_64 architecture.
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 You specify bare-metal instance types by editing the `install-config.yaml` file.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 +
 For more information, see the {product-title} documentation about installing on AWS.
 --
@@ -48,16 +48,16 @@ Accessing virtual machines (VMs)::
 
 Networking::
 // Hiding the following in ROSA/OSD because SR-IOV is not supported.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 --
 * You cannot use Single Root I/O Virtualization (SR-IOV) or bridge Container Network Interface (CNI) networks, including virtual LAN (VLAN). If your application requires a flat layer 2 network or control over the IP pool, consider using OVN-Kubernetes secondary overlay networks.
 --
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 --
 * If your application requires a flat layer 2 network or control over the IP pool, consider using OVN-Kubernetes secondary overlay networks.
 --
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 Storage::
 --
@@ -106,9 +106,9 @@ AWS bare-metal and ROSA clusters might have different supported storage solution
 Consider using CSI storage, which supports ReadWriteMany (RWX), cloning, and snapshots to enable live migration, fast VM creation, and VM snapshots capabilities.
 --
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Hosted control planes (HCPs)::
 --
 * HCPs for {VirtProductName} are not currently supported on AWS infrastructure.
 --
-endif::openshift-dedicated,openshift-rosa[]
\ No newline at end of file
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/modules/virt-change-vm-instance-type.adoc b/modules/virt-change-vm-instance-type.adoc
new file mode 100644
index 000000000000..7f0cf6c4f856
--- /dev/null
+++ b/modules/virt-change-vm-instance-type.adoc
@@ -0,0 +1,39 @@
+// Module included in the following assemblies:
+//
+// * virt/managing_vms/virt-edit-vms.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-change-vm-instance-type_{context}"]
+
+= Changing the instance type of a VM
+
+You can change the instance type associated with a running virtual machine (VM) by using the web console. The change takes effect immediately.
+
+.Prerequisites
+
+* You created the VM by using an instance type.
+
+.Procedure
+
+. In the {product-title} web console, click *Virtualization* -> *VirtualMachines*.
+
+. Select a VM to open the *VirtualMachine details* page.
+
+. Click the *Configuration* tab.
+
+. On the *Details* tab, click the instance type text to open the *Edit Instancetype* dialog. For example, click *1 CPU | 2 GiB Memory*.
+
+. Edit the instance type by using the *Series* and *Size* lists.
+.. Select an item from the *Series* list to show the relevant sizes for that series. For example, select *General Purpose*.
+.. Select the VM's new instance type from the *Size* list. For example, select *medium: 1 CPUs, 4Gi Memory*, which is available in the *General Purpose* series.
+
+. Click *Save*.
+
+.Verification
+
+. Click the *YAML* tab.
+
+. Click *Reload*.
+
+. Review the VM YAML to confirm that the instance type changed.
+
diff --git a/modules/virt-changing-update-settings.adoc b/modules/virt-changing-update-settings.adoc
new file mode 100644
index 000000000000..9bbb01d4105b
--- /dev/null
+++ b/modules/virt-changing-update-settings.adoc
@@ -0,0 +1,28 @@
+// Module included in the following assemblies:
+//
+// * virt/updating/upgrading-virt.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-changing-update-settings_{context}"]
+= Changing update settings
+
+You can change the update channel and approval strategy for your {VirtProductName} Operator subscription by using the web console.
+
+.Prerequisites
+
+* You have installed the {VirtProductName} Operator.
+* You have administrator permissions.
+
+.Procedure
+
+. Click *Operators* -> *Installed Operators*.
+
+. Select *{VirtProductName}* from the list.
+
+. Click the *Subscription* tab. 
+
+. In the *Subscription details* section, click the setting that you want to change. For example, to change the approval strategy from *Manual* to *Automatic*, click *Manual*.
+
+. In the window that opens, select the new update channel or approval strategy.
+
+. Click *Save*.
diff --git a/modules/virt-checking-storage-configuration.adoc b/modules/virt-checking-storage-configuration.adoc
index de347104e53a..ffc646f939d4 100644
--- a/modules/virt-checking-storage-configuration.adoc
+++ b/modules/virt-checking-storage-configuration.adoc
@@ -167,11 +167,11 @@ data:
   status.failureReason: "" # <2>
   status.startTimestamp: "2023-07-31T13:14:38Z" # <3>
   status.completionTimestamp: "2023-07-31T13:19:41Z" # <4>
-  status.result.cnvVersion: 4.17.2 # <5>
+  status.result.cnvVersion: 4.18.2 # <5>
   status.result.defaultStorageClass: trident-nfs <6>
   status.result.goldenImagesNoDataSource: <data_import_cron_list> # <7>
   status.result.goldenImagesNotUpToDate: <data_import_cron_list> # <8>
-  status.result.ocpVersion: 4.17.0 # <9>
+  status.result.ocpVersion: 4.18.0 # <9>
   status.result.pvcBound: "true" # <10>
   status.result.storageProfileMissingVolumeSnapshotClass: <storage_class_list> # <11>
   status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list> # <12>
diff --git a/modules/virt-common-instancetypes.adoc b/modules/virt-common-instancetypes.adoc
index 93976e6b595b..93f6f61f2636 100644
--- a/modules/virt-common-instancetypes.adoc
+++ b/modules/virt-common-instancetypes.adoc
@@ -16,14 +16,17 @@ These instance type resources are named according to their series, version, and
 |===
 ^.^|Use case ^.^|Series ^.^|Characteristics ^.^|vCPU to memory ratio ^.^|Example resource
 
-^.^|Universal
-^.^|U
+^.^|Network
+^.^|N
 a|
-* Burstable CPU performance
-^.^|1:4
-.^a|`u1.medium`::
-* 1 vCPUs
-* 4 Gi memory
+* Hugepages
+* Dedicated CPU
+* Isolated emulator threads
+* Requires nodes capable of running DPDK workloads
+^.^|1:2
+.^a|`n1.medium`::
+* 4 vCPUs
+* 4GiB Memory
 
 ^.^|Overcommitted
 ^.^|O
@@ -33,9 +36,9 @@ a|
 ^.^|1:4
 .^a|`o1.small`::
 * 1 vCPU
-* 2Gi memory
+* 2GiB Memory
 
-^.^|Compute-exclusive
+^.^|Compute Exclusive
 ^.^|CX
 a|
 * Hugepages
@@ -45,20 +48,18 @@ a|
 ^.^|1:2
 .^a|`cx1.2xlarge`::
 * 8 vCPUs
-* 16Gi memory
+* 16GiB Memory
 
-^.^|NVIDIA GPU
-^.^|GN
+^.^|General Purpose
+^.^|U
 a|
-* For VMs that use GPUs provided by the NVIDIA GPU Operator
-* Has predefined GPUs
 * Burstable CPU performance
 ^.^|1:4
-.^a|`gn1.8xlarge`::
-* 32 vCPUs
-* 128Gi memory
+.^a|`u1.medium`::
+* 1 vCPU
+* 4GiB Memory
 
-^.^|Memory-intensive
+^.^|Memory Intensive
 ^.^|M
 a|
 * Hugepages
@@ -66,17 +67,5 @@ a|
 ^.^|1:8
 .^a|`m1.large`::
 * 2 vCPUs
-* 16Gi memory
-
-^.^|Network-intensive
-^.^|N
-a|
-* Hugepages
-* Dedicated CPU
-* Isolated emulator threads
-* Requires nodes capable of running DPDK workloads
-^.^|1:2
-.^a|`n1.medium`::
-* 4 vCPUs
-* 4Gi memory
+* 16GiB Memory
 |===
\ No newline at end of file
diff --git a/modules/virt-configuring-a-live-migration-policy.adoc b/modules/virt-configuring-a-live-migration-policy.adoc
index d6d02492c12f..cd255cdef884 100644
--- a/modules/virt-configuring-a-live-migration-policy.adoc
+++ b/modules/virt-configuring-a-live-migration-policy.adoc
@@ -78,5 +78,5 @@ spec:
 +
 [source,terminal]
 ----
-$ oc create migrationpolicy -f <migration_policy>.yaml
-----
\ No newline at end of file
+$ oc create -f <migration_policy>.yaml
+----
diff --git a/modules/virt-configuring-default-and-virt-default-storage-class.adoc b/modules/virt-configuring-default-and-virt-default-storage-class.adoc
new file mode 100644
index 000000000000..fd86c44bc176
--- /dev/null
+++ b/modules/virt-configuring-default-and-virt-default-storage-class.adoc
@@ -0,0 +1,63 @@
+// Module included in the following assembly:
+//
+// * virt/storage/virt-automatic-bootsource-updates.adoc
+//
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-configuring-default-and-virt-default-storage-class_{context}"]
+= Configuring the default and virt-default storage classes
+
+A storage class determines how persistent storage is provisioned for workloads. In {VirtProductName}, the virt-default storage class takes precedence over the cluster default storage class and is used specifically for virtualization workloads. Only one storage class should be set as virt-default or cluster default at a time. If multiple storage classes are marked as default, the virt-default storage class overrides the cluster default. To ensure consistent behavior, configure only one storage class as the default for virtualization workloads.
+
+[IMPORTANT]
+====
+Boot sources are created using the default storage class. When the default storage class changes, old boot sources are automatically updated using the new default storage class. If your cluster does not have a default storage class, you must define one.
+
+If boot source images were stored as volume snapshots and both the cluster default and virt-default storage class have been unset, the volume snapshots are cleaned up and new data volumes will be created. However the newly created data volumes will not start importing until a default storage class is set.
+====
+
+.Procedure
+
+. Patch the current virt-default or a cluster default storage class to false:
+.. Identify all storage classes currently marked as virt-default by running the following command:
++
+[source,terminal]
+----
+$ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubevirt.io/is-default-virt-class"=="true")|.name'
+----
++
+.. For each storage class returned, remove the virt-default annotation by running the following command:
++
+[source,terminal]
+----
+$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "false"}}}'
+----
++
+.. Identify all storage classes currently marked as cluster default by running the following command:
++
+[source,terminal]
+----
+$ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubernetes.io/is-default-class"=="true")|.name'
+----
++
+.. For each storage class returned, remove the cluster default annotation by running the following command:
++
+[source,terminal]
+----
+$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
+----
+
+. Set a new default storage class:
+.. Assign the virt-default role to a storage class by running the following command:
++
+[source,terminal]
+----
+$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
+----
++
+.. Alternatively, assign the cluster default role to a storage class by running the following command:
++
+[source,terminal]
+----
+$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
+----
\ No newline at end of file
diff --git a/modules/virt-configuring-disk-sharing-lun.adoc b/modules/virt-configuring-disk-sharing-lun.adoc
index d317b8bc3347..cff84b27766b 100644
--- a/modules/virt-configuring-disk-sharing-lun.adoc
+++ b/modules/virt-configuring-disk-sharing-lun.adoc
@@ -19,6 +19,11 @@ You can set an error policy for each LUN disk. The error policy controls how the
 
 For a LUN disk with an SCSi connection and a persistent reservation, as required for Windows Failover Clustering for shared volumes, you set the error policy to `report`.
 
+[IMPORTANT]
+====
+{VirtProductName} does not currently support SCSI-3 Persistent Reservations (SCSI-3 PR) over multipath storage. As a workaround, disable multipath or ensure the Windows Server Failover Clustering (WSFC) shared disk is setup from a single device and not part of multipath.
+====
+
 .Prerequisites
 
 * You must have cluster administrator privileges to configure the feature gate option.
diff --git a/modules/virt-configuring-downward-metrics.adoc b/modules/virt-configuring-downward-metrics.adoc
index 797ba6eebb8a..f988d08a3964 100644
--- a/modules/virt-configuring-downward-metrics.adoc
+++ b/modules/virt-configuring-downward-metrics.adoc
@@ -40,7 +40,7 @@ spec:
     name: u1.medium
   preference:
     name: fedora
-  running: true
+  runStrategy: Always
   template:
     metadata:
       labels:
diff --git a/modules/virt-configuring-runstrategy-vm.adoc b/modules/virt-configuring-runstrategy-vm.adoc
index e56d84c4703d..c585c95950c1 100644
--- a/modules/virt-configuring-runstrategy-vm.adoc
+++ b/modules/virt-configuring-runstrategy-vm.adoc
@@ -8,11 +8,6 @@
 
 You can configure a run strategy for a virtual machine (VM) by using the command line.
 
-[IMPORTANT]
-====
-The `spec.runStrategy` and `spec.running` keys are mutually exclusive. A VM configuration that contains values for both keys is invalid.
-====
-
 .Procedure
 
 * Edit the `VirtualMachine` resource by running the following command:
diff --git a/modules/virt-configuring-secondary-network-vm-live-migration.adoc b/modules/virt-configuring-secondary-network-vm-live-migration.adoc
index 637981c1f7cb..499861c03a56 100644
--- a/modules/virt-configuring-secondary-network-vm-live-migration.adoc
+++ b/modules/virt-configuring-secondary-network-vm-live-migration.adoc
@@ -50,18 +50,19 @@ spec:
 +
 [source,terminal,subs="attributes+"]
 ----
-oc edit hyperconverged kubevirt-hyperconverged -n {CNVNamespace}
+$ oc edit hyperconverged kubevirt-hyperconverged -n {CNVNamespace}
 ----
 
 . Add the name of the `NetworkAttachmentDefinition` object to the `spec.liveMigrationConfig` stanza of the `HyperConverged` CR:
 +
 .Example `HyperConverged` manifest
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: hco.kubevirt.io/v1beta1
 kind: HyperConverged
 metadata:
   name: kubevirt-hyperconverged
+  namespace: {CNVNamespace}
 spec:
   liveMigrationConfig:
     completionTimeoutPerGiB: 800
diff --git a/modules/virt-configuring-storage-class-bootsource-update.adoc b/modules/virt-configuring-storage-class-bootsource-update.adoc
index 68538de80283..149f8cb39a88 100644
--- a/modules/virt-configuring-storage-class-bootsource-update.adoc
+++ b/modules/virt-configuring-storage-class-bootsource-update.adoc
@@ -5,13 +5,13 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-configuring-storage-class-bootsource-update_{context}"]
-= Configuring a storage class for custom boot source updates
+= Configuring a storage class for boot source images
 
-You can override the default storage class by editing the `HyperConverged` custom resource (CR).
+You can configure a specific storage class in the `HyperConverged` resource.
 
 [IMPORTANT]
 ====
-Boot sources are created from storage using the default storage class. If your cluster does not have a default storage class, you must define one before configuring automatic updates for custom boot sources.
+To ensure stable behavior and avoid unnecessary re-importing, you can specify the `storageClassName` in the `dataImportCronTemplates` section of the `HyperConverged` resource.
 ====
 
 .Procedure
@@ -23,7 +23,7 @@ Boot sources are created from storage using the default storage class. If your c
 $ oc edit hyperconverged kubevirt-hyperconverged -n {CNVNamespace}
 ----
 
-. Define a new storage class by entering a value in the `storageClassName` field:
+. Add the `dataImportCronTemplate` to the spec section of the `HyperConverged` resource and set the `storageClassName`:
 +
 [source,yaml]
 ----
@@ -34,11 +34,12 @@ metadata:
 spec:
   dataImportCronTemplates:
   - metadata:
-      name: rhel8-image-cron
+      name: rhel9-image-cron
     spec:
       template:
         spec:
-          storageClassName: <new_storage_class> <1>
+          storage:
+            storageClassName: <storage_class> <1>
       schedule: "0 */12 * * *" <2>
       managedDataSource: <data_source> <3>
 # ...
@@ -54,36 +55,18 @@ For the custom image to be detected as an available boot source, the value of th
 ----
 --
 
-. Remove the `storageclass.kubernetes.io/is-default-class` annotation from the current default storage class.
-.. Retrieve the name of the current default storage class by running the following command:
-+
-[source,terminal]
-----
-$ oc get storageclass
-----
-+
-.Example output
-[source,text]
-----
-NAME                          PROVISIONER                      RECLAIMPOLICY  VOLUMEBINDINGMODE    ALLOWVOLUMEEXPANSION  AGE
-csi-manila-ceph               manila.csi.openstack.org         Delete         Immediate            false                 11d
-hostpath-csi-basic (default)  kubevirt.io.hostpath-provisioner Delete         WaitForFirstConsumer false                 11d <1>
-----
-+
-<1> In this example, the current default storage class is named `hostpath-csi-basic`.
+. Wait for the HyperConverged Operator (HCO) and Scheduling, Scale, and Performance (SSP) resources to complete reconciliation.
 
-.. Remove the annotation from the current default storage class by running the following command:
+. Delete any outdated `DataVolume` and `VolumeSnapshot` objects from the `openshift-virtualization-os-images` namespace by running the following command.
 +
 [source,terminal]
 ----
-$ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' <1>
+$ oc delete DataVolume,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
 ----
-<1> Replace `<current_default_storage_class>` with the `storageClassName` value of the default storage class.
 
-. Set the new storage class as the default by running the following command:
+. Wait for all `DataSource` objects to reach a "Ready - True" status. Data sources can reference either a PersistentVolumeClaim (PVC) or a VolumeSnapshot. To check the expected source format, run the following command:
 +
 [source,terminal]
 ----
-$ oc patch storageclass <new_storage_class> -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' <1>
-----
-<1> Replace `<new_storage_class>` with the `storageClassName` value that you added to the `HyperConverged` CR.
+$ oc get storageprofile <storage_class_name> -o json | jq .status.dataImportCronSourceFormat
+----
\ No newline at end of file
diff --git a/modules/virt-configuring-vm-real-time.adoc b/modules/virt-configuring-vm-real-time.adoc
index 3dd0f52f30d7..a3483d04413f 100644
--- a/modules/virt-configuring-vm-real-time.adoc
+++ b/modules/virt-configuring-vm-real-time.adoc
@@ -23,7 +23,7 @@ kind: VirtualMachine
 metadata:
   name: realtime-vm
 spec:
-  running: true
+  runStrategy: Always
   template:
     metadata:
       annotations:
diff --git a/modules/virt-connecting-vm-secondarynw-using-fqdn.adoc b/modules/virt-connecting-vm-secondarynw-using-fqdn.adoc
index 55ab60138cb5..be2b6ff6e8b4 100644
--- a/modules/virt-connecting-vm-secondarynw-using-fqdn.adoc
+++ b/modules/virt-connecting-vm-secondarynw-using-fqdn.adoc
@@ -40,7 +40,7 @@ metadata:
   name: example-vm
   namespace: example-namespace
 spec:
-  running: true
+  runStrategy: Always
   template:
     spec:
       domain:
diff --git a/modules/virt-connecting-vm-virtctl.adoc b/modules/virt-connecting-vm-virtctl.adoc
index 9cfdb7d957eb..b2b8d460df6a 100644
--- a/modules/virt-connecting-vm-virtctl.adoc
+++ b/modules/virt-connecting-vm-virtctl.adoc
@@ -41,6 +41,7 @@ $ virtctl console <vm_name>
 . Press `Ctrl+]` to end the console session.
 endif::[]
 ifdef::vnc-console[]
++
 [source,terminal]
 ----
 $ virtctl vnc <vm_name>
diff --git a/modules/virt-controlling-multiple-vms.adoc b/modules/virt-controlling-multiple-vms.adoc
new file mode 100644
index 000000000000..ce0dd64a0219
--- /dev/null
+++ b/modules/virt-controlling-multiple-vms.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * virt/managing_vms/virt-controlling-vm-states.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-controlling-multiple-vms-web_{context}"]
+= Controlling the state of multiple virtual machines
+
+You can start, stop, restart, pause, and unpause multiple virtual machines from the web console.
+
+.Procedure
+
+. Navigate to *Virtualization* -> *VirtualMachines* in the web console.
+. Optional: To limit the number of displayed virtual machines, select a relevant project from the *Projects* list.
+. Select a checkbox next to the virtual machines you want to work with. To select all virtual machines, click the checkbox in the *VirtualMachines* table header.
+. Click *Actions* and select the intended action from the menu.
diff --git a/modules/virt-creating-a-primary-cluster-udn.adoc b/modules/virt-creating-a-primary-cluster-udn.adoc
new file mode 100644
index 000000000000..f7babc51739b
--- /dev/null
+++ b/modules/virt-creating-a-primary-cluster-udn.adoc
@@ -0,0 +1,51 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc
+
+:_mod-docs-content-type: PROCEDURE                                
+[id="virt-creating-a-primary-cluster-udn_{context}"]                                  
+= Creating a primary cluster-scoped user-defined network by using the CLI
+
+You can connect multiple namespaces to the same primary user-defined network (UDN) to achieve native tenant isolation by using the CLI.
+
+.Prerequisites
+. You have access to the cluster as a user with `cluster-admin` privileges.
+. You have installed the OpenShift CLI (`oc`).
+
+.Procedure
+. Create a `ClusterUserDefinedNetwork` object to specify the custom network configuration:
++
+.Example `ClusterUserDefinedNetwork` manifest
+[source,yaml]
+----
+kind: ClusterUserDefinedNetwork
+metadata:
+  name: cudn-l2-net # <1>
+spec:
+  namespaceSelector: # <2>
+    matchExpressions: # <3>
+    - key: kubernetes.io/metadata.name
+      operator: In # <4>
+      values: ["red-namespace", "blue-namespace"]
+  network:
+    topology: Layer2 # <5>
+    layer2:
+      role: Primary # <6>
+      ipam:
+        lifecycle: Persistent
+      subnets:
+        - 203.203.0.0/16
+----
+<1> Specifies the name of the `ClusterUserDefinedNetwork` custom resource.
+<2> Specifies the set of namespaces that the cluster UDN applies to. The namespace selector must not point to `default`, an `openshift-*` namespace, or any global namespaces that are defined by the Cluster Network Operator (CNO).
+<3> Specifies the type of selector. In this example, the `matchExpressions` selector selects objects that have the label `kubernetes.io/metadata.name` with the value `red-namespace` or `blue-namespace`.
+<4> Specifies the type of operator. Possible values are `In`, `NotIn`, and `Exists`.
+<5> Specifies the topological configuration of the network. The required value is `Layer2`. A `Layer2` topology creates a logical switch that is shared by all nodes.
+<6> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
+
+. Apply the `ClusterUserDefinedNetwork` manifest by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f --validate=true <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/virt-creating-a-primary-udn.adoc b/modules/virt-creating-a-primary-udn.adoc
new file mode 100644
index 000000000000..fa33fe0a5582
--- /dev/null
+++ b/modules/virt-creating-a-primary-udn.adoc
@@ -0,0 +1,47 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc
+
+:_mod-docs-content-type: PROCEDURE                                
+[id="virt-creating-a-primary-udn_{context}"]                                  
+= Creating a primary namespace-scoped user-defined network by using the CLI
+
+You can create an isolated primary network in your project namespace by using the CLI. You must use the OVN-Kubernetes layer 2 topology and enable persistent IP address allocation in the user-defined network (UDN) configuration to ensure VM live migration support.
+
+.Prerequisites
+. You have installed the OpenShift CLI (`oc`).
+. You have created a namespace and applied the `k8s.ovn.org/primary-user-defined-network` label.
+
+.Procedure
+. Create a `UserDefinedNetwork` object to specify the custom network configuration:
++
+.Example `UserDefinedNetwork` manifest
+[source,yaml]
+----
+apiVersion: k8s.ovn.org/v1
+kind: UserDefinedNetwork
+metadata:
+  name: udn-l2-net # <1>
+  namespace: my-namespace # <2>
+spec:
+  topology: Layer2 # <3>
+  layer2: 
+    role: Primary # <4>
+    subnets:
+      - "10.0.0.0/24"
+      - "2001:db8::/60" 
+  ipam:
+    lifecycle: Persistent # <5>
+----
+<1> Specifies the name of the `UserDefinedNetwork` custom resource. 
+<2> Specifies the namespace in which the VM is located. The namespace must have the `k8s.ovn.org/primary-user-defined-network` label. The namespace must not be `default`, an `openshift-*` namespace, or match any global namespaces that are defined by the Cluster Network Operator (CNO).
+<3> Specifies the topological configuration of the network. The required value is `Layer2`. A `Layer2` topology creates a logical switch that is shared by all nodes.
+<4> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
+<5> Specifies that virtual workloads have consistent IP addresses across reboots and migration. The `spec.layer2.subnets` field is required when `ipam.lifecycle: Persistent` is specified.
+
+. Apply the `UserDefinedNetwork` manifest by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f --validate=true <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/virt-creating-hpp-basic-storage-pool.adoc b/modules/virt-creating-hpp-basic-storage-pool.adoc
index 3cbf9ffa66a6..e83de2ea24bc 100644
--- a/modules/virt-creating-hpp-basic-storage-pool.adoc
+++ b/modules/virt-creating-hpp-basic-storage-pool.adoc
@@ -33,9 +33,9 @@ spec:
   storagePools: <1>
   - name: any_name
     path: "/var/myvolumes" <2>
-workload:
-  nodeSelector:
-    kubernetes.io/os: linux
+  workload:
+    nodeSelector:
+      kubernetes.io/os: linux
 ----
 <1> The `storagePools` stanza is an array to which you can add multiple entries.
 <2> Specify the storage pool directories under this node path.
diff --git a/modules/virt-creating-infiniband-interface-on-nodes.adoc b/modules/virt-creating-infiniband-interface-on-nodes.adoc
new file mode 100644
index 000000000000..cff1a20d0b2c
--- /dev/null
+++ b/modules/virt-creating-infiniband-interface-on-nodes.adoc
@@ -0,0 +1,64 @@
+// Module included in the following assemblies:
+//
+// * networking/k8s_nmstate/k8s-observing-node-network-state.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-creating-infiniband-interface-on-nodes_{context}"]
+= Creating an IP over InfiniBand interface on nodes
+
+On the {product-title} web console, you can install a Red{nbsp}Hat certified third-party Operator, such as the NVIDIA Network Operator, that supports InfiniBand (IPoIB) mode. Typically, you would use the third-party Operator with other vendor infrastructure to manage resources in an {product-title} cluster. To create an IPoIB interface on nodes in your cluster, you must define an InfiniBand (IPoIB) interface in a `NodeNetworkConfigurationPolicy` (NNCP) manifest file. 
+
+[IMPORTANT]
+====
+The {product-title} documentation describes defining only the IPoIB interface configuration in a `NodeNetworkConfigurationPolicy` (NNCP) manifest file. You must refer to the NVIDIA and other third-party vendor documentation for the majority of the configuring steps. Red{nbsp}Hat support does not extend to anything external to the NNCP configuration. 
+
+For more information about the NVIDIA Operator, see link:https://docs.nvidia.com/networking/display/kubernetes2410/getting+started+with+red+hat+openshift[Getting Started with Red{nbsp}Hat OpenShift] (NVIDIA Docs Hub).
+====
+
+.Prerequisites
+
+* You installed a Red{nbsp}Hat certified third-party Operator that supports an IPoIB interface.
+
+
+.Procedure
+
+. Create or edit a `NodeNetworkConfigurationPolicy` (NNCP) manifest file, and then specify an IPoIB interface in the file.
++
+
+[source,yaml]
+----
+apiVersion: nmstate.io/v1
+kind: NodeNetworkConfigurationPolicy
+metadata:
+  name: worker-0-ipoib
+spec:
+# ...
+    interfaces:
+    - description: ""
+      infiniband:
+        mode: datagram <1>
+        pkey: "0xffff" <2>
+      ipv4:
+        address:
+        - ip: 100.125.3.4
+          prefix-length: 16
+        dhcp: false
+        enabled: true
+      ipv6:
+        enabled: false
+      name: ibp27s0
+      state: up
+      type: infiniband <3>
+# ...
+----
+<1> `datagram` is the default mode for an IPoIB interface, and this mode improves optimizes performance and latency. `connected` mode is a supported mode but consider only using this mode when you need to adjust the maximum transmission unit (MTU) value to improve node connectivity with surrounding network devices.  
+<2> Supports a string or an integer value. The parameter defines the protection key, or _P-key_, for the interface for the purposes of authentication and encrypted communications with a third-party vendor, such as NVIDIA. Values `None` and `0xffff` indicate the protection key for the base interface in an InfiniBand system.
+<3> Sets the type of interface to `infiniband `.
+
+. Apply the NNCP configuration to each node in your cluster by running the following command. The Kubernetes NMState Operator can then create an IPoIB interface on each node. 
++
+[source,yaml]
+----
+$ oc apply -f <nncp_file_name> <1>
+----
+<1> Replace `<nncp_file_name>` with the name of your NNCP file.
diff --git a/modules/virt-creating-new-vm-from-cloned-pvc-using-datavolumetemplate.adoc b/modules/virt-creating-new-vm-from-cloned-pvc-using-datavolumetemplate.adoc
index b1d2cad5a1d7..0de6292020c1 100644
--- a/modules/virt-creating-new-vm-from-cloned-pvc-using-datavolumetemplate.adoc
+++ b/modules/virt-creating-new-vm-from-cloned-pvc-using-datavolumetemplate.adoc
@@ -47,7 +47,7 @@ metadata:
     kubevirt.io/vm: vm-dv-clone
   name: vm-dv-clone <1>
 spec:
-  running: false
+  runStrategy: Halted
   template:
     metadata:
       labels:
diff --git a/modules/virt-creating-primary-cluster-udn-web.adoc b/modules/virt-creating-primary-cluster-udn-web.adoc
new file mode 100644
index 000000000000..2709a0cf5da3
--- /dev/null
+++ b/modules/virt-creating-primary-cluster-udn-web.adoc
@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc              
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-creating-primary-cluster-udn-web_{context}"]
+= Creating a primary cluster-scoped user-defined network by using the web console
+
+You can connect multiple namespaces to the same primary user-defined network (UDN) by creating a `ClusterUserDefinedNetwork` custom resource in the {product-title} web console.
+
+.Prerequisites
+* You have access to the {product-title} web console as a user with `cluster-admin` permissions.
+
+.Procedure
+. From the *Administrator* perspective, click *Networking* -> *UserDefinedNetworks*.
+
+. From the *Create* list, select *ClusterUserDefinedNetwork*.
+
+. In the *Name* field, specify a name for the cluster-scoped UDN.
+
+. Specify a value in the *Subnet* field.
+
+. In the *Project(s) Match Labels* field, add the appropriate labels to select namespaces that the cluster UDN applies to.
+
+. Click *Create*. The cluster-scoped UDN serves as the default primary network for pods and virtual machines located in namespaces that contain the labels that you specified in step 5.
\ No newline at end of file
diff --git a/modules/virt-creating-primary-udn-web.adoc b/modules/virt-creating-primary-udn-web.adoc
new file mode 100644
index 000000000000..195ca9e2be00
--- /dev/null
+++ b/modules/virt-creating-primary-udn-web.adoc
@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc              
+
+:_mod-docs-content-type: PROCEDURE                                    
+[id="virt-creating-primary-udn-web_{context}"]                                   
+= Creating a primary namespace-scoped user-defined network by using the web console
+
+You can create an isolated primary network in your project namespace by creating a `UserDefinedNetwork` custom resource in the {product-title} web console.
+
+.Prerequisites
+* You have access to the {product-title} web console as a user with `cluster-admin` permissions.
+* You have created a namespace and applied the `k8s.ovn.org/primary-user-defined-network` label. For more information, see "Creating a namespace for user-defined networks by using the web console".
+
+.Procedure
+. From the *Administrator* perspective, click *Networking* -> *UserDefinedNetworks*.
+
+. Click *Create UserDefinedNetwork*.
+
+. From the *Project name* list, select the namespace that you previously created.
+
+. Specify a value in the *Subnet* field.
+
+. Click *Create*. The user-defined network serves as the default primary network for pods and virtual machines that you create in this namespace.
\ No newline at end of file
diff --git a/modules/virt-creating-rbac-cloning-dvs.adoc b/modules/virt-creating-rbac-cloning-dvs.adoc
index b879c62a30d1..ff5c7d1cedbe 100644
--- a/modules/virt-creating-rbac-cloning-dvs.adoc
+++ b/modules/virt-creating-rbac-cloning-dvs.adoc
@@ -12,6 +12,11 @@ Create a new cluster role that enables permissions for all actions for the `data
 
 * You must have cluster admin privileges.
 
+[NOTE]
+====
+If you are a non-admin user that is an administrator for both the source and target namespaces, you can create a `Role` instead of a `ClusterRole` where appropriate.
+====
+
 .Procedure
 
 . Create a `ClusterRole` manifest:
diff --git a/modules/virt-creating-service-cli.adoc b/modules/virt-creating-service-cli.adoc
index 126fc7b17ef3..847714d437c2 100644
--- a/modules/virt-creating-service-cli.adoc
+++ b/modules/virt-creating-service-cli.adoc
@@ -25,7 +25,7 @@ metadata:
   name: example-vm
   namespace: example-namespace
 spec:
-  running: false
+  runStrategy: Halted
   template:
     metadata:
       labels:
diff --git a/modules/virt-creating-udn-namespace-cli.adoc b/modules/virt-creating-udn-namespace-cli.adoc
new file mode 100644
index 000000000000..3bb34308cc8f
--- /dev/null
+++ b/modules/virt-creating-udn-namespace-cli.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc              
+
+:_mod-docs-content-type: PROCEDURE                                    
+[id="virt-creating-udn-namespace-cli_{context}"]                                   
+= Creating a namespace for user-defined networks by using the CLI
+
+You can create a namespace to be used with primary user-defined networks (UDNs) by using the CLI.
+
+.Prerequisites
+* You have access to the cluster as a user with `cluster-admin` permissions.
+* You have installed the OpenShift CLI (`oc`).
+
+
+.Procedure
+. Create a `Namespace` object as a YAML file similar to the following example:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: udn_namespace
+  labels:
+    k8s.ovn.org/primary-user-defined-network: "" # <1>
+# ...
+----
+<1> This label is required for the namespace to be associated with a UDN. If the namespace is to be used with an existing cluster UDN, you must also add the appropriate labels that are defined in the `spec.namespaceSelector` field of the `ClusterUserDefinedNetwork` custom resource.
+
+. Apply the `Namespace` manifest by running the following command:
++
+[source, terminal]
+----
+oc apply -f <filename>.yaml
+----
\ No newline at end of file
diff --git a/modules/virt-creating-udn-namespace-web.adoc b/modules/virt-creating-udn-namespace-web.adoc
new file mode 100644
index 000000000000..604d8be87ee9
--- /dev/null
+++ b/modules/virt-creating-udn-namespace-web.adoc
@@ -0,0 +1,28 @@
+// Module included in the following assemblies:
+//
+// * virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc              
+
+:_mod-docs-content-type: PROCEDURE                                    
+[id="virt-creating-udn-namespace-web_{context}"]                                   
+= Creating a namespace for user-defined networks by using the web console
+
+You can create a namespace to be used with primary user-defined networks (UDNs) by using the {product-title} web console.
+
+.Prerequisites
+* Log in to the {product-title} web console as a user with `cluster-admin` permissions.
+
+
+.Procedure
+. From the *Administrator* perspective, click *Administration* -> *Namespaces*.
+
+. Click *Create Namespace*.
+
+. In the *Name* field, specify a name for the namespace. The name must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character.
+
+. In the *Labels* field, add the `k8s.ovn.org/primary-user-defined-network` label.
+
+. Optional: If the namespace is to be used with an existing cluster-scoped UDN, add the appropriate labels as defined in the `spec.namespaceSelector` field in the `ClusterUserDefinedNetwork` custom resource.
+
+. Optional: Specify a default network policy.
+
+. Click *Create* to create the namespace.
\ No newline at end of file
diff --git a/modules/virt-creating-vm-cli.adoc b/modules/virt-creating-vm-cli.adoc
index c69f8b212d4b..de67ef21bd30 100644
--- a/modules/virt-creating-vm-cli.adoc
+++ b/modules/virt-creating-vm-cli.adoc
@@ -38,7 +38,7 @@ This example manifest does not configure VM authentication.
     name: u1.medium <3>
   preference:
     name: rhel.9 <4>
-  running: true
+  runStrategy: Always
   template:
     spec:
       domain:
diff --git a/modules/virt-creating-vm-cloned-pvc-data-volume-template.adoc b/modules/virt-creating-vm-cloned-pvc-data-volume-template.adoc
index cb47006fee68..a7f323abdd28 100644
--- a/modules/virt-creating-vm-cloned-pvc-data-volume-template.adoc
+++ b/modules/virt-creating-vm-cloned-pvc-data-volume-template.adoc
@@ -27,7 +27,7 @@ metadata:
     kubevirt.io/vm: vm-dv-clone
   name: vm-dv-clone <1>
 spec:
-  running: false
+  runStrategy: Halted
   template:
     metadata:
       labels:
diff --git a/modules/virt-creating-vm-from-template.adoc b/modules/virt-creating-vm-from-template.adoc
index f46546ae4d8e..fcf461f90117 100644
--- a/modules/virt-creating-vm-from-template.adoc
+++ b/modules/virt-creating-vm-from-template.adoc
@@ -6,30 +6,33 @@
 [id="virt-creating-vm-from-template_{context}"]
 = Creating a VM from a template
 
-You can create a virtual machine (VM) from a template with an available boot source by using the {product-title} web console.
+You can create a virtual machine (VM) from a template with an available boot source by using the {product-title} web console. You can customize template or VM parameters, such as data sources, Cloud-init, or SSH keys, before you start the VM.
 
-Optional: You can customize template or VM parameters, such as data sources, cloud-init, or SSH keys, before you start the VM.
+You can choose between two views in the web console to create the VM:
+
+* A virtualization-focused view, which provides a concise list of virtualization-related options at the top of the view
+* A general view, which provides access to the various web console options, including *Virtualization*
 
 .Procedure
 
-. Navigate to *Virtualization* -> *Catalog* in the web console.
-. Click *Boot source available* to filter templates with boot sources.
+. From the {product-title} web console, choose your view:
+** For a virtualization-focused view, select *Administrator* -> *Virtualization* -> *Catalog*.
 +
-The catalog displays the default templates. Click *All Items* to view all available templates for your filters.
-
+** For a general view, navigate to *Virtualization* -> *Catalog*.
+. Click the *Template catalog* tab.
+. Click the *Boot source available* checkbox to filter templates with boot sources. The catalog displays the default templates.
+. Click *All templates* to view the available templates for your filters.
+** To focus on particular templates, enter the keyword in the `Filter by keyword` field.
+** Choose a template project from the *All projects* dropdown menu, or view all projects.
 . Click a template tile to view its details.
-. Optional: If you are using a Windows template, you can mount a Windows driver disk by selecting the *Mount Windows drivers disk* checkbox.
-. If you do not need to customize the template or VM parameters, click *Quick create VirtualMachine* to create a VM from the template.
-+
-If you need to customize the template or VM parameters, do the following:
-
-.. Click *Customize VirtualMachine*.
-.. Expand *Storage* or *Optional parameters* to edit data source settings.
-.. Click *Customize VirtualMachine parameters*.
+** Optional: If you are using a Windows template, you can mount a Windows driver disk by selecting the *Mount Windows drivers disk* checkbox.
+** If you do not need to customize the template or VM parameters, click *Quick create VirtualMachine* to create a VM from the template.
 +
-The *Customize and create VirtualMachine* pane displays the *Overview*, *YAML*, *Scheduling*, *Environment*, *Network interfaces*, *Disks*, *Scripts*, and *Metadata* tabs.
+** If you need to customize the template or VM parameters, do the following:
 
-.. Edit the parameters that must be set before the VM boots, such as cloud-init or a static SSH key.
+.. Click *Customize VirtualMachine*. The *Customize and create VirtualMachine* page displays the *Overview*, *YAML*, *Scheduling*, *Environment*, *Network interfaces*, *Disks*, *Scripts*, and *Metadata* tabs.
+.. Click the *Scripts* tab to edit the parameters that must be set before the VM boots, such as `Cloud-init`, `SSH key`, or `Sysprep` (Windows VM only).
+.. Optional: Click the *Start this virtualmachine after creation (Always)* checkbox.
 .. Click *Create VirtualMachine*.
 +
 The *VirtualMachine details* page displays the provisioning status.
diff --git a/modules/virt-creating-vm-snapshot-cli.adoc b/modules/virt-creating-vm-snapshot-cli.adoc
index 35c7ad6f87eb..140be2483701 100644
--- a/modules/virt-creating-vm-snapshot-cli.adoc
+++ b/modules/virt-creating-vm-snapshot-cli.adoc
@@ -10,7 +10,27 @@ You can create a virtual machine (VM) snapshot for an offline or online VM by cr
 
 .Prerequisites
 
-* Ensure that the persistent volume claims (PVCs) are in a storage class that supports Container Storage Interface (CSI) volume snapshots.
+* Ensure the `Snapshot` feature gate is enabled for the `kubevirt` CR by using the following command:
++
+[source,terminal,subs="attributes+"]
+----
+$ oc get kubevirt kubevirt-hyperconverged -n {CNVNamespace} -o yaml
+----
++
+.Truncated output
+[source,yaml]
+----
+spec:
+  developerConfiguration:
+    featureGates:
+      - Snapshot
+----
+
+* Ensure that the VM snapshot includes disks that meet the following requirements:
+** The disks are data volumes or persistent volume claims.
+** The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots.
+** The disks are _bound_ to a persistent volume (PV) and _populated_ with a datasource. 
+
 * Install the OpenShift CLI (`oc`).
 * Optional: Power down the VM for which you want to create a snapshot.
 
@@ -40,7 +60,9 @@ $ oc create -f <snapshot_name>.yaml
 +
 The snapshot controller creates a `VirtualMachineSnapshotContent` object, binds it to the `VirtualMachineSnapshot`, and updates the `status` and `readyToUse` fields of the `VirtualMachineSnapshot` object.
 
-. Optional: If you are taking an online snapshot, you can use the `wait` command and monitor the status of the snapshot:
+.Verification
+
+. Optional: During the snapshot creation process, you can use the `wait` command to monitor the status of the snapshot and wait until it is ready for use:
 .. Enter the following command:
 +
 [source,terminal]
@@ -49,9 +71,9 @@ $ oc wait <vm_name> <snapshot_name> --for condition=Ready
 ----
 
 .. Verify the status of the snapshot:
-* `InProgress` - The online snapshot operation is still in progress.
-* `Succeeded` - The online snapshot operation completed successfully.
-* `Failed` - The online snapshot operaton failed.
+* `InProgress` - The snapshot operation is still in progress.
+* `Succeeded` - The snapshot operation completed successfully.
+* `Failed` - The snapshot operaton failed.
 +
 [NOTE]
 ====
@@ -64,8 +86,6 @@ To set no deadline, you can specify `0`, though this is generally not recommende
 If you do not specify a unit of time such as `m` or `s`, the default is seconds (`s`).
 ====
 
-.Verification
-
 . Verify that the `VirtualMachineSnapshot` object is created and bound with `VirtualMachineSnapshotContent` and that the `readyToUse` flag is set to `true`:
 +
 [source,terminal]
@@ -109,10 +129,21 @@ status:
   readyToUse: true <3>
   sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f
   virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d <4>
+  indications: <5>
+    - Online
+  includedVolumes: <6>
+    - name: rootdisk
+      kind: PersistentVolumeClaim
+      namespace: default
+    - name: datadisk1
+      kind: DataVolume
+      namespace: default
 ----
 <1> The `status` field of the `Progressing` condition specifies if the snapshot is still being created.
 <2> The `status` field of the `Ready` condition specifies if the snapshot creation process is complete.
 <3> Specifies if the snapshot is ready to be used.
 <4> Specifies that the snapshot is bound to a `VirtualMachineSnapshotContent` object created by the snapshot controller.
+<5> Specifies additional information about the snapshot, such as whether it is an online snapshot, or whether it was created with QEMU guest agent running.
+<6> Lists the storage volumes that are part of the snapshot, as well as their parameters.
 
-. Check the `spec:volumeBackups` property of the `VirtualMachineSnapshotContent` resource to verify that the expected PVCs are included in the snapshot.
\ No newline at end of file
+. Check the `includedVolumes` section in the snapshot description to verify that the expected PVCs are included in the snapshot.
\ No newline at end of file
diff --git a/modules/virt-creating-vm-snapshot-web.adoc b/modules/virt-creating-vm-snapshot-web.adoc
index 6541042eec97..cb9f7c5e86e3 100644
--- a/modules/virt-creating-vm-snapshot-web.adoc
+++ b/modules/virt-creating-vm-snapshot-web.adoc
@@ -8,10 +8,14 @@
 
 You can create a snapshot of a virtual machine (VM) by using the {product-title} web console.
 
-The VM snapshot includes disks that meet the following requirements:
+.Prerequisites
 
-* Either a data volume or a persistent volume claim
-* Belong to a storage class that supports Container Storage Interface (CSI) volume snapshots
+* The `snapshot` feature gate is enabled in the YAML configuration of the `kubevirt` CR.
+
+* The VM snapshot includes disks that meet the following requirements:
+** The disks are data volumes or persistent volume claims.
+** The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots.
+** The disks are _bound_ to a persistent volume (PV) and _populated_ with a datasource.
 
 .Procedure
 
diff --git a/modules/virt-creating-windows-vm.adoc b/modules/virt-creating-windows-vm.adoc
index c2ca844b76ed..245d3bfe692d 100644
--- a/modules/virt-creating-windows-vm.adoc
+++ b/modules/virt-creating-windows-vm.adoc
@@ -10,7 +10,7 @@ You can create a Windows virtual machine (VM) by uploading a Windows image to a
 
 .Prerequisites
 
-* You created a Windows installation DVD or USB with the Windows Media Creation Tool. See link:https://www.microsoft.com/en-us/software-download/windows10%20[Create Windows 10 installation media] in the Microsoft documentation.
+* You created a Windows installation DVD or USB with the Windows Media Creation Tool. See link:https://www.microsoft.com/en-us/software-download/windows10[Create Windows 10 installation media] in the Microsoft documentation.
 * You created an `autounattend.xml` answer file. See link:https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/update-windows-settings-and-scripts-create-your-own-answer-file-sxs[Answer files (unattend.xml)] in the Microsoft documentation.
 
 .Procedure
diff --git a/modules/virt-customizing-storage-profile.adoc b/modules/virt-customizing-storage-profile.adoc
index aa6a58d90911..e6796a9de5b8 100644
--- a/modules/virt-customizing-storage-profile.adoc
+++ b/modules/virt-customizing-storage-profile.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/storage/virt-customizing-storageprofiles.adoc
+// * virt/storage/virt-configuring-storage-profile.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-customizing-storage-profile_{context}"]
@@ -108,24 +108,3 @@ status:
 <1> Specify the access mode.
 <2> Specify the volume mode.
 <3> Specify the default cloning strategy.
-
-[id="virt-customizing-storage-profile-providers-and-default-behaviors_{context}"]
-.Storage providers and default behaviors
-
-[cols="1,1",options="header"]
-|===
-|Storage provider|Default behavior
-|rook-ceph.rbd.csi.ceph.com|Snapshot
-|openshift-storage.rbd.csi.ceph.com|Snapshot
-|csi-vxflexos.dellemc.com|CSI Clone
-|csi-isilon.dellemc.com|CSI Clone
-|csi-powermax.dellemc.com|CSI Clone
-|csi-powerstore.dellemc.com|CSI Clone
-|hspc.csi.hitachi.com|CSI Clone
-|csi.hpe.com|CSI Clone
-|spectrumscale.csi.ibm.com|CSI Clone
-|rook-ceph.rbd.csi.ceph.com|CSI Clone
-|openshift-storage.rbd.csi.ceph.com|CSI Clone
-|cephfs.csi.ceph.com|CSI Clone
-|openshift-storage.cephfs.csi.ceph.com|CSI Clone
-|===
\ No newline at end of file
diff --git a/modules/virt-customizing-vm-template-web.adoc b/modules/virt-customizing-vm-template-web.adoc
index 786a871b9159..9127ae7aab63 100644
--- a/modules/virt-customizing-vm-template-web.adoc
+++ b/modules/virt-customizing-vm-template-web.adoc
@@ -1,10 +1,10 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/creating_vm/virt-creating-vms-from-templates.adoc
+// * virt/creating_vm/virt-creating-vms-from-templates.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-customizing-vm-template-web_{context}"]
-= Customizing a VM template by using the web console
+= Removing a deprecated designation from a customized VM template by using the web console
 
 You can customize an existing virtual machine (VM) template by modifying the VM or template parameters, such as data sources, cloud-init, or SSH keys, before you start the VM. If you customize a template by copying it and including all of its labels and annotations, the customized template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed.
 
diff --git a/modules/virt-defining-apps-for-dr.adoc b/modules/virt-defining-apps-for-dr.adoc
index 2c52cf29eb24..65dd7449e9e8 100644
--- a/modules/virt-defining-apps-for-dr.adoc
+++ b/modules/virt-defining-apps-for-dr.adoc
@@ -33,14 +33,14 @@ Use the pod `pullMethod: node` when creating a data volume from a registry sourc
 [id="best-practices-{rh-rhacm}-discovered-vm_{context}"]
 == Best practices when defining an {rh-rhacm}-discovered VM
 
-You can configure any VM in the cluster that is not an {rh-rhacm}-managed application as an {rh-rhacm}-discovered application. This includes VMs imported by using the Migration Toolkit for Virtualization (MTV), VMs created by using the {VirtProductName} web console, or VMs created by any other means, such as the CLI.
+You can configure any VM in the cluster that is not an {rh-rhacm}-managed application as an {rh-rhacm}-discovered application. This includes VMs imported by using the Migration Toolkit for Virtualization (MTV), VMs created by using the {product-title} web console, or VMs created by any other means, such as the CLI.
 
 There are several actions you can take to improve your experience and chance of success when defining an {rh-rhacm}-discovered VM.
 
 [discrete]
 [id="protect-the-vm_{context}"]
-=== Protect the VM when using MTV, the {VirtProductName} web console, or a custom VM
-Because automatic labeling is not currently available, the application owner must manually label the components of the VM application when using MTV, the {VirtProductName} web console, or a custom VM.
+=== Protect the VM when using MTV, the {product-title} web console, or a custom VM
+Because automatic labeling is not currently available, the application owner must manually label the components of the VM application when using MTV, the {product-title} web console, or a custom VM.
 
 After creating the VM, apply a common label to the following resources associated with the VM: `VirtualMachine`, `DataVolume`, `PersistentVolumeClaim`, `Service`, `Route`, `Secret`, `ConfigMap`, `VirtualMachinePreference`, and `VirtualMachineInstancetype`. Do not label virtual machine instances (VMIs) or pods; {VirtProductName} creates and manages these automatically.
 
diff --git a/modules/virt-defining-watchdog-device-vm.adoc b/modules/virt-defining-watchdog-device-vm.adoc
index f2959f889ea7..cb6854361acb 100644
--- a/modules/virt-defining-watchdog-device-vm.adoc
+++ b/modules/virt-defining-watchdog-device-vm.adoc
@@ -25,7 +25,7 @@ metadata:
     kubevirt.io/vm: vm2-rhel84-watchdog
   name: <vm-name>
 spec:
-  running: false
+  runStrategy: Halted
   template:
     metadata:
       labels:
diff --git a/modules/virt-deploying-operator-cli.adoc b/modules/virt-deploying-operator-cli.adoc
index b8c23b9b7925..0dafdffebb48 100644
--- a/modules/virt-deploying-operator-cli.adoc
+++ b/modules/virt-deploying-operator-cli.adoc
@@ -13,9 +13,9 @@ You can deploy the {VirtProductName} Operator by using the `oc` CLI.
 * Subscribe to the {VirtProductName} catalog in the `{CNVNamespace}` namespace.
 * Log in as a user with `cluster-admin` privileges.
 // required for ROSA/OSD
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Create a machine pool based on a bare metal compute node instance type.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/virt-enabling-usb-host-passthrough.adoc b/modules/virt-enabling-usb-host-passthrough.adoc
index 232563047e28..8384a76681b3 100644
--- a/modules/virt-enabling-usb-host-passthrough.adoc
+++ b/modules/virt-enabling-usb-host-passthrough.adoc
@@ -34,7 +34,7 @@ $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
 
 +
 .Example YAML snippet
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: hco.kubevirt.io/v1beta1
 kind: HyperConverged
diff --git a/modules/virt-example-nmstate-IP-management.adoc b/modules/virt-example-nmstate-IP-management.adoc
index 669d545a026f..90a521dee3ea 100644
--- a/modules/virt-example-nmstate-IP-management.adoc
+++ b/modules/virt-example-nmstate-IP-management.adoc
@@ -51,6 +51,11 @@ The following snippet ensures that the interface has no IP address:
 # ...
 ----
 
+[IMPORTANT]
+====
+Always set the `state` parameter to `up` when you set both the `ipv4.enabled` and the `ipv6.enabled` parameter to `false` to disable an interface. If you set `state: down` with this configuration, the interface receives a DHCP IP address because of automatic DHCP assignment. 
+====
+
 [id="virt-example-nmstate-IP-management-dhcp_{context}"]
 == Dynamic host configuration
 
@@ -103,7 +108,7 @@ To define a DNS configuration for a network interface, you must initially specif
 
 [IMPORTANT]
 ====
-You cannot use `br-ex` bridge, an OVNKubernetes-managed Open vSwitch bridge, as the interface when configuring DNS resolvers unless you manually configured a customized `br-ex` bridge.
+You cannot use the `br-ex` bridge, an OVN-Kubernetes-managed Open vSwitch bridge, as the interface when configuring DNS resolvers unless you manually configured a customized `br-ex` bridge.
 
 For more information, see "Creating a manifest object that includes a customized br-ex bridge" in the _Deploying installer-provisioned clusters on bare metal_ document or the _Installing a user-provisioned cluster on bare metal_ document.
 ====
@@ -144,8 +149,7 @@ You can specify DNS options under the `dns-resolver.config` section of your NNCP
 desiredState:
     dns-resolver:
       config:
-        search:
-         options:
+        options:
          - timeout:2
          - attempts:3
 # ...
@@ -285,4 +289,11 @@ routes:
 # ...
 ----
 <1> The static IP address for the Ethernet interface.
-<2> Next hop address for the node traffic. This must be in the same subnet as the IP address set for the Ethernet interface.
+<2> The next hop address for the node traffic. This must be in the same subnet as the IP address set for the Ethernet interface.
+
+[IMPORTANT]
+====
+You cannot use the OVN-Kubernetes `br-ex` bridge as the next hop interface when configuring a static route unless you manually configured a customized `br-ex` bridge.
+
+For more information, see "Creating a manifest object that includes a customized br-ex bridge" in the _Deploying installer-provisioned clusters on bare metal_ document or the _Installing a user-provisioned cluster on bare metal_ document.
+====
diff --git a/modules/virt-expanding-vm-disk-pvc.adoc b/modules/virt-expanding-vm-disk-pvc.adoc
index 0f918d052bda..58f364cebf3d 100644
--- a/modules/virt-expanding-vm-disk-pvc.adoc
+++ b/modules/virt-expanding-vm-disk-pvc.adoc
@@ -4,11 +4,38 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-expanding-vm-disk-pvc_{context}"]
-= Expanding a VM disk PVC
+= Increasing a VM disk size by expanding the PVC of the disk
 
-You can increase the size of a virtual machine (VM) disk by expanding the persistent volume claim (PVC) of the disk.
+You can increase the size of a virtual machine (VM) disk by expanding the persistent volume claim (PVC) of the disk. To specify the increased PVC volume, you can use the web console with the VM running. Alternatively, you can edit the PVC manifest in the CLI.
 
+[NOTE]
+====
 If the PVC uses the file system volume mode, the disk image file expands to the available size while reserving some space for file system overhead.
+====
+
+[id="virt-expanding-vm-disk-pvc-web-console_{context}"]
+== Expanding a VM disk PVC in the web console
+
+You can increase the size of a VM disk PVC in the web console without leaving the *VirtualMachines* page and with the VM running.
+
+.Procedure
+
+. In the *Administrator* or *Virtualization* perspective, open the *VirtualMachines* page.
+. Select the running VM to open its *Details* page.
+. Select the *Configuration* tab and click *Storage*.
+. Click the options menu {kebab} next to the disk you want to expand. Select the *Edit* option.
++
+The *Edit disk* dialog opens.
+. In the *PersistentVolumeClaim size* field, enter the desired size.
+. Click *Save*.
+
+[NOTE]
+====
+You can enter any value greater than the current one. However, if the new value exceeds the available size, an error is displayed.
+====
+
+[id="virt-expanding-vm-disk-pvc-editing-manifest_{context}"]
+== Expanding a VM disk PVC by editing its manifest
 
 .Procedure
 
diff --git a/modules/virt-installing-qemu-guest-agent-on-linux-vm.adoc b/modules/virt-installing-qemu-guest-agent-on-linux-vm.adoc
index 692f04f8348e..c2b2c324d560 100644
--- a/modules/virt-installing-qemu-guest-agent-on-linux-vm.adoc
+++ b/modules/virt-installing-qemu-guest-agent-on-linux-vm.adoc
@@ -7,14 +7,13 @@
 [id="virt-installing-qemu-guest-agent-on-linux-vm_{context}"]
 = Installing the QEMU guest agent on a Linux VM
 
-The `qemu-guest-agent` is widely available and available by default in {op-system-base-full} virtual machines (VMs). Install the agent and start the service.
+The `qemu-guest-agent` is available by default in {op-system-base-full} virtual machines (VMs)
 
-[NOTE]
-====
-To create snapshots of an online (Running state) VM with the highest integrity, install the QEMU guest agent.
+To create snapshots of a VM in the `Running` state with the highest integrity, install the QEMU guest agent.
 
-The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system as much as possible, depending on the system workload. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. The conditions under which the snapshot was taken are reflected in the snapshot indications that are displayed in the web console or CLI.
-====
+The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. 
+
+The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again, or use an offline snapshot
 
 .Procedure
 
diff --git a/modules/virt-installing-qemu-guest-agent-on-windows-vm.adoc b/modules/virt-installing-qemu-guest-agent-on-windows-vm.adoc
index c6f0d92c3e8b..fbb2f6fe1fef 100644
--- a/modules/virt-installing-qemu-guest-agent-on-windows-vm.adoc
+++ b/modules/virt-installing-qemu-guest-agent-on-windows-vm.adoc
@@ -9,12 +9,13 @@
 
 For Windows virtual machines (VMs), the QEMU guest agent is included in the VirtIO drivers. You can install the drivers during a Windows installation or on an existing Windows VM.
 
-[NOTE]
-====
-To create snapshots of an online (Running state) VM with the highest integrity, install the QEMU guest agent.
+To create snapshots of a VM in the `Running` state with the highest integrity, install the QEMU guest agent.
 
-The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system as much as possible, depending on the system workload. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. The conditions under which the snapshot was taken are reflected in the snapshot indications that are displayed in the web console or CLI.
-====
+The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. 
+
+Note that in a Windows guest operating system, quiescing also requires the Volume Shadow Copy Service (VSS). Therefore, before you create a snapshot, ensure that VSS is enabled on the VM as well.
+
+The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again or use an offline snapshot.
 
 .Procedure
 
diff --git a/modules/virt-installing-virt-operator.adoc b/modules/virt-installing-virt-operator.adoc
index a2f9b9ba3ab8..759dedab298c 100644
--- a/modules/virt-installing-virt-operator.adoc
+++ b/modules/virt-installing-virt-operator.adoc
@@ -13,9 +13,9 @@ You can deploy the {VirtProductName} Operator by using the {product-title} web c
 * Install {product-title} {product-version} on your cluster.
 * Log in to the {product-title} web console as a user with `cluster-admin` permissions.
 // required for ROSA/OSD
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Create a machine pool based on a bare metal compute node instance type. For more information, see "Creating a machine pool" in the Additional resources of this section.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 .Procedure
 
diff --git a/modules/virt-manual-approval-strategy.adoc b/modules/virt-manual-approval-strategy.adoc
new file mode 100644
index 000000000000..c871e55e6b05
--- /dev/null
+++ b/modules/virt-manual-approval-strategy.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * virt/updating/upgrading-virt.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="virt-manual-approval-strategy_{context}"]
+= Manual approval strategy
+
+If you use the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported. To avoid risking the supportability and functionality of your cluster, use the *Automatic* approval strategy. 
+
+If you must use the *Manual* approval strategy, maintain a supportable cluster by approving pending Operator updates as soon as they become available.
\ No newline at end of file
diff --git a/modules/virt-metro-dr-odf.adoc b/modules/virt-metro-dr-odf.adoc
index 997e149992ec..2b85c78f23a2 100644
--- a/modules/virt-metro-dr-odf.adoc
+++ b/modules/virt-metro-dr-odf.adoc
@@ -6,7 +6,7 @@
 [id="metro-dr-odf_{context}"]
 = Metro-DR for {rh-storage-first}
 
-{VirtProductName} supports the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#metro-dr-solution[Metro-DR solution for {rh-storage}], which provides two-way synchronous data replication between managed {VirtProductName} clusters installed on primary and secondary sites.
+{VirtProductName} supports the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#metro-dr-solution[Metro-DR solution for {rh-storage}], which provides two-way synchronous data replication between managed {VirtProductName} clusters installed on primary and secondary sites.
 
 .Metro-DR differences
 * This synchronous solution is only available to metropolitan distance data centers with a network round-trip latency of 10 milliseconds or less. 
diff --git a/modules/virt-migrating-storage-class-ui.adoc b/modules/virt-migrating-storage-class-ui.adoc
new file mode 100644
index 000000000000..10af5ab23864
--- /dev/null
+++ b/modules/virt-migrating-storage-class-ui.adoc
@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// * virt/managing_vms/virtual_disks/virt-migrating-storage-class.adoc
+
+:_mod-docs-content-type: PROCEDURE
+
+[id="virt-migrating-storage-class-ui_{context}"]
+= Migrating VM disks to a different storage class by using the web console
+
+You can migrate one or more disks attached to a virtual machine (VM) to a different storage class by using the {product-title} web console. When performing this action on a running VM, the operation of the VM is not interrupted and the data on the migrated disks remains accessible.
+
+[NOTE]
+====
+With the {VirtProductName} Operator, you can only start storage class migration for one VM at the time and the VM must be running. If you need to migrate more VMs at once or migrate a mix of running and stopped VMs, consider using the link:https://docs.redhat.com/en/documentation/migration_toolkit_for_containers/{mtc-version}/html/migration_toolkit_for_containers/index[{mtc-first}].
+
+{mtc-full} is not part of {VirtProductName} and requires separate installation.
+====
+
+:FeatureName: Storage class migration
+include::snippets/technology-preview.adoc[]
+
+.Prerequisites
+
+* You must have a data volume or a persistent volume claim (PVC) available for storage class migration.
+* The cluster must have a node available for live migration. As part of the storage class migration, the VM is live migrated to a different node.
+* The VM must be running.
+
+.Procedure
+
+. Navigate to *Virtualization* -> *VirtualMachines* in the web console.
+. Click the Options menu {kebab} beside the virtual machine and select *Migration* -> *Storage*.
++
+You can also access this option from the *VirtualMachine details* page by selecting *Actions* -> *Migration* -> *Storage*.
+. On the *Migration details* page, choose whether to migrate the entire VM storage or selected volumes only. If you click *Selected volumes*, select any disks that you intend to migrate. Click *Next* to proceed.
+. From the list of available options on the *Destination StorageClass* page, select the storage class to migrate to. Click *Next* to proceed.
+. On the *Review* page, review the list of affected disks and the target storage class. To start the migration, click *Migrate VirtualMachine storage*.
+. Stay on the *Migrate VirtualMachine storage* page to watch the progress and wait for the confirmation that the migration completed successfully.
+
+.Verification
+
+. From the *VirtualMachine details* page, navigate to *Configuration* -> *Storage*.
+. Verify that all disks have the expected storage class listed in the *Storage class* column.
diff --git a/modules/virt-monitoring-upgrade-status.adoc b/modules/virt-monitoring-upgrade-status.adoc
index d31f6050144e..fa9ed0eafb1e 100644
--- a/modules/virt-monitoring-upgrade-status.adoc
+++ b/modules/virt-monitoring-upgrade-status.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-monitoring-upgrade-status_{context}"]
-= Monitoring {VirtProductName} upgrade status
+= Monitoring update status
 
-To monitor the status of a {VirtProductName} Operator upgrade, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
+To monitor the status of a {VirtProductName} Operator update, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
 
 [NOTE]
 ====
diff --git a/modules/virt-networking-glossary.adoc b/modules/virt-networking-glossary.adoc
index a480c8fd338a..a32d35c4ddc1 100644
--- a/modules/virt-networking-glossary.adoc
+++ b/modules/virt-networking-glossary.adoc
@@ -20,6 +20,10 @@ API resource that allows you to define custom resources, or an object defined by
 
 Network attachment definition (NAD):: A CRD introduced by the Multus project that allows you to attach pods, virtual machines, and virtual machine instances to one or more networks.
 
+UserDefinedNetwork (UDN):: A namespace-scoped CRD introduced by the user-defined network API that can be used to create a tenant network that isolates the tenant namespace from other namespaces.
+
+ClusterUserDefinedNetwork (CUDN):: A cluster-scoped CRD introduced by the user-defined network API that cluster administrators can use to create a shared network across multiple namespaces.
+
 ifndef::openshift-rosa,openshift-dedicated[]
 Node network configuration policy (NNCP):: A CRD introduced by the nmstate project, describing the requested network configuration on nodes.
 You update the node network configuration, including adding and removing interfaces, by applying a `NodeNetworkConfigurationPolicy` manifest to the cluster.
diff --git a/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc b/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc
index 63ff7b5d1189..74d7089b8145 100644
--- a/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc
+++ b/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc
@@ -8,6 +8,27 @@
 
 When you update from one Extended Update Support (EUS) version to the next, you must manually disable automatic workload updates to prevent {VirtProductName} from migrating or evicting workloads during the update process.
 
+[IMPORTANT]
+====
+In {product-title} 4.16, the underlying {op-system-first} upgraded to version 9.4 of {op-system-base-full}. To operate correctly, all `virt-launcher` pods in the cluster need to use the same version of {op-system-base}.
+
+After upgrading to {product-title} 4.16 from an earlier version, re-enable workload updates in {VirtProductName} to allow `virt-launcher` pods to update. Before upgrading to the next {product-title} version, verify that all VMIs use up-to-date workloads:
+
+[source,terminal]
+----
+$ oc get kv kubevirt-kubevirt-hyperconverged -o json -n openshift-cnv | jq .status.outdatedVirtualMachineInstanceWorkloads
+----
+
+If the previous command returns a value larger than `0`, list all VMIs with outdated `virt-launcher` pods and start live migration to update them to a new version:
+
+[source,terminal]
+----
+$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
+----
+
+For the list of supported {product-title} releases and the {op-system-base} versions they use, see link:https://access.redhat.com/articles/6907891[{op-system-base} Versions Utilized by {op-system} and {product-title}].
+====
+
 .Prerequisites
 
 * You are running an EUS version of {product-title} and want to update to the next EUS version. You have not yet updated to the odd-numbered version in between.
@@ -206,4 +227,4 @@ $ oc get vmim -A
 
 .Next steps
 
-* You can now unpause the worker nodes' machine config pools.
\ No newline at end of file
+* Unpause the machine config pools for each compute node.
diff --git a/modules/virt-querying-metrics.adoc b/modules/virt-querying-metrics.adoc
index c9c199cceb8a..229215390ffa 100644
--- a/modules/virt-querying-metrics.adoc
+++ b/modules/virt-querying-metrics.adoc
@@ -21,7 +21,8 @@ ifndef::openshift-rosa,openshift-dedicated[]
 The following query can identify virtual machines that are waiting for Input/Output (I/O):
 
 `kubevirt_vmi_vcpu_wait_seconds_total`::
-Returns the wait time (in seconds) for a virtual machine's vCPU. Type: Counter.
+Returns the wait time (in seconds) on I/O for vCPUs of a virtual machine. Type: Counter. 
+
 
 A value above '0' means that the vCPU wants to run, but the host scheduler cannot run it yet. This inability to run indicates that there is an issue with I/O.
 
diff --git a/modules/virt-regional-dr-odf.adoc b/modules/virt-regional-dr-odf.adoc
index 928899ddcd69..c608247f4430 100644
--- a/modules/virt-regional-dr-odf.adoc
+++ b/modules/virt-regional-dr-odf.adoc
@@ -6,7 +6,7 @@
 [id="regional-dr-odf_{context}"]
 = Regional-DR for {rh-storage-first}
 
-{VirtProductName} supports the link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#rdr-solution[Regional-DR solution for {rh-storage}], which provides asynchronous data replication at regular intervals between managed {VirtProductName} clusters installed on primary and secondary sites.
+{VirtProductName} supports the link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.18/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#rdr-solution[Regional-DR solution for {rh-storage}], which provides asynchronous data replication at regular intervals between managed {VirtProductName} clusters installed on primary and secondary sites.
 
 .Regional-DR differences
 * Regional-DR supports higher network latency between the primary and secondary sites.
diff --git a/modules/virt-restoring-vm-from-snapshot-cli.adoc b/modules/virt-restoring-vm-from-snapshot-cli.adoc
index 832e09c40698..f218fdbd4078 100644
--- a/modules/virt-restoring-vm-from-snapshot-cli.adoc
+++ b/modules/virt-restoring-vm-from-snapshot-cli.adoc
@@ -12,6 +12,12 @@ You can restore an existing virtual machine (VM) to a previous configuration by
 
 * Power down the VM you want to restore.
 
+* Optional: Adjust what happens if the target VM is not fully stopped (_ready_). To do so, set the `targetReadinessPolicy` parameter in the `vmrestore` YAML configuration to one of the following values:
+** `FailImmediate` - The restore process fails immediately if the VM is not ready.
+** `StopTarget` - If the VM is not ready, it gets stopped, and the restore process starts.
+** `WaitGracePeriod 5` - The restore process waits for a set amount of time, in minutes, for the VM to be ready. This is the default setting, with the default value set to 5 minutes.
+** `WaitEventually` - The restore process waits indefinitely for the VM to be ready.
+
 .Procedure
 
 . Create a YAML file to define a `VirtualMachineRestore` object that specifies the name of the VM you want to restore and the name of the snapshot to be used as the source as in the following example:
diff --git a/modules/virt-restoring-vm-from-snapshot-web.adoc b/modules/virt-restoring-vm-from-snapshot-web.adoc
index aff723eddc89..83b60217dd7a 100644
--- a/modules/virt-restoring-vm-from-snapshot-web.adoc
+++ b/modules/virt-restoring-vm-from-snapshot-web.adoc
@@ -17,3 +17,9 @@ You can restore a virtual machine (VM) to a previous configuration represented b
 . Select a snapshot to open the *Snapshot Details* screen.
 . Click the Options menu {kebab} and select *Restore VirtualMachine from snapshot*.
 . Click *Restore*.
+
+. Optional: You can also create a new VM based on the snapshot. To do so:  
+.. In the Options menu {kebab} of the the snapshot, select *Create VirtualMachine from Snapshot*.
+.. Provide a name for the new VM.
+.. Click *Create*
+
diff --git a/modules/virt-rhel-9.adoc b/modules/virt-rhel-9.adoc
index 4c0fedfdb150..ab6fc6b3001f 100644
--- a/modules/virt-rhel-9.adoc
+++ b/modules/virt-rhel-9.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="virt-rhel-9_{context}"]
-= {VirtProductName} on {op-system-base} 9
+= {op-system-base} 9 compatibility
 
 {VirtProductName} {VirtVersion} is based on {op-system-base-full} 9. You can update to {VirtProductName} {VirtVersion} from a version that was based on {op-system-base} 8 by following the standard {VirtProductName} update procedure. No additional steps are required.
 
diff --git a/modules/virt-runstrategies-vms.adoc b/modules/virt-runstrategies-vms.adoc
index 39eb8483ca2f..6a68799b55e3 100644
--- a/modules/virt-runstrategies-vms.adoc
+++ b/modules/virt-runstrategies-vms.adoc
@@ -9,7 +9,7 @@
 The `spec.runStrategy` key has four possible values:
 
 `Always`::
-The virtual machine instance (VMI) is always present when a virtual machine (VM) is created on another node. A new VMI is created if the original stops for any reason. This is the same behavior as `running: true`.
+The virtual machine instance (VMI) is always present when a virtual machine (VM) is created on another node. A new VMI is created if the original stops for any reason.
 
 `RerunOnFailure`::
 The VMI is re-created on another node if the previous instance fails. The instance is not re-created if the VM stops successfully, such as when it is shut down.
@@ -18,7 +18,7 @@ The VMI is re-created on another node if the previous instance fails. The instan
 You control the VMI state manually with the `start`, `stop`, and `restart` virtctl client commands. The VM is not automatically restarted.
 
 `Halted`::
-No VMI is present when a VM is created. This is the same behavior as `running: false`.
+No VMI is present when a VM is created.
 
 Different combinations of the `virtctl start`, `stop` and `restart` commands affect the run strategy.
 
diff --git a/modules/virt-setting-resource-quota-limits-for-vms.adoc b/modules/virt-setting-resource-quota-limits-for-vms.adoc
index 4f802b689735..7123c09479da 100644
--- a/modules/virt-setting-resource-quota-limits-for-vms.adoc
+++ b/modules/virt-setting-resource-quota-limits-for-vms.adoc
@@ -19,7 +19,7 @@ kind: VirtualMachine
 metadata:
   name: with-limits
 spec:
-  running: false
+  runStrategy: Halted
   template:
     spec:
       domain:
diff --git a/modules/virt-storage-wizard-fields-web.adoc b/modules/virt-storage-wizard-fields-web.adoc
index b501c2a85e4f..617cd165a3de 100644
--- a/modules/virt-storage-wizard-fields-web.adoc
+++ b/modules/virt-storage-wizard-fields-web.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/creating_vm/virt-creating-vms-from-templates.adoc
+// * virt/creating_vm/virt-creating-vms-from-templates.adoc
+// * virt/managing_vms/virt-edit-vms.adoc
 
 [id="virt-storage-wizard-fields-web_{context}"]
 = Storage fields
diff --git a/modules/virt-supported-cluster-version.adoc b/modules/virt-supported-cluster-version.adoc
index caf1e403e167..9862ae6b014f 100644
--- a/modules/virt-supported-cluster-version.adoc
+++ b/modules/virt-supported-cluster-version.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * virt/about-virt.adoc
+// * virt/about_virt/about-virt.adoc
 // * virt/virt_release_notes/virt-2-4-release-notes.adoc
 
 [id="virt-supported-cluster-version_{context}"]
-= {VirtProductName} supported cluster version
+= Supported cluster versions for {VirtProductName}
 
 {VirtProductName} {VirtVersion} is supported for use on {product-title} {product-version} clusters. To use the latest z-stream release of {VirtProductName}, you must first upgrade to the latest version of {product-title}.
diff --git a/modules/virt-temporary-token-VNC.adoc b/modules/virt-temporary-token-VNC.adoc
index 171e4fdbccdf..f839b79ed416 100644
--- a/modules/virt-temporary-token-VNC.adoc
+++ b/modules/virt-temporary-token-VNC.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/virt-accessing-vm-consoles.adoc
+// * virt/managing_vms/virt-accessing-vm-consoles.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-temporary-token-VNC_{context}"]
@@ -15,7 +15,7 @@ Kubernetes also supports authentication using client certificates, instead of a
 
 .Prerequisites
 
-* A running VM with {VirtProductName} 4.14 or later and xref:../../virt/about-virt/virt-architecture#virt-about-ssp-operator_virt-architecture[`ssp-operator`] 4.14 or later
+* A running VM with {VirtProductName} 4.14 or later and `ssp-operator` 4.14 or later.
 
 .Procedure
 
diff --git a/modules/virt-using-wasp-agent-to-configure-higher-vm-workload-density.adoc b/modules/virt-using-wasp-agent-to-configure-higher-vm-workload-density.adoc
index 1d422e61cbea..0deb83fc4252 100644
--- a/modules/virt-using-wasp-agent-to-configure-higher-vm-workload-density.adoc
+++ b/modules/virt-using-wasp-agent-to-configure-higher-vm-workload-density.adoc
@@ -13,6 +13,8 @@ The `wasp-agent` component facilitates memory overcommitment by assigning swap r
 Swap resources can be only assigned to virtual machine workloads (VM pods) of the `Burstable` Quality of Service (QoS) class. VM pods of the `Guaranteed` QoS class and pods of any QoS class that do not belong to VMs cannot swap resources.
 
 For descriptions of QoS classes, see link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/[Configure Quality of Service for Pods] (Kubernetes documentation).
+
+Using `spec.domain.resources.requests.memory` in the VM manifest disables the memory overcommit configuration. Use `spec.domain.memory.guest` instead.
 ====
 
 .Prerequisites
@@ -76,7 +78,8 @@ spec:
             [Unit]
             Description=Provision and enable swap
             ConditionFirstBoot=no
-            
+            ConditionPathExists=!/var/tmp/swapfile
+
             [Service]
             Type=oneshot
             Environment=SWAP_SIZE_MB=5000
@@ -84,13 +87,25 @@ spec:
             sudo chmod 600 /var/tmp/swapfile && \
             sudo mkswap /var/tmp/swapfile && \
             sudo swapon /var/tmp/swapfile && \
-            free -h && \
-            sudo systemctl set-property --runtime system.slice MemorySwapMax=0 IODeviceLatencyTargetSec=\"/ 50ms\""
-            
+            free -h"
+
             [Install]
             RequiredBy=kubelet-dependencies.target
           enabled: true
           name: swap-provision.service
+        - contents: |
+            [Unit]
+            Description=Restrict swap for system slice
+            ConditionFirstBoot=no
+
+            [Service]
+            Type=oneshot
+            ExecStart=/bin/sh -c "sudo systemctl set-property --runtime system.slice MemorySwapMax=0 IODeviceLatencyTargetSec=\"/ 50ms\""
+
+            [Install]
+            RequiredBy=kubelet-dependencies.target
+          enabled: true
+          name: cgroup-system-slice-config.service
 ----
 +
 To have enough swap space for the worst-case scenario, make sure to have at least as much swap space provisioned as overcommitted RAM. Calculate the amount of swap space to be provisioned on a node by using the following formula:
@@ -174,9 +189,9 @@ spec:
             - name: SWAP_UTILIZATION_THRESHOLD_FACTOR
               value: "0.8"
             - name: MAX_AVERAGE_SWAP_IN_PAGES_PER_SECOND
-              value: "1000"
+              value: "1000000000"
             - name: MAX_AVERAGE_SWAP_OUT_PAGES_PER_SECOND
-              value: "1000"
+              value: "1000000000"
             - name: AVERAGE_WINDOW_SIZE_SECONDS
               value: "30"
             - name: VERBOSITY
@@ -188,7 +203,7 @@ spec:
                 fieldRef:
                   fieldPath: spec.nodeName
           image: >-
-            quay.io/openshift-virtualization/wasp-agent:v4.17 <1>
+            quay.io/openshift-virtualization/wasp-agent:v4.18 <1>
           imagePullPolicy: Always
           name: wasp-agent
           resources:
diff --git a/modules/virt-viewing-automatically-created-storage-profiles.adoc b/modules/virt-viewing-automatically-created-storage-profiles.adoc
new file mode 100644
index 000000000000..4fa22fa39840
--- /dev/null
+++ b/modules/virt-viewing-automatically-created-storage-profiles.adoc
@@ -0,0 +1,75 @@
+// Module included in the following assemblies:
+//
+// * virt/storage/virt-configuring-storage-profile.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="virt-viewing-automatically-created-storage-profiles_{context}"]
+= Viewing automatically created storage profiles
+
+The system creates storage profiles for each storage class automatically.
+
+.Procedure
+. To view the list of storage profiles, run the following command:
++
+[source,terminal]
+----
+$ oc get storageprofile
+----
+
+. To fetch the details of a particular storage profile, run the following command:
++
+[source,terminal]
+----
+$ oc describe storageprofile <name>
+----
++
+.Example storage profile details
+[source,yaml]
+----
+Name:         ocs-storagecluster-ceph-rbd-virtualization
+Namespace:
+Labels:       app=containerized-data-importer
+              app.kubernetes.io/component=storage
+              app.kubernetes.io/managed-by=cdi-controller
+              app.kubernetes.io/part-of=hyperconverged-cluster
+              app.kubernetes.io/version=4.17.2
+              cdi.kubevirt.io=
+Annotations:  <none>
+API Version:  cdi.kubevirt.io/v1beta1
+Kind:         StorageProfile
+Metadata:
+  Creation Timestamp:  2023-11-13T07:58:02Z
+  Generation:          2
+  Owner References:
+    API Version:           cdi.kubevirt.io/v1beta1
+    Block Owner Deletion:  true
+    Controller:            true
+    Kind:                  CDI
+    Name:                  cdi-kubevirt-hyperconverged
+    UID:                   2d6f169a-382c-4caf-b614-a640f2ef8abb
+  Resource Version:        4186799537
+  UID:                     14aef804-6688-4f2e-986b-0297fd3aaa68
+Spec:
+Status:
+  Claim Property Sets: <1>
+    accessModes:
+      ReadWriteMany
+    volumeMode:  Block
+    accessModes:
+      ReadWriteOnce
+    volumeMode:  Block
+    accessModes:
+      ReadWriteOnce
+    volumeMode:                   Filesystem
+  Clone Strategy:                  csi-clone <2>
+  Data Import Cron Source Format:  snapshot <3>
+  Provisioner:                     openshift-storage.rbd.csi.ceph.com
+  Snapshot Class:                  ocs-storagecluster-rbdplugin-snapclass
+  Storage Class:                   ocs-storagecluster-ceph-rbd-virtualization
+Events:                            <none>
+----
+<1> `Claim Property Sets` is an ordered list of `AccessMode`/`VolumeMode` pairs, which describe the PVC modes that are used to provision VM disks.
+<2> The `Clone Strategy` line indicates the clone strategy to be used.
+<3> `Data Import Cron Source Format` indicates whether golden images on this storage are stored as PVCs or volume snapshots.
+
+
diff --git a/modules/virt-viewing-network-state-of-node-console.adoc b/modules/virt-viewing-network-state-of-node-console.adoc
index af7bfbc14899..6c005d7e24a4 100644
--- a/modules/virt-viewing-network-state-of-node-console.adoc
+++ b/modules/virt-viewing-network-state-of-node-console.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-viewing-network-state-of-node-console_{context}"]
-= Viewing the network state of a node from the web console
+= Viewing the network state of a node (NNS) from the web console
 
 As an administrator, you can use the {product-title} web console to observe `NodeNetworkState` resources and network interfaces, and access network details.
 
@@ -15,5 +15,21 @@ In the *NodeNetworkState* page, you can view the list of `NodeNetworkState` reso
 
 . To access the detailed information about `NodeNetworkState` resource, click the `NodeNetworkState` resource name listed in the *Name* column .
 
-. to expand and view the *Network Details* section for the `NodeNetworkState` resource, click the *>* icon . Alternatively, you can click on each interface type under the *Network interface* column to view the network details.
+. To expand and view the *Network Details* section for the `NodeNetworkState` resource, click the greater than (*>*) symbol . Alternatively, you can click on each interface type under the *Network interface* column to view the network details.
+
+[id="virt-viewing-graphical-representation-of-nns-topology_{context}"]
+== Viewing a graphical representation of the NNS topology
+
+To make the configuration of the node network in the cluster easier to understand, you can view it in the form of a diagram. The NNS topology diagram displays all node components (network interface controllers, bridges, bonds, and VLANs), their properties and configurations, and connections between the nodes.
+
+To open the topology view of the cluster, do the following:
+
+. In the *Administrator* view of the web console, navigate to *Networking* -> *NodeNetworkState*.
+. In the upper-right corner of the page, click the *Topology* icon.
++
+The NNS topology diagram opens. Each group of components represents a single node.
++
+* To display the configuration and propertires of a node, click inside the border of the node.
+* To display the features or the YAML file of a specific component (for example, an interface or a bridge), click the icon of the component.
+* The icons of active components have green borders; the icons of disconnected components have red borders.
 
diff --git a/modules/virt-viewing-outdated-workloads.adoc b/modules/virt-viewing-outdated-workloads.adoc
index b2276ca52641..ab6aafd5a70d 100644
--- a/modules/virt-viewing-outdated-workloads.adoc
+++ b/modules/virt-viewing-outdated-workloads.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="virt-viewing-outdated-workloads_{context}"]
-= Viewing outdated {VirtProductName} workloads
+= Viewing outdated VM workloads
 
-You can view a list of outdated workloads by using the CLI.
+You can view a list of outdated virtual machine (VM) workloads by using the CLI.
 
 [NOTE]
 ====
diff --git a/modules/virt-virtctl-commands.adoc b/modules/virt-virtctl-commands.adoc
index 0824ef2253c3..e503e8b7c187 100644
--- a/modules/virt-virtctl-commands.adoc
+++ b/modules/virt-virtctl-commands.adoc
@@ -73,6 +73,18 @@ You can use `virtctl create` commands to create manifests for virtual machines,
 |`virtctl create vm --name <vm_name>`
 |Create a VM manifest, specifying a name for the VM.
 
+|`virtctl create vm --user <user_name> --ssh-key\|password-file=<value>`
+|Create a VM manifest with a cloud-init configuration to create the selected user and either add an SSH public key from the supplied string, or a password from a file.
+
+|`virtctl create vm --access-cred type:password,src:<secret>`
+|Create a VM manifest with a user and password combination injected from the selected secret.
+
+|`virtctl create vm --access-cred type:ssh,src:<secret>,user:<user_name>`
+|Create a VM manifest with an SSH public key injected from the selected secret.
+
+|`virtctl create vm --volume-sysprep src:<config_map>`
+|Create a VM manifest, specifying a config map to use as the sysprep volume. The config map must contain a valid answer file named `unattend.xml` or `autounattend.xml`.
+
 |`virtctl create vm --instancetype <instancetype_name>`
 |Create a VM manifest that uses an existing cluster-wide instance type.
 
@@ -201,7 +213,7 @@ Optional:
 * `--keep-vme` retains the `VirtualMachineExport` CR after download. The default behavior is to delete the `VirtualMachineExport` CR after download.
 * `--insecure` enables an insecure HTTP connection.
 
-|`virtctl vmexport download <vmexport_name> --<vm\|snapshot\|pvc>=<object_name> --output=<output_file> --volume=<volume_name>`
+|`virtctl vmexport download <vmexport_name> --vm\|snapshot\|pvc=<object_name> --output=<output_file> --volume=<volume_name>`
 |Create a `VirtualMachineExport` CR and then download the volume defined in the CR.
 
 |`virtctl vmexport download export --manifest`
@@ -323,5 +335,8 @@ You use the `virtctl image-upload` commands to upload a VM image to a data volum
 
 |`virtctl image-upload dv <datavolume_name> --size=<datavolume_size> --image-path=</path/to/image>`
 |Upload a VM image to a new data volume of a specified requested size.
+
+|`virtctl image-upload dv <datavolume_name> --datasource --size=<datavolume_size> --image-path=</path/to/image>`
+|Upload a VM image to a new data volume and create an associated `DataSource` object for it.
 |===
 
diff --git a/modules/virt-vm-custom-scheduler.adoc b/modules/virt-vm-custom-scheduler.adoc
index 7d973f8713f0..83de4f57a503 100644
--- a/modules/virt-vm-custom-scheduler.adoc
+++ b/modules/virt-vm-custom-scheduler.adoc
@@ -22,7 +22,7 @@ kind: VirtualMachine
 metadata:
   name: vm-fedora
 spec:
-  running: true
+  runStrategy: Always
   template:
     spec:
       schedulerName: my-scheduler <1>
diff --git a/modules/virt-vm-storage-volume-types.adoc b/modules/virt-vm-storage-volume-types.adoc
index 2d7c4e6e9cec..6daa5dfa75b6 100644
--- a/modules/virt-vm-storage-volume-types.adoc
+++ b/modules/virt-vm-storage-volume-types.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
-// * virt/virtual_machines/creating_vm/virt-creating-vms-from-templates.adoc
+// * virt/creating_vm/virt-creating-vms-from-templates.adoc
+// * virt/managing_vms/virt-edit-vms.adoc
 
 [id="virt-vm-storage-volume-types_{context}"]
 = Storage volume types
diff --git a/modules/virt-vmware-comparison.adoc b/modules/virt-vmware-comparison.adoc
new file mode 100644
index 000000000000..c06b5aed5fd9
--- /dev/null
+++ b/modules/virt-vmware-comparison.adoc
@@ -0,0 +1,51 @@
+// Module included in the following assemblies:
+//
+// * virt/about_virt/about-virt.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="virt-vmware-comparison_{context}"]
+= Comparing {VirtProductName} to {vmw-full}
+
+If you are familiar with {vmw-first}, the following table lists {VirtProductName} components that you can use to accomplish similar tasks. However, because {VirtProductName} is conceptually different from {vmw-short}, and much of its functionality comes from the underlying {product-title}, {VirtProductName} does not have direct alternatives for all {vmw-short} concepts or components.
+
+.Mapping of {vmw-short} concepts to their closest {VirtProductName} counterparts
+[options="header"]
+[cols="2,2,3"]
+|===
+|{vmw-short} concept |{VirtProductName} |Explanation
+
+|Datastore
+|Persistent volume (PV){nbsp}+ +
+Persistent volume claim (PVC)
+|Stores VM disks. A PV represents existing storage and is attached to a VM through a PVC. When created with the `ReadWriteMany` (RWX) access mode, PVCs can be mounted by multiple VMs simultaneously.
+
+|Dynamic Resource Scheduling (DRS)
+|Pod eviction policy{nbsp}+ +
+Descheduler
+|Provides active resource balancing. A combination of pod eviction policies and a descheduler allows VMs to be live migrated to more appropriate nodes to keep node resource utilization manageable.
+
+|NSX
+|Multus{nbsp}+ +
+OVN-Kubernetes{nbsp}+ +
+Third-party container network interface (CNI) plug-ins
+|Provides an overlay network configuration. There is no direct equivalent for NSX in {VirtProductName}, but you can use the OVN-Kubernetes network provider or install certified third-party CNI plug-ins.
+
+|Storage Policy Based Management (SPBM)
+|Storage class
+|Provides policy-based storage selection. Storage classes represent various storage types and describe storage capabilities, such as quality of service, backup policy, reclaim policy, and whether volume expansion is allowed. A PVC can request a specific storage class to satisfy application requirements.
+
+|vCenter +
+vRealize Operations
+|OpenShift Metrics and Monitoring
+|Provides host and VM metrics. You can view metrics and monitor the overall health of the cluster and VMs by using the {product-title} web console.
+
+|vMotion
+|Live migration
+|Moves a running VM to another node without interruption. For live migration to be available, the PVC attached to the VM must have the `ReadWriteMany` (RWX) access mode.
+
+|vSwitch +
+DvSwitch
+|NMState Operator{nbsp}+ +
+Multus
+|Provides a physical network configuration. You can use the NMState Operator to apply state-driven network configuration and manage various network interface types, including Linux bridges and network bonds. With Multus, you can attach multiple network interfaces and connect VMs to external networks.
+|===
diff --git a/modules/virt-what-you-can-do-with-virt.adoc b/modules/virt-what-you-can-do-with-virt.adoc
index cee1409ccf85..8c5703c4c98a 100644
--- a/modules/virt-what-you-can-do-with-virt.adoc
+++ b/modules/virt-what-you-can-do-with-virt.adoc
@@ -6,27 +6,40 @@
 [id="virt-what-you-can-do-with-virt_{context}"]
 = What you can do with {VirtProductName}
 
-{VirtProductName} is an add-on to {product-title} that allows you to run and manage virtual machine workloads alongside container workloads.
+ifndef::openshift-origin[]
+{VirtProductName} provides the scalable, enterprise-grade virtualization functionality in Red{nbsp}Hat OpenShift.
+endif::[]
+ifdef::openshift-origin[]
+{VirtProductName} provides the scalable, enterprise-grade virtualization functionality in {product-title}.
+endif::[]
+You can use it to manage virtual machines (VMs) exclusively or alongside container workloads.
+
+ifndef::openshift-origin,openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+[NOTE]
+====
+If you have a {ove-first} subscription, you can run unlimited VMs on subscribed hosts, but you cannot run application instances in containers. For more information, see the subscription guide section about link:https://www.redhat.com/en/resources/self-managed-openshift-subscription-guide#section-8[{ove-first} and related products].
+====
+endif::[]
 
 {VirtProductName} adds new objects into your {product-title} cluster by using Kubernetes custom resources to enable virtualization tasks. These tasks include:
 
-* Creating and managing Linux and Windows virtual machines (VMs)
+* Creating and managing Linux and Windows VMs
 * Running pod and VM workloads alongside each other in a cluster
-* Connecting to virtual machines through a variety of consoles and CLI tools
-* Importing and cloning existing virtual machines
-* Managing network interface controllers and storage disks attached to virtual machines
-* Live migrating virtual machines between nodes
+* Connecting to VMs through a variety of consoles and CLI tools
+* Importing and cloning existing VMs
+* Managing network interface controllers and storage disks attached to VMs
+* Live migrating VMs between nodes
 
-An enhanced web console provides a graphical portal to manage these virtualized resources alongside the {product-title} cluster containers and infrastructure.
+You can manage your cluster and virtualization resources by using the *Virtualization* perspective of the {product-title} web console, and by using the {oc-first}.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 {VirtProductName} is designed and tested to work well with {rh-storage-first} features.
 
 [IMPORTANT]
 ====
 When you deploy {VirtProductName} with {rh-storage}, you must create a dedicated storage class for Windows virtual machine disks. See link:https://access.redhat.com/articles/6978371[Optimizing ODF PersistentVolumes for Windows VMs] for details.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // A line about support for OVN and OpenShiftSDN network providers has been moved to the `about-virt` assembly due to xrefs.
 // If you are re-using this module, you might also want to include that line in your assembly.
diff --git a/modules/web-console-overview.adoc b/modules/web-console-overview.adoc
index 1fce87494a4e..afd1c74d4881 100644
--- a/modules/web-console-overview.adoc
+++ b/modules/web-console-overview.adoc
@@ -7,7 +7,7 @@
 
 The web console runs as a pod on the control plane node. The static assets required to run the web console are served by the pod. 
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 After you install {product-title} using the `openshift-install create cluster` command, you can find the web console URL and login credentials for the installed cluster in the CLI output of the installation program. For example:
 
 [source,terminal]
@@ -28,9 +28,9 @@ For existing clusters that you did not install, you can use `oc whoami --show-co
 ====
 The `dir` parameter specifies the `assets` directory, which stores the manifest files, the ISO image, and the `auth` directory. The `auth` directory stores the `kubeadmin-password` and `kubeconfig` files. As a `kubeadmin` user, you can use the `kubeconfig` file to access the cluster with the following setting: `export KUBECONFIG=<install_directory>/auth/kubeconfig`. The `kubeconfig` is specific to the generated ISO image, so if the `kubeconfig` is set and the `oc` command fails, it is possible that the system did not boot with the generated ISO image. To perform debugging, during the bootstrap process, you can log in to the console as the `core` user by using the contents of the `kubeadmin-password` file.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 .Procedure
 
@@ -39,4 +39,4 @@ ifdef::openshift-rosa,openshift-dedicated[]
 . On the cluster *Overview* tab, click *Open console*, and log in with your credentials.
 
 Alternatively, use the `oc whoami --show-console` command to get the web console URL.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/modules/windows-upgrades-eus.adoc b/modules/windows-upgrades-eus.adoc
new file mode 100644
index 000000000000..3231617a7001
--- /dev/null
+++ b/modules/windows-upgrades-eus.adoc
@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * windows_containers/windows-node-upgrades.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="wmco-upgrades-eus_{context}"]
+= Windows Machine Config Operator Control Plane Only update
+
+{product-title} and Windows Machine Config Operator (WMCO) support updating from one EUS version to another EUS version of {product-title}, in a process called a *Control Plane Only* update. After upgrading the cluster, the Windows nodes are updated from the starting EUS version to the new EUS version while keeping the Windows workloads in a healthy state with no disruptions.
+
+[IMPORTANT]
+====
+This update was previously known as an *EUS-to-EUS* update and is now referred to as a *Control Plane Only* update. These updates are only viable between *even-numbered minor versions* of {product-title}.
+====
diff --git a/modules/wmco-configure-debug-logging.adoc b/modules/wmco-configure-debug-logging.adoc
new file mode 100644
index 000000000000..030c718907f7
--- /dev/null
+++ b/modules/wmco-configure-debug-logging.adoc
@@ -0,0 +1,40 @@
+// Module included in the following assemblies:
+//
+// windows_containers/enabling-windows-container-workloads.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="wmco-configure-debug-logging_{context}"]
+= Configuring debug-level logging for the Windows Machine Config Operator
+
+By default, the Windows Machine Config Operator (WMCO) is configured to use the `info` log level. You can change the log level to `debug` by editing the WMCO `Subscription` object. 
+
+.Procedure
+
+. Edit the `windows-machine-config-operator` subscription in the `windows-machine-config-operator` namespace by using the following command:
++
+[source,terminal]
+----
+$ oc edit subscription windows-machine-config-operator -n openshift-windows-machine-config-operator
+----
+
+. Add the follwing parameters to the `.spec.config.env` stanza:
++
+[source,yaml]
+----
+apiVersion: operators.coreos.com/v1alpha1
+kind: Subscription
+# ...
+  name: windows-machine-config-operator
+  namespace: openshift-windows-machine-config-operator
+# ...
+spec:
+# ...
+  config:
+    env:
+    - name: ARGS <1>
+      value: --debugLogging <2>
+----
+<1> Defines a list of environment variables that must exist in all containers in the pod.
+<2> Specifies the `debug` level of verbosity for log messages.
+
+You can revert to the default `info` log level by removing the `name` and `value` parameters that you added. 
diff --git a/modules/wmco-upgrades-eus-using-cli.adoc b/modules/wmco-upgrades-eus-using-cli.adoc
new file mode 100644
index 000000000000..81a92c4f54c1
--- /dev/null
+++ b/modules/wmco-upgrades-eus-using-cli.adoc
@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * windows_containers/windows-node-upgrades.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="wmco-upgrades-eus-using-cli_{context}"]
+= WMCO Control Plane Only update by using the CLI
+
+You can use the {oc-first} to perform a Control Plane Only update of the Windows Machine Config Operator (WMCO).
+
+.Prerequisites
+* The cluster must be running on a supported EUS version of {product-title}.
+* All Windows nodes must be in a healthy state.
+* All Windows nodes must be running on the same version of the WMCO.
+* All the of the prerequisites of the Control Plane Only update are met, as described in "Performing a Control Plane Only update."
+
+.Procedure
+
+. Uninstall the WMCO Operator from the cluster by following the steps in "Deleting Operators from a cluster using the CLI."
++
+[IMPORTANT]
+====
+Delete the Operator only. Do not delete the Windows namespace or any Windows workloads.
+====
+
+. Update {product-title} by following the steps in "Performing a Control Plane Only update."
+
+. Install the new WMCO version by following the steps in "Installing the Windows Machine Config Operator using the CLI."
+
+.Verification 
+
+* On the Verify that the *Status* shows *Succeeded* to confirm successful installation of the WMCO.
+
diff --git a/modules/wmco-upgrades-eus-using-web-console.adoc b/modules/wmco-upgrades-eus-using-web-console.adoc
new file mode 100644
index 000000000000..a3283daa8815
--- /dev/null
+++ b/modules/wmco-upgrades-eus-using-web-console.adoc
@@ -0,0 +1,34 @@
+// Module included in the following assemblies:
+//
+// * windows_containers/windows-node-upgrades.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="wmco-upgrades-eus-using-web-console_{context}"]
+= WMCO Control Plane Only update by using the web console
+
+You can use the {product-title} web console to perform a Control Plane Only update of the Windows Machine Config Operator (WMCO).
+
+.Prerequisites
+* The cluster must be running on a supported EUS version of {product-title}.
+* All Windows nodes must be in a healthy state.
+* All Windows nodes must be running on the same version of the WMCO.
+* All the of the prerequisites of the Control Plane Only update are met, as described in "Performing a Control Plane Only update."
+
+.Procedure
+
+. Uninstall WMCO operator by using the following the steps:
++
+[IMPORTANT]
+====
+Delete the Operator only. Do not delete the Windows namespace or any Windows workloads.
+====
++
+.. Log in to the {product-title} web console.
+.. Navigate to *Operators -> OperatorHub*.
+.. Use the *Filter by keyword* box to search for `Red Hat Windows Machine Config Operator`.
+.. Click the *Red Hat Windows Machine Config Operator* tile. The Operator tile indicates it is installed.
+.. In the *Windows Machine Config Operator* descriptor page, click *Uninstall*.
+
+. Update {product-title} by following the steps in "Performing a Control Plane Only update."
+
+. Install the new WMCO version by following the steps in "Installing the Windows Machine Config Operator using the web console."
diff --git a/modules/wmco-upgrades.adoc b/modules/wmco-upgrades.adoc
index 7dbcba1d03a3..0053acd94e50 100644
--- a/modules/wmco-upgrades.adoc
+++ b/modules/wmco-upgrades.adoc
@@ -3,16 +3,16 @@
 // * windows_containers/windows-node-upgrades.adoc
 
 [id="wmco-upgrades_{context}"]
-= Windows Machine Config Operator upgrades
+= Windows Machine Config Operator updates
 
-When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is upgraded based on the upgrade channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO upgrade results in the Kubernetes components in the Windows machine being upgraded.
+When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is updated based on the update channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO update results in the Kubernetes components in the Windows machine being updated.
 
 [NOTE]
 ====
-If you are upgrading to a new version of the WMCO and want to use cluster monitoring, you must have the `openshift.io/cluster-monitoring=true` label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display.
+If you are updating to a new version of the WMCO and want to use cluster monitoring, you must have the `openshift.io/cluster-monitoring=true` label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display.
 ====
 
-For a non-disruptive upgrade, the WMCO terminates the Windows machines configured by the previous version of the WMCO and recreates them using the current version. This is done by deleting the `Machine` object, which results in the drain and deletion of the Windows node. To facilitate an upgrade, the WMCO adds a version annotation to all the configured nodes. During an upgrade, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an upgrade, the WMCO only updates one Windows machine at a time.
+For a non-disruptive update, the WMCO terminates the Windows machines configured by the previous version of the WMCO and recreates them using the current version. This is done by deleting the `Machine` object, which results in the drain and deletion of the Windows node. To facilitate an update, the WMCO adds a version annotation to all the configured nodes. During an update, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an update, the WMCO only updates one Windows machine at a time.
 
 After the update, it is recommended that you set the `spec.os.name.windows` parameter in your workload pods. The WMCO uses this field to authoritatively identify the pod operating system for validation and is used to enforce Windows-specific pod security context constraints (SCCs).
 
diff --git a/modules/ztp-configuring-the-hub-cluster-for-backup-and-restore.adoc b/modules/ztp-configuring-the-hub-cluster-for-backup-and-restore.adoc
new file mode 100644
index 000000000000..131109fdd42d
--- /dev/null
+++ b/modules/ztp-configuring-the-hub-cluster-for-backup-and-restore.adoc
@@ -0,0 +1,177 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ztp-configuring-the-hub-cluster-for-backup-and-restore_{context}"]
+= Configuring the hub cluster for backup and restore
+
+You can use {ztp} to configure a set of policies to back up `BareMetalHost` resources. 
+This allows you to recover data from a failed hub cluster and deploy a replacement cluster using {rh-rhacm-first}.
+
+.Prerequisites
+
+* You have installed the OpenShift CLI (`oc`).
+
+* You have logged in as a user with `cluster-admin` privileges.
+
+.Procedure
+
+. Create a policy to add the `cluster.open-cluster-management.io/backup=cluster-activation` label to all `BareMetalHost` resources that have the `infraenvs.agent-install.openshift.io` label.
+Save the policy as `BareMetalHostBackupPolicy.yaml`. 
++
+The following example adds the `cluster.open-cluster-management.io/backup` label to all `BareMetalHost` resources that have the `infraenvs.agent-install.openshift.io` label:
++
+.Example Policy
+[source,yaml]
+----
+apiVersion: policy.open-cluster-management.io/v1
+kind: Policy
+metadata:
+  name: bmh-cluster-activation-label
+  annotations:
+    policy.open-cluster-management.io/description: Policy used to add the cluster.open-cluster-management.io/backup=cluster-activation label to all BareMetalHost resources
+spec:
+  disabled: false
+  policy-templates:
+    - objectDefinition:
+        apiVersion: policy.open-cluster-management.io/v1
+        kind: ConfigurationPolicy
+        metadata:
+          name: set-bmh-backup-label
+        spec:
+          object-templates-raw: |
+            {{- /* Set cluster-activation label on all BMH resources */ -}}
+            {{- $infra_label := "infraenvs.agent-install.openshift.io" }}
+            {{- range $bmh := (lookup "metal3.io/v1alpha1" "BareMetalHost" "" "" $infra_label).items }}
+                - complianceType: musthave
+                  objectDefinition:
+                    kind: BareMetalHost
+                    apiVersion: metal3.io/v1alpha1
+                    metadata:
+                      name: {{ $bmh.metadata.name }}
+                      namespace: {{ $bmh.metadata.namespace }}
+                      labels:
+                        cluster.open-cluster-management.io/backup: cluster-activation <1>
+            {{- end }}
+          remediationAction: enforce
+          severity: high
+---
+apiVersion: cluster.open-cluster-management.io/v1beta1
+kind: Placement
+metadata:
+  name: bmh-cluster-activation-label-pr
+spec:
+  predicates:
+    - requiredClusterSelector:
+        labelSelector:
+          matchExpressions:
+            - key: name
+              operator: In
+              values:
+                - local-cluster
+---
+apiVersion: policy.open-cluster-management.io/v1
+kind: PlacementBinding
+metadata:
+  name: bmh-cluster-activation-label-binding
+placementRef:
+  name: bmh-cluster-activation-label-pr
+  apiGroup: cluster.open-cluster-management.io
+  kind: Placement
+subjects:
+  - name: bmh-cluster-activation-label
+    apiGroup: policy.open-cluster-management.io
+    kind: Policy
+---
+apiVersion: cluster.open-cluster-management.io/v1beta2
+kind: ManagedClusterSetBinding
+metadata:
+  name: default
+  namespace: default
+spec:
+  clusterSet: default
+----
+<1> If you apply the `cluster.open-cluster-management.io/backup: cluster-activation` label to `BareMetalHost` resources, the {rh-rhacm} cluster backs up those resources.
+You can restore the `BareMetalHost` resources if the active cluster becomes unavailable, when restoring the hub activation resources.
+
+. Apply the policy by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f BareMetalHostBackupPolicy.yaml
+----
+
+.Verification
+
+. Find all `BareMetalHost` resources with the label `infraenvs.agent-install.openshift.io`  by running the following command: 
++
+[source,terminal]
+----
+$ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io
+----
++
+.Example output
+[source,yaml]
+----
+NAMESPACE      NAME             STATE   CONSUMER   ONLINE   ERROR   AGE
+baremetal-ns   baremetal-name                      false            50s
+----
+
+. Verify that the policy has applied the label `cluster.open-cluster-management.io/backup=cluster-activation` to all these resources, by running the following command:
++
+[source,terminal]
+----
+$ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io,cluster.open-cluster-management.io/backup=cluster-activation
+----
++
+.Example output
+[source,yaml]
+----
+NAMESPACE      NAME             STATE   CONSUMER   ONLINE   ERROR   AGE
+baremetal-ns   baremetal-name                      false            50s
+----
++
+The output must show the same list as in the previous step, which listed all `BareMetalHost` resources with the label `infraenvs.agent-install.openshift.io`.
+This confirms that that all the `BareMetalHost` resources with the `infraenvs.agent-install.openshift.io` label also have the `cluster.open-cluster-management.io/backup: cluster-activation` label.
++
+The following example shows a `BareMetalHost` resource with the `infraenvs.agent-install.openshift.io` label. 
+The resource must also have the `cluster.open-cluster-management.io/backup: cluster-activation` label, which was added by the policy created in step 1.
++
+[source,yaml]
+----
+apiVersion: metal3.io/v1alpha1
+kind: BareMetalHost
+metadata:
+  labels:
+    cluster.open-cluster-management.io/backup: cluster-activation
+    infraenvs.agent-install.openshift.io: value
+  name: baremetal-name
+  namespace: baremetal-ns
+----
+
+You can now use {rh-rhacm-title} to restore a managed cluster. 
+
+[IMPORTANT]
+====
+When you restore `BareMetalHosts` resources as part of restoring the cluster activation data, you must restore the `BareMetalHosts` status.
+The following {rh-rhacm} `Restore` resource example restores activation resources, including `BareMetalHosts`, and also restores the status for the `BareMetalHosts` resources:
+[source,yaml]
+----
+apiVersion: cluster.open-cluster-management.io/v1beta1
+kind: Restore
+metadata:
+  name: restore-acm-bmh
+  namespace: open-cluster-management-backup
+spec:
+  cleanupBeforeRestore: CleanupRestored
+  veleroManagedClustersBackupName: latest <1>
+  veleroCredentialsBackupName: latest
+  veleroResourcesBackupName: latest
+  restoreStatus:
+    includedResources: 
+      - BareMetalHosts<2>
+----
+====
+<1> Set `veleroManagedClustersBackupName: latest` to restore activation resources.
+<2> Restores the status for `BareMetalHosts` resources.
\ No newline at end of file
diff --git a/modules/ztp-creating-ztp-crs-for-multiple-managed-clusters.adoc b/modules/ztp-creating-ztp-crs-for-multiple-managed-clusters.adoc
index 7cda513cc763..0e74611b5a79 100644
--- a/modules/ztp-creating-ztp-crs-for-multiple-managed-clusters.adoc
+++ b/modules/ztp-creating-ztp-crs-for-multiple-managed-clusters.adoc
@@ -15,3 +15,5 @@ You can provision single clusters manually or in batches with {ztp}:
 Provisioning a single cluster:: Create a single `SiteConfig` CR and related installation and configuration CRs for the cluster, and apply them in the hub cluster to begin cluster provisioning. This is a good way to test your CRs before deploying on a larger scale.
 
 Provisioning many clusters:: Install managed clusters in batches of up to 400 by defining `SiteConfig` and related CRs in a Git repository. ArgoCD uses the `SiteConfig` CRs to deploy the sites. The {rh-rhacm} policy generator creates the manifests and applies them to the hub cluster. This starts the cluster provisioning process.
+
+include::snippets/siteconfig-deprecation-notice.adoc[]
diff --git a/modules/ztp-deleting-node-using-siteconfig.adoc b/modules/ztp-deleting-node-using-siteconfig.adoc
index ad5103b3b713..7639453997aa 100644
--- a/modules/ztp-deleting-node-using-siteconfig.adoc
+++ b/modules/ztp-deleting-node-using-siteconfig.adoc
@@ -101,7 +101,7 @@ If you are working with secrets, deleting a secret too early can cause an issue
 Delete the secret only after the node cleanup, when the current ArgoCD synchronization is complete.
 ====
 
-.Next Steps
+.Next steps
 
 To reprovision a node, delete the changes previously added to the `SiteConfig`, push the changes to the Git repository, and wait for the synchronization to complete.
 This regenerates the `BareMetalHost` CR of the worker node and triggers the re-install of the node.
diff --git a/modules/ztp-deploying-a-site.adoc b/modules/ztp-deploying-a-site.adoc
index a692477e8552..0f6ec7d633da 100644
--- a/modules/ztp-deploying-a-site.adoc
+++ b/modules/ztp-deploying-a-site.adoc
@@ -8,6 +8,8 @@
 
 Use the following procedure to create a `SiteConfig` custom resource (CR) and related files and initiate the {ztp-first} cluster deployment.
 
+include::snippets/siteconfig-deprecation-notice.adoc[]
+
 .Prerequisites
 
 * You have installed the OpenShift CLI (`oc`).
diff --git a/modules/ztp-generating-install-and-config-crs-manually.adoc b/modules/ztp-generating-install-and-config-crs-manually.adoc
index fed72f454cf2..1110fb11f26c 100644
--- a/modules/ztp-generating-install-and-config-crs-manually.adoc
+++ b/modules/ztp-generating-install-and-config-crs-manually.adoc
@@ -8,6 +8,8 @@
 
 Use the `generator` entrypoint for the `ztp-site-generate` container to generate the site installation and configuration custom resource (CRs) for a cluster based on `SiteConfig` and `{policy-gen-cr}` CRs.
 
+include::snippets/siteconfig-deprecation-notice.adoc[]
+
 .Prerequisites
 
 * You have installed the OpenShift CLI (`oc`).
diff --git a/modules/ztp-gitops-ztp-max-spoke-clusters.adoc b/modules/ztp-gitops-ztp-max-spoke-clusters.adoc
index e4a727fd90d7..8af4eac9088a 100644
--- a/modules/ztp-gitops-ztp-max-spoke-clusters.adoc
+++ b/modules/ztp-gitops-ztp-max-spoke-clusters.adoc
@@ -52,15 +52,6 @@ The following guidelines are based on internal lab benchmark testing only and do
 |Requirement
 |Description
 
-|{product-title}
-|version 4.13
-
-|{rh-rhacm}
-|version 2.7
-
-|{cgu-operator-first}
-|version 4.13
-
 |Server hardware
 |3 x Dell PowerEdge R650 rack servers
 
diff --git a/modules/ztp-image-based-upgrade-procedure-rollback.adoc b/modules/ztp-image-based-upgrade-procedure-rollback.adoc
index e0ed6b945d51..37877fd10dbd 100644
--- a/modules/ztp-image-based-upgrade-procedure-rollback.adoc
+++ b/modules/ztp-image-based-upgrade-procedure-rollback.adoc
@@ -34,8 +34,8 @@ spec:
         - spoke4
   ibuSpec:
     seedImageRef:
-      image: quay.io/seed/image:4.17.0-rc.1
-      version: 4.17.0-rc.1
+      image: quay.io/seed/image:4.18.0-rc.1
+      version: 4.18.0-rc.1
       pullSecretRef:
         name: "<seed_pull_secret>"
     extraManifests:
diff --git a/modules/ztp-image-based-upgrade-procedure-steps.adoc b/modules/ztp-image-based-upgrade-procedure-steps.adoc
index a5919d01116f..a58e928c4bd5 100644
--- a/modules/ztp-image-based-upgrade-procedure-steps.adoc
+++ b/modules/ztp-image-based-upgrade-procedure-steps.adoc
@@ -57,6 +57,12 @@ spec:
 ----
 <1> Clusters to upgrade.
 <2> Target platform version, the seed image to be used, and the secret required to access the image.
++
+[NOTE]
+====
+If you add the seed image pull secret in the hub cluster, in the same namespace as the `ImageBasedGroupUpgrade` resource, the secret is added to the manifest list for the `Prep` stage. The secret is recreated in each spoke cluster in the `openshift-lifecycle-agent` namespace.
+====
++
 <3> Optional: Applies additional manifests, which are not in the seed image, to the target cluster. Also applies `ConfigMap` objects for custom catalog sources.
 <4> List of `ConfigMap` resources that contain the {oadp-short} `Backup` and `Restore` CRs.
 <5> Upgrade plan details.
diff --git a/modules/ztp-precaching-ztp-config.adoc b/modules/ztp-precaching-ztp-config.adoc
index a84b72d6f7c8..2f90c86e4cf9 100644
--- a/modules/ztp-precaching-ztp-config.adoc
+++ b/modules/ztp-precaching-ztp-config.adoc
@@ -13,6 +13,8 @@ In the {ztp-first} provisioning workflow, the {factory-prestaging-tool} requires
 * `nodes.installerArgs`
 * `nodes.ignitionConfigOverride`
 
+include::snippets/siteconfig-deprecation-notice.adoc[]
+
 .Example SiteConfig with additional fields
 [source,yaml]
 ----
diff --git a/modules/ztp-sno-accelerated-ztp.adoc b/modules/ztp-sno-accelerated-ztp.adoc
index 134ddefe2bd9..bbc1c138c532 100644
--- a/modules/ztp-sno-accelerated-ztp.adoc
+++ b/modules/ztp-sno-accelerated-ztp.adoc
@@ -34,7 +34,7 @@ spec:
   baseDomain: "example.com"
   pullSecretRef:
     name: "assisted-deployment-pull-secret"
-  clusterImageSetNameRef: "openshift-4.10"
+  clusterImageSetNameRef: "openshift-4.18"
   sshPublicKey: "ssh-rsa AAAA..."
   clusters:
   # ...
diff --git a/modules/ztp-sno-siteconfig-config-reference.adoc b/modules/ztp-sno-siteconfig-config-reference.adoc
index 48dd19ed804e..4e9803bc63a0 100644
--- a/modules/ztp-sno-siteconfig-config-reference.adoc
+++ b/modules/ztp-sno-siteconfig-config-reference.adoc
@@ -16,11 +16,6 @@
 a|Configure workload partitioning by setting the value for `cpuPartitioningMode` to `AllNodes`.
 To complete the configuration, specify the `isolated` and `reserved` CPUs in the `PerformanceProfile` CR.
 
-[NOTE]
-====
-Configuring workload partitioning by using the `cpuPartitioningMode` field in the `SiteConfig` CR is a Tech Preview feature in {product-title} 4.13.
-====
-
 |`metadata.name`
 |Set `name` to `assisted-deployment-pull-secret` and create the `assisted-deployment-pull-secret` CR in the same namespace as the `SiteConfig` CR.
 
@@ -51,9 +46,10 @@ For example, `acmpolicygenerator/acm-common-ranGen.yaml` applies to all clusters
 
 |`spec.clusters.diskEncryption`
 a|Configure this field to enable disk encryption with Trusted Platform Module (TPM) and Platform Configuration Registers (PCRs) protection. For more information, see "About disk encryption with TPM and PCR protection".
+
 [NOTE]
 ====
-Configuring disk encryption by using the `diskEncryption` field in the `SiteConfig` CR is a Technology Preview feature in {product-title} 4.17.
+Configuring disk encryption by using the `diskEncryption` field in the `SiteConfig` CR is a Technology Preview feature in {product-title} 4.18.
 ====
 
 |`spec.clusters.diskEncryption.type`
diff --git a/modules/ztp-telco-core-software-versions.adoc b/modules/ztp-telco-core-software-versions.adoc
deleted file mode 100644
index 1329aee7638a..000000000000
--- a/modules/ztp-telco-core-software-versions.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-// Module included in the following assemblies:
-//
-// * telco_ref_design_specs/core/telco-core-ref-validation-artifacts.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="ztp-telco-core-software-versions_{context}"]
-= Telco core {product-version} validated solution software versions
-
-The Red Hat telco core version {product-version} solution has been validated using the following Red Hat software products.
-
-.Telco core {product-version} validated solution software
-[cols=2*, width="80%", options="header"]
-|====
-|Product
-|Software version
-
-|Hub cluster {product-title} version
-|4.13
-
-|{ztp} plugin
-|4.11, 4.12, or 4.13
-
-|{rh-rhacm-first}
-|2.7
-
-|{gitops-title}
-|1.9
-
-|{cgu-operator-first}
-|4.11, 4.12, or 4.13
-|====
diff --git a/modules/ztp-telco-hub-cluster-software-versions.adoc b/modules/ztp-telco-hub-cluster-software-versions.adoc
new file mode 100644
index 000000000000..c1a5cc695f20
--- /dev/null
+++ b/modules/ztp-telco-hub-cluster-software-versions.adoc
@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="ztp-telco-hub-cluster-software-versions_{context}"]
+= Telco RAN DU {product-version} hub cluster validated software components
+
+The Red Hat telco RAN {product-version} solution has been validated using the following Red Hat software products for {product-title} hub clusters.
+
+.Telco hub cluster validated software components
+[cols=2*, width="80%", options="header"]
+|====
+|Component
+|Software version
+
+|Hub cluster version
+|4.18
+
+|{rh-rhacm-first}
+|2.12^1^
+
+|{gitops-title}
+|1.14
+
+|{ztp} site generate plugins
+|4.18
+
+|{cgu-operator-first}
+|4.18
+|====
+[1] This table will be updated when the aligned {rh-rhacm} version 2.13 is released.
diff --git a/modules/ztp-telco-ran-software-versions.adoc b/modules/ztp-telco-ran-software-versions.adoc
index 44506f2eb025..194a9ab65a08 100644
--- a/modules/ztp-telco-ran-software-versions.adoc
+++ b/modules/ztp-telco-ran-software-versions.adoc
@@ -1,13 +1,12 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/ztp-preparing-the-hub-cluster.adoc
-// * scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.adoc
+// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="ztp-telco-ran-software-versions_{context}"]
 = Telco RAN DU {product-version} validated software components
 
-The Red Hat telco RAN DU {product-version} solution has been validated using the following Red Hat software products for {product-title} managed clusters and hub clusters.
+The Red Hat telco RAN DU {product-version} solution has been validated using the following Red Hat software products for {product-title} managed clusters.
 
 .Telco RAN DU managed cluster validated software components
 [cols=2*, width="80%", options="header"]
@@ -16,48 +15,27 @@ The Red Hat telco RAN DU {product-version} solution has been validated using the
 |Software version
 
 |Managed cluster version
-|4.17
+|4.18
 
 |Cluster Logging Operator
-|6.0
+|6.1^1^
 
 |Local Storage Operator
-|4.17
+|4.18
 
-|{oadp-first}
-|1.4.1
+|OpenShift API for Data Protection (OADP)
+|1.4
 
 |PTP Operator
-|4.17
+|4.18
 
-|SRIOV Operator
-|4.17
+|SR-IOV Operator
+|4.18
 
 |SRIOV-FEC Operator
-|2.9
+|2.10
 
-|{lcao}
-|4.17
-|====
-
-.Hub cluster validated software components
-[cols=2*, width="80%", options="header"]
-|====
-|Component
-|Software version
-
-|Hub cluster version
-|4.17
-
-|{rh-rhacm-first}
-|2.11
-
-|{ztp} plugin
-|4.17
-
-|{gitops-title}
-|1.13
-
-|{cgu-operator-first}
-|4.17
+|Lifecycle Agent
+|4.18
 |====
+[1] This table will be updated when the aligned Cluster Logging Operator version 6.2 is released.
diff --git a/modules/ztp-troubleshooting-ztp-gitops-installation-crs.adoc b/modules/ztp-troubleshooting-ztp-gitops-installation-crs.adoc
index 729631cde561..70344519f167 100644
--- a/modules/ztp-troubleshooting-ztp-gitops-installation-crs.adoc
+++ b/modules/ztp-troubleshooting-ztp-gitops-installation-crs.adoc
@@ -36,18 +36,31 @@ $ oc get managedcluster
 +
 [source,terminal]
 ----
-$ oc describe -n openshift-gitops application clusters
+$ oc get applications.argoproj.io -n openshift-gitops clusters -o yaml
 ----
 
-.. Check for the `Status.Conditions` field to view the error logs for the managed cluster. For example, setting an invalid value for `extraManifestPath:` in the `SiteConfig` CR raises the following error:
+.. To identify error logs for the managed cluster, inspect the `status.operationState.syncResult.resources` field. For example, if an invalid value is assigned to the `extraManifestPath` in the `SiteConfig` CR, an error similar to the following is generated:
 +
 [source,text]
 ----
-Status:
-  Conditions:
-    Last Transition Time:  2021-11-26T17:21:39Z
-    Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
-    Type:  ComparisonError
+syncResult:
+  resources:
+  - group: ran.openshift.io
+    kind: SiteConfig
+    message: The Kubernetes API could not find ran.openshift.io/SiteConfig for
+      requested resource spoke-sno/spoke-sno. Make sure the "SiteConfig" CRD is
+      installed on the destination cluster
+----
+
+.. To see a more detailed `SiteConfig` error, complete the following steps:
+
+... In the Argo CD dashboard, click the *SiteConfig* resource that Argo CD is trying to sync. 
+
+... Check the *DESIRED MANIFEST* tab to find the `siteConfigError` field.
++
+[source,text]
+----
+siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory
 ----
 
 .. Check the `Status.Sync` field. If there are log errors, the `Status.Sync` field could indicate an `Unknown` error:
diff --git a/networking/about-managed-networking.adoc b/networking/about-managed-networking.adoc
index 403ada3341f0..44b2fc3bad9d 100644
--- a/networking/about-managed-networking.adoc
+++ b/networking/about-managed-networking.adoc
@@ -16,15 +16,36 @@ The following are some of the most commonly used {openshift-networking} features
 +
 ** xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[OVN-Kubernetes network plugin], which is the default CNI plugin.
 ** {OCP-short} SDN network plugin, which was deprecated in {OCP-short} 4.16 and removed in {OCP-short} 4.17.
-+
+
+ifdef::openshift-rosa[]
+
+[IMPORTANT]
+====
+Before upgrading {rosa-classic} clusters that are configured with the OpenShift SDN network plugin to version 4.17, you must migrate to the OVN-Kubernetes network plugin. For more information, see _Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin_ in the  _Additional resources_ section.
+====
+endif::openshift-rosa[]
+
+ifdef::openshift-dedicated[]
+
 [IMPORTANT]
 ====
-You cannot migrate an {OCP-short} 4.16 cluster that uses the SDN network plugin to {OCP-short} 4.17 because no migration path currently exists.
+Before upgrading {product-title} clusters that are configured with the OpenShift SDN network plugin to version 4.17, you must migrate to the OVN-Kubernetes network plugin. For more information, see _Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin_ in the  _Additional resources_ section.
 ====
+endif::openshift-dedicated[]
+
 
 [discrete]
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources
 
-* link:https://access.redhat.com/articles/7065170[{OCP-short} SDN CNI removal in OCP 4.17]
\ No newline at end of file
+* link:https://access.redhat.com/articles/7065170[{OCP-short} SDN CNI removal in OCP 4.17]
+ifdef::openshift-rosa[]
+* xref:../networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc#migrate-from-openshift-sdn[Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin]
+endif::openshift-rosa[]
+
+ifdef::openshift-dedicated[]
+
+* xref:../networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn-osd.adoc#migrate-from-openshift-sdn-osd[Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin]
+endif::openshift-dedicated[]
+
diff --git a/networking/about-networking.adoc b/networking/about-networking.adoc
deleted file mode 100644
index d9e1ead66a68..000000000000
--- a/networking/about-networking.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="about-networking"]
-= About networking
-include::_attributes/common-attributes.adoc[]
-:context: about-networking
-
-toc::[]
-
-{openshift-networking} is an ecosystem of features, plugins and advanced networking capabilities that extend Kubernetes networking with the advanced networking-related features that your cluster needs to manage its network traffic for one or multiple hybrid clusters. This ecosystem of networking capabilities integrates ingress, egress, load balancing, high-performance throughput, security, inter- and intra-cluster traffic management and provides role-based observability tooling to reduce its natural complexities.
-
-
-The following list highlights some of the most commonly used {openshift-networking} features available on your cluster:
-
-- Primary cluster network provided by either of the following Container Network Interface (CNI) plugins:
-  * xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[OVN-Kubernetes network plugin], the default plugin
-  * xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[About the OVN-Kubernetes network plugin]
-- Certified 3rd-party alternative primary network plugins
-- Cluster Network Operator for network plugin management
-- Ingress Operator for TLS encrypted web traffic
-- DNS Operator for name assignment
-- MetalLB Operator for traffic load balancing on bare metal clusters
-- IP failover support for high-availability
-- Additional hardware network support through multiple CNI plugins, including for macvlan, ipvlan, and SR-IOV hardware networks
-- IPv4, IPv6, and dual stack addressing
-- Hybrid Linux-Windows host clusters for Windows-based workloads
-- {SMProductName} for discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring of services
-- {sno-caps}
-- Network Observability Operator for network debugging and insights
-- link:https://catalog.redhat.com/software/container-stacks/detail/5f0c67b7ce85fb9e399f3a12[Submariner] for inter-cluster networking
-- link:https://docs.redhat.com/en/documentation/red_hat_service_interconnect/[Red Hat Service Interconnect] for layer 7 inter-cluster networking
diff --git a/networking/cidr-range-definitions.adoc b/networking/cidr-range-definitions.adoc
index 29dc2ee7b013..76c141e6fa10 100644
--- a/networking/cidr-range-definitions.adoc
+++ b/networking/cidr-range-definitions.adoc
@@ -9,27 +9,59 @@ endif::openshift-dedicated,openshift-rosa[]
 
 toc::[]
 
-You must specify non-overlapping ranges for the following CIDR ranges.
+If your cluster uses OVN-Kubernetes, you must specify non-overlapping ranges for Classless Inter-Domain Routing (CIDR) subnet ranges.  
+
+[IMPORTANT]
+====
+For {product-title} 4.17 and later versions, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should also be avoided by users. For upgraded clusters, there is no change to the default masquerade subnet.
+====
+
+The following subnet types and are mandatory for a cluster that uses OVN-Kubernetes:
+
+* Join: Uses a join switch to connect gateway routers to distributed routers. A join switch reduces the number of IP addresses for a distributed router. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the join switch. 
+* Masquerade: Prevents collisions for identical source and destination IP addresses that are sent from a node as hairpin traffic to the same node after a load balancer makes a routing decision.
+* Transit: A transit switch is a type of distributed switch that spans across all nodes in the cluster. A transit switch routes traffic between different zones. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the transit switch. 
 
 [NOTE]
 ====
-Machine CIDR ranges cannot be changed after creating your cluster.
+You can change the join, masquerade, and transit CIDR ranges for your cluster as a post-installation task.
 ====
 
 ifdef::openshift-rosa,openshift-dedicated[]
 When specifying subnet CIDR ranges, ensure that the subnet CIDR range is within the defined Machine CIDR. You must verify that the subnet CIDR ranges allow for enough IP addresses for all intended workloads depending on which platform the cluster is hosted.
 endif::[]
 
+OVN-Kubernetes, the default network provider in {product-title} 4.14 and later versions, internally uses the following IP address subnet ranges:
+
+* `V4JoinSubnet`: `100.64.0.0/16`
+* `V6JoinSubnet`: `fd98::/64`
+* `V4TransitSwitchSubnet`: `100.88.0.0/16`
+* `V6TransitSwitchSubnet`: `fd97::/64`
+* `defaultV4MasqueradeSubnet`: `169.254.0.0/17`
+* `defaultV6MasqueradeSubnet`: `fd69::/112`
+
 [IMPORTANT]
 ====
-OVN-Kubernetes, the default network provider in {product-title} 4.14 and later versions, uses the following IP address ranges internally: `100.64.0.0/16`, `169.254.169.0/29`, `100.88.0.0/16`, `fd98::/64`, `fd69::/125`, and `fd97::/64`. If your cluster uses OVN-Kubernetes, do not include any of these IP address ranges in any other CIDR definitions in your cluster or infrastructure.
-
-For {product-title} 4.17 and later versions, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should also be avoided by users. For upgraded clusters, there is no change to the default masquerade subnet.
+The previous list includes join, transit, and masquerade IPv4 and IPv6 address subnets. If your cluster uses OVN-Kubernetes, do not include any of these IP address subnet ranges in any other CIDR definitions in your cluster or infrastructure.
 ====
 
+ifndef::openshift-rosa,openshift-dedicated[]
+[role="_additional-resources"]
+.Additional resources
+
+* For more information about configuring join subnets or transit subnets, see xref:../networking/ovn_kubernetes_network_provider/configure-ovn-kubernetes-subnets.adoc#configure-ovn-kubernetes-subnets[Configuring OVN-Kubernetes internal IP address subnets].
+endif::[]
+
 [id="machine-cidr-description"]
 == Machine CIDR
+
 In the Machine classless inter-domain routing (CIDR) field, you must specify the IP address range for machines or cluster nodes.
+
+[NOTE]
+====
+Machine CIDR ranges cannot be changed after creating your cluster.
+====
+
 ifdef::openshift-rosa,openshift-dedicated[]
 This range must encompass all CIDR address ranges for your virtual private cloud (VPC) subnets. Subnets must be contiguous. A minimum IP address range of 128 addresses, using the subnet prefix `/25`, is supported for single availability zone deployments. A minimum address range of 256 addresses, using the subnet prefix `/24`, is supported for deployments that use multiple availability zones.
 endif::openshift-rosa,openshift-dedicated[]
@@ -43,6 +75,14 @@ When using {hcp-title}, the static IP address `172.20.0.1` is reserved for the i
 ====
 endif::[]
 
+ifndef::openshift-rosa,openshift-dedicated[]
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/networking_operators/cluster-network-operator.adoc#nw-operator-cr_cluster-network-operator[Cluster Network Operator configuration]
+endif::[]
+
+
 [id="service-cidr-description"]
 == Service CIDR
 In the Service CIDR field, you must specify the IP address range for services.
diff --git a/networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc b/networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
index 9465f32662ac..75730dcf532a 100644
--- a/networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
+++ b/networking/configuring_ingress_cluster_traffic/configuring-externalip.adoc
@@ -17,6 +17,22 @@ This functionality is generally most useful for clusters installed on bare-metal
 // About ExternalIP
 include::modules/nw-externalip-about.adoc[leveloffset=+1]
 
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../networking/configuring-ipfailover.adoc#configuring-ipfailover[Configuring IP failover]
+
+* xref:../../networking/networking_operators/metallb-operator/about-metallb.adoc#about-metallb[About MetalLB and the MetalLB Operator]
+
+// Configuration for ExternalIP
+include::modules/configuration-externalip.adoc[leveloffset=+1]
+
+// Restrictions on the assignment of an external IP address
+include::modules/restrictions-on-ip-assignment.adoc[leveloffset=+1]
+
+// Example policy objects
+include::modules/example-policy-objects.adoc[leveloffset=+1]
+
 // ExternalIP address block configuration
 include::modules/nw-externalip-object.adoc[leveloffset=+1]
 
diff --git a/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-patch-fields.adoc b/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-patch-fields.adoc
new file mode 100644
index 000000000000..85ee796c608c
--- /dev/null
+++ b/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-patch-fields.adoc
@@ -0,0 +1,19 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="configuring-ingress-cluster-patch-fields"]
+= Patching existing ingress objects
+include::_attributes/common-attributes.adoc[]
+:context: configuring-ingress-cluster-patch-fields
+
+toc::[]
+
+You can update or modify the following fields of existing `Ingress` objects without recreating the objects or disrupting services to them:
+
+* Specifications
+* Host
+* Path
+* Backend services
+* SSL/TLS settings
+* Annotations
+
+// Example: Patching ingress objects with an ingressClassName
+include::modules/nw-patch-fields-example.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-aws.adoc b/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-aws.adoc
index 958e1c4f6dfc..6f91305c7a83 100644
--- a/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-aws.adoc
+++ b/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-aws.adoc
@@ -44,6 +44,8 @@ include::modules/nw-ingress-setting-select-subnet-loadbalancerservice.adoc[level
 
 include::modules/nw-ingress-setting-update-subnet-loadbalancerservice.adoc[leveloffset=+2]
 
+include::modules/nw-ingress-aws-static-eip-nlb-configuration.adoc[leveloffset=+2]
+
 [role="_additional-resources"]
 [id="additional-resources_configuring-ingress-cluster-traffic-aws"]
 == Additional resources
diff --git a/networking/enable-cluster-wide-proxy.adoc b/networking/enable-cluster-wide-proxy.adoc
index 26f4499aa1a5..866b03839690 100644
--- a/networking/enable-cluster-wide-proxy.adoc
+++ b/networking/enable-cluster-wide-proxy.adoc
@@ -8,30 +8,71 @@ toc::[]
 
 Production environments can deny direct access to the internet and instead have an HTTP or HTTPS proxy available. You can configure {product-title} to use a proxy by xref:../networking/enable-cluster-wide-proxy.adoc#nw-proxy-configure-object_config-cluster-wide-proxy[modifying the Proxy object for existing clusters] or by configuring the proxy settings in the `install-config.yaml` file for new clusters.
 
-== Prerequisites
+After you enable a cluster-wide egress proxy for your cluster on a supported platform, {op-system-first} populates the `status.noProxy` parameter with the values of the `networking.machineNetwork[].cidr`, `networking.clusterNetwork[].cidr`, and `networking.serviceNetwork[]` fields from your `install-config.yaml` file that exists on the supported platform. 
 
-* Review the xref:../installing/install_config/configuring-firewall.adoc#configuring-firewall[sites that your cluster requires access to] and determine whether any of them must bypass the proxy. By default, all cluster system egress traffic is proxied, including calls to the cloud provider API for the cloud that hosts your cluster. System-wide proxy affects system components only, not user workloads. Add sites to the Proxy object's `spec.noProxy` field to bypass the proxy if necessary.
-+
 [NOTE]
 ====
-The Proxy object `status.noProxy` field is populated with the values of the `networking.machineNetwork[].cidr`, `networking.clusterNetwork[].cidr`, and `networking.serviceNetwork[]` fields from your installation configuration with most installation types.
-
-For installations on Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and {rh-openstack-first}, the `Proxy` object `status.noProxy` field is also populated with the instance metadata endpoint (`169.254.169.254`).
+As a postinstallation task, you can change the `networking.clusterNetwork[].cidr` value, but not the `networking.machineNetwork[].cidr` and the `networking.serviceNetwork[]` values. For more information, see "Configuring the cluster network range".
 ====
-+
+
+For installations on {aws-first}, {gcp-first}, {azure-first}, and {rh-openstack-first}, the `status.noProxy` parameter is also populated with the instance metadata endpoint, `169.254.169.254`.
+
+.Example of values added to the `status:` segment of a `Proxy` object by {op-system}
+[source,yaml]
+----
+apiVersion: config.openshift.io/v1
+kind: Proxy
+metadata:
+  name: cluster
+# ...
+networking:
+  clusterNetwork: <1>
+  - cidr: <ip_address_from_cidr>
+    hostPrefix: 23
+  network type: OVNKubernetes
+  machineNetwork: <2>
+  - cidr: <ip_address_from_cidr>
+  serviceNetwork: <3>
+  - 172.30.0.0/16
+# ...
+status:
+  noProxy:
+  - localhost
+  - .cluster.local
+  - .svc
+  - 127.0.0.1
+  - <api_server_internal_url> <4>
+# ...
+----
+<1> Specify IP address blocks from which pod IP addresses are allocated. The default value is `10.128.0.0/14` with a host prefix of `/23`.
+<2> Specify the IP address blocks for machines. The default value is `10.0.0.0/16`.
+<3> Specify IP address block for services. The default value is `172.30.0.0/16`.
+<4> You can find the URL of the internal API server by running the `oc get infrastructures.config.openshift.io cluster -o jsonpath='{.status.etcdDiscoveryDomain}'` command. 
+
 [IMPORTANT]
 ====
 If your installation type does not include setting the `networking.machineNetwork[].cidr` field, you must include the machine IP addresses manually in the `.status.noProxy` field to make sure that the traffic between nodes can bypass the proxy.
 ====
 
+[id="prerequisites_cluster-wide-proxy"]
+== Prerequisites
+
+Review the xref:../installing/install_config/configuring-firewall.adoc#configuring-firewall[sites that your cluster requires access to] and determine whether any of them must bypass the proxy. By default, all cluster system egress traffic is proxied, including calls to the cloud provider API for the cloud that hosts your cluster. The system-wide proxy affects system components only, not user workloads. If necessary, add sites to the `spec.noProxy` parameter of the `Proxy` object to bypass the proxy.
+
+// Enabling the cluster-wide proxy
 include::modules/nw-proxy-configure-object.adoc[leveloffset=+1]
 
+// Removing the cluster-wide proxy
 include::modules/nw-proxy-remove.adoc[leveloffset=+1]
 
+// Verifying the cluster-wide proxy configuration
+include::modules/nw-verify-proxy-configuration.adoc[leveloffset=+1]
+
 [discrete]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../security/certificates/updating-ca-bundle.adoc#ca-bundle-understanding_updating-ca-bundle[Replacing the CA Bundle certificate]
-* xref:../security/certificate_types_descriptions/proxy-certificates.adoc#customization[Proxy certificate customization]
-* link:https://access.redhat.com/solutions/7065528[How is the cluster-wide proxy setting applied to {product-title} nodes?]
+* xref:../networking/configuring-cluster-network-range.adoc#configuring-cluster-network-range[Configuring the cluster network range]
+* xref:../security/certificates/updating-ca-bundle.adoc#ca-bundle-understanding_updating-ca-bundle[Understanding the CA Bundle certificate]
+* xref:../security/certificate_types_descriptions/proxy-certificates.adoc#customization[Proxy certificates]
+* link:https://access.redhat.com/solutions/7065528[How is the cluster-wide proxy setting applied to {product-title} nodes?]
\ No newline at end of file
diff --git a/networking/hardware_networks/about-sriov.adoc b/networking/hardware_networks/about-sriov.adoc
index 56a4a8e572a9..1331162e94f6 100644
--- a/networking/hardware_networks/about-sriov.adoc
+++ b/networking/hardware_networks/about-sriov.adoc
@@ -79,12 +79,11 @@ The SR-IOV Network resources injector and SR-IOV Network Operator webhook are en
 Use caution when disabling the SR-IOV Network Operator Admission Controller webhook. You can disable the webhook under specific circumstances, such as troubleshooting, or if you want to use unsupported devices.
 ====
 
+// Supported platforms
 include::modules/nw-sriov-supported-platforms.adoc[leveloffset=+2]
+
+// Supported devices
 include::modules/nw-sriov-supported-devices.adoc[leveloffset=+2]
-include::modules/nw-sriov-device-discovery.adoc[leveloffset=+2]
-include::modules/nw-sriov-example-vf-function-in-pod.adoc[leveloffset=+2]
-include::modules/nw-sriov-app-netutil.adoc[leveloffset=+2]
-include::modules/nw-sriov-huge-pages.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 [id="configure-multi-networks-additional-resources"]
@@ -95,8 +94,10 @@ include::modules/nw-sriov-huge-pages.adoc[leveloffset=+2]
 [id="about-sriov-next-steps"]
 == Next steps
 
-* Optional: xref:../../networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc#configuring-sriov-operator[Configuring the SR-IOV Network Operator]
+* xref:../../networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc#configuring-sriov-operator[Configuring the SR-IOV Network Operator]
 * xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
 * If you use {VirtProductName}: xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[Connecting a virtual machine to an SR-IOV network]
 * xref:../../networking/hardware_networks/configuring-sriov-net-attach.adoc#configuring-sriov-net-attach[Configuring an SR-IOV network attachment]
-* xref:../../networking/hardware_networks/add-pod.adoc#add-pod[Adding a pod to an SR-IOV additional network]
+* xref:../../networking/hardware_networks/configuring-sriov-net-attach.adoc#configuring-sriov-net-attach[Ethernet network attachement: Adding a pod to an SR-IOV additional network]
+* xref:../../networking/hardware_networks/configuring-sriov-ib-attach.adoc#configuring-sriov-ib-attach[InfiniBand network attachement: Adding a pod to an SR-IOV additional network]
+
diff --git a/networking/hardware_networks/add-pod.adoc b/networking/hardware_networks/add-pod.adoc
deleted file mode 100644
index 03e82d70f604..000000000000
--- a/networking/hardware_networks/add-pod.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="add-pod"]
-= Adding a pod to an SR-IOV additional network
-include::_attributes/common-attributes.adoc[]
-:context: configuring-sr-iov
-
-toc::[]
-
-You can add a pod to an existing Single Root I/O Virtualization (SR-IOV) network.
-
-Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator].
-
-include::modules/nw-sriov-runtime-config.adoc[leveloffset=+1]
-
-include::modules/nw-multus-add-pod.adoc[leveloffset=+1]
-
-include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2]
-
-include::modules/nw-sriov-topology-manager.adoc[leveloffset=+1]
-
-include::modules/nw-openstack-sr-iov-testpmd-pod.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-[id="add-pod-additional-resources"]
-== Additional resources
-
-* xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV Ethernet network attachment]
-* xref:../../networking/hardware_networks/configuring-sriov-ib-attach.adoc#configuring-sriov-ib-attach[Configuring an SR-IOV InfiniBand network attachment]
-* xref:../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager[Using CPU Manager]
-* xref:../../networking/hardware_networks/configuring-sriov-device.adoc#nw-sriov-exclude-topology-manager_configuring-sriov-device[Exclude SR-IOV network topology for NUMA-aware scheduling]
diff --git a/networking/hardware_networks/configuring-sriov-device.adoc b/networking/hardware_networks/configuring-sriov-device.adoc
index d0c63b1147d9..30b725fb5bcf 100644
--- a/networking/hardware_networks/configuring-sriov-device.adoc
+++ b/networking/hardware_networks/configuring-sriov-device.adoc
@@ -13,10 +13,28 @@ Before you perform any tasks in the following documentation, ensure that you xre
 // SR-IOV network node configuration object
 include::modules/nw-sriov-networknodepolicy-object.adoc[leveloffset=+1]
 
+// SR-IOV network node configuration examples
+include::modules/nw-sr-iov-network-node-configuration-examples.adoc[leveloffset=+2]
+
+// Automated discovery of SR-IOV network devices
+include::modules/nw-sriov-device-discovery.adoc[leveloffset=+2]
+
 // A direct companion to nw-sriov-networknodepolicy-object
 // Virtual function (VF) partitioning for SR-IOV devices
+
+include::modules/nw-sriov-nic-mlx-secure-boot.adoc[leveloffset=+2]
+
 include::modules/nw-sriov-nic-partitioning.adoc[leveloffset=+2]
 
+// A test pod template for clusters that use SR-IOV on OpenStack
+include::modules/nw-openstack-sr-iov-testpmd-pod.adoc[leveloffset=+2]
+
+// A test pod template for clusters that use OVS hardware offloading on OpenStack
+include::modules/nw-openstack-hw-offload-testpmd-pod.adoc[leveloffset=+2]
+
+// Huge pages resource injection for Downward API
+include::modules/nw-sriov-huge-pages.adoc[leveloffset=+2]
+
 // Configuring SR-IOV network devices
 include::modules/nw-sriov-configuring-device.adoc[leveloffset=+1]
 
@@ -25,20 +43,14 @@ include::modules/nw-sriov-configuring-device.adoc[leveloffset=+1]
 
 * xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes].
 
-// Configuring parallel node draining during SR-IOV network policy updates
-include::modules/nw-sriov-configuring-multiple-nodes.adoc[leveloffset=+2]
-
-// Troubleshooting SR-IOV configuration
-include::modules/nw-sriov-troubleshooting.adoc[leveloffset=+1]
-
-// Assigning an SR-IOV network to a VRF
-include::modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc[leveloffset=+1]
+// Creating a non-uniform memory access (NUMA) aligned SR-IOV pod
+include::modules/nw-sriov-topology-manager.adoc[leveloffset=+1]
 
 // Exclude the SR-IOV network topology for NUMA-aware scheduling
 include::modules/nw-sriov-exclude-topology-manager.adoc[leveloffset=+1]
 
-// Excluding the SR-IOV network topology for NUMA-aware scheduling
-include::modules/nw-sriov-configure-exclude-topology-manager.adoc[leveloffset=+2]
+// Troubleshooting SR-IOV configuration
+include::modules/nw-sriov-troubleshooting.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/networking/hardware_networks/configuring-sriov-ib-attach.adoc b/networking/hardware_networks/configuring-sriov-ib-attach.adoc
index feafce102aa0..8459b3f6c077 100644
--- a/networking/hardware_networks/configuring-sriov-ib-attach.adoc
+++ b/networking/hardware_networks/configuring-sriov-ib-attach.adoc
@@ -13,26 +13,29 @@ Before you perform any tasks in the following documentation, ensure that you xre
 // InfiniBand device configuration object
 include::modules/nw-sriov-ibnetwork-object.adoc[leveloffset=+1]
 
-// Configuration of IP address assignment for an additional network
-include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
-
 // Creating a configuration for assignment of dual-stack IP addresses dynamically
 include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]
 
-[role="_additional-resources"]
-.Additional resources
-* xref:../../networking/multiple_networks/secondary_networks/attaching-pod.adoc#attaching-pod[Attaching a pod to an additional network]
+// Configuration of IP address assignment for a network attachment
+include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
 
 // Configuring SR-IOV additional network
 include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1]
 
-[id="configuring-sriov-ib-attach-next-steps"]
-== Next steps
+// Runtime configuration for an InfiniBand-based SR-IOV attachment
+include::modules/nw-sriov-runtime-config-sriov-ib.adoc[leveloffset=+1]
+
+// Adding a pod to an additional network
+include::modules/nw-multus-add-pod.adoc[leveloffset=+1]
 
-* xref:../../networking/hardware_networks/add-pod.adoc#add-pod[Adding a pod to an SR-IOV additional network]
+// Exposing MTU for vfio-pci SR-IOV devices to pod
+include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 [id="configuring-sriov-ib-attach-additional-resources"]
 == Additional resources
 
- * xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
+* xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
+* xref:../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager[Using CPU Manager]
+* xref:../../networking/hardware_networks/configuring-sriov-device.adoc#nw-sriov-exclude-topology-manager_configuring-sriov-device[Exclude SR-IOV network topology for NUMA-aware scheduling]
+
diff --git a/networking/hardware_networks/configuring-sriov-net-attach.adoc b/networking/hardware_networks/configuring-sriov-net-attach.adoc
index 49200a1215f1..a16142b3f74c 100644
--- a/networking/hardware_networks/configuring-sriov-net-attach.adoc
+++ b/networking/hardware_networks/configuring-sriov-net-attach.adoc
@@ -10,24 +10,43 @@ You can configure an Ethernet network attachment for an Single Root I/O Virtuali
 
 Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator].
 
-
+// Ethernet device configuration object
 include::modules/nw-sriov-network-object.adoc[leveloffset=+1]
-include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
+
+// Creating a configuration for assignment of dual-stack IP addresses dynamically
 include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]
 
-[role="_additional-resources"]
-.Additional resources
-* xref:../../networking/multiple_networks/secondary_networks/attaching-pod.adoc#attaching-pod[Attaching a pod to an additional network]
+// Configuration of IP address assignment for a network attachment
+include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
 
+// Configuring SR-IOV additional network
 include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1]
 
-[id="configuring-sriov-net-attach-next-steps"]
-== Next steps
+// Assigning an SR-IOV network to a VRF
+include::modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc[leveloffset=+1]
+
+// Creating an additional SR-IOV network attachment with the CNI VRF plugin
+include::modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc[leveloffset=+2]
 
-* xref:../../networking/hardware_networks/add-pod.adoc#add-pod[Adding a pod to an SR-IOV additional network]
+// Runtime configuration for an Ethernet-based SR-IOV attachment
+include::modules/nw-sriov-runtime-config-ethernet.adoc[leveloffset=+1]
+
+// Adding a pod to an additional network
+include::modules/nw-multus-add-pod.adoc[leveloffset=+1]
+
+// Exposing MTU for vfio-pci SR-IOV devices to pod
+include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2]
+
+// Configuring parallel node draining during SR-IOV network policy updates
+include::modules/nw-sriov-configuring-multiple-nodes.adoc[leveloffset=+1]
+
+// Excluding the SR-IOV network topology for NUMA-aware scheduling
+include::modules/nw-sriov-configure-exclude-topology-manager.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 [id="configuring-sriov-net-attach-additional-resources"]
 == Additional resources
 
- * xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
+* xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
+* xref:../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager[Using CPU Manager]
+
diff --git a/networking/hardware_networks/configuring-sriov-rdma-cni.adoc b/networking/hardware_networks/configuring-sriov-rdma-cni.adoc
new file mode 100644
index 000000000000..8168fdacb9f8
--- /dev/null
+++ b/networking/hardware_networks/configuring-sriov-rdma-cni.adoc
@@ -0,0 +1,13 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="configuring-sriov-rdma-cni"]
+= Configuring an RDMA subsystem for SR-IOV
+include::_attributes/common-attributes.adoc[]
+:context: configuring-sriov-rdma-cni
+
+toc::[]
+
+Remote Direct Memory Access (RDMA) allows direct memory access between two systems without involving the operating system of either system.
+You can configure an RDMA Container Network Interface (CNI) on Single Root I/O Virtualization (SR-IOV) to enable high-performance, low-latency communication between containers.
+When you combine RDMA with SR-IOV, you provide a mechanism to expose hardware counters of Mellanox Ethernet devices for use inside  Data Plane Development Kit (DPDK)    applications.
+
+include::modules/nw-configuring-sriov-rdma-cni.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/networking/hardware_networks/using-dpdk-and-rdma.adoc b/networking/hardware_networks/using-dpdk-and-rdma.adoc
index a2e9e8614ffb..b0ee72d87ef5 100644
--- a/networking/hardware_networks/using-dpdk-and-rdma.adoc
+++ b/networking/hardware_networks/using-dpdk-and-rdma.adoc
@@ -10,6 +10,9 @@ The containerized Data Plane Development Kit (DPDK) application is supported on
 
 Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator].
 
+// Example use of a virtual function in a pod
+include::modules/nw-sriov-example-vf-function-in-pod.adoc[leveloffset=+1]
+
 // Using a virtual function in DPDK mode with an Intel NIC
 include::modules/nw-sriov-dpdk-example-intel.adoc[leveloffset=+1]
 
@@ -24,7 +27,7 @@ include::modules/nw-running-dpdk-rootless-tap.adoc[leveloffset=+1]
 
 // I can't seem to find this in 4.16 or 4.15 * xr3f:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-enable-container_use_devices_configuring-additional-network[Enabling the container_use_devices boolean]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
 
 * xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device]
 
@@ -32,6 +35,9 @@ include::modules/nw-sriov-concept-dpdk-line-rate.adoc[leveloffset=+1]
 
 include::modules/nw-sriov-example-dpdk-line-rate.adoc[leveloffset=+1]
 
+// DPDK library for use with container applications
+include::modules/nw-sriov-app-netutil.adoc[leveloffset=+2]
+
 include::modules/nw-sriov-network-operator.adoc[leveloffset=+2]
 
 include::modules/nw-sriov-create-object.adoc[leveloffset=+2]
@@ -49,30 +55,27 @@ include::snippets/technology-preview.adoc[leveloffset=+0]
 // Use a tag to skip header and include content only
 include::modules/nw-sriov-rdma-example-mellanox.adoc[tag=content]
 
+// A test pod template for clusters that use OVS-DPDK on OpenStack
 include::modules/nw-openstack-ovs-dpdk-testpmd-pod.adoc[leveloffset=+1]
 
-include::modules/nw-openstack-hw-offload-testpmd-pod.adoc[leveloffset=+1]
-
 [role="_additional-resources"]
 [id="additional-resources_using-dpdk-and-rdma"]
 == Additional resources
 
 * xref:../../networking/hardware_networks/about-sriov.adoc#supported-devices_about-sriov[Supported devices]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#adjusting-nic-queues-with-the-performance-profile_cnf-low-latency-perf-profile[Adjusting the NIC queues with the performance profile]
+* xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#adjusting-nic-queues-with-the-performance-profile_cnf-low-latency-perf-profile[Adjusting the NIC queues with the performance profile]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc#cnf-provisioning-low-latency-workloads[Provisioning real-time and low latency workloads]
+* xref:../../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#cnf-provisioning-low-latency-workloads[Provisioning real-time and low latency workloads]
 
 * xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[Installing the SR-IOV Network Operator]
 
 * xref:../../networking/hardware_networks/configuring-sriov-device.adoc#nw-sriov-networknodepolicy-object_configuring-sriov-device[Configuring an SR-IOV network device]
 * xref:../../networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc#nw-multus-whereabouts_configuring-additional-network[Dynamic IP address assignment configuration with Whereabouts]
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc#disabling-interrupt-processing-for-individual-pods_cnf-provisioning-low-latency[Disabling interrupt processing for individual pods]
+* xref:../../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#disabling-interrupt-processing-for-individual-pods_cnf-provisioning-low-latency[Disabling interrupt processing for individual pods]
 
 * xref:../../networking/hardware_networks/configuring-sriov-net-attach.adoc#configuring-sriov-net-attach[Configuring an SR-IOV Ethernet network attachment]
 
-* The xref:../../networking/hardware_networks/about-sriov.adoc#nw-sriov-app-netutil_about-sriov[app-netutil library] provides several API methods for gathering network information about a container's parent pod.
-
 :!FeatureName:
diff --git a/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc b/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc
index daf4515db460..a6b30bc143a3 100644
--- a/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc
+++ b/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc
@@ -11,6 +11,11 @@ After you install the Kubernetes NMState Operator, you can use the Operator to o
 
 For more information about how to install the NMState Operator, see xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator#k8s-nmstate-about-the-k8s-nmstate-operator[Kubernetes NMState Operator].
 
+[WARNING]
+====
+When configuring Virtual Route Forwarding (VRF) users must change their VRFs to a table ID lower than 1000 as higher than 1000 is reserved for {product-title}.
+====
+
 // Viewing the network state of a node by using the CLI
 include::modules/virt-viewing-network-state-of-node.adoc[leveloffset=+1]
 
@@ -27,6 +32,9 @@ include::modules/node-network-configuration-policy-file.adoc[leveloffset=+1]
 
 * xref:../../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#virt-removing-interface-from-nodes_{context}[Removing an interface from nodes]
 
+// Creating an InfiniBand interface on nodes
+include::modules/virt-creating-infiniband-interface-on-nodes.adoc[leveloffset=+1]
+
 // Managing policy from the web console
 include::modules/virt-node-network-config-console.adoc[leveloffset=+1]
 
@@ -36,13 +44,13 @@ include::modules/virt-monitor-node-network-config-console.adoc[leveloffset=+2]
 // Creating a policy
 include::modules/virt-create-node-network-config-console.adoc[leveloffset=+2]
 
-=== Updating the policy
+== Updating the policy
 
 // Updating the policy by using form
-include::modules/virt-update-node-network-config-form.adoc[leveloffset=+3]
+include::modules/virt-update-node-network-config-form.adoc[leveloffset=+2]
 
 // Updating the policy by using YAML
-include::modules/virt-update-node-network-config-yaml.adoc[leveloffset=+3]
+include::modules/virt-update-node-network-config-yaml.adoc[leveloffset=+2]
 
 // Deleting the policy
 include::modules/virt-delete-node-network-config.adoc[leveloffset=+2]
diff --git a/networking/load-balancing-openstack.adoc b/networking/load-balancing-openstack.adoc
index cecb2551828a..b642026720ce 100644
--- a/networking/load-balancing-openstack.adoc
+++ b/networking/load-balancing-openstack.adoc
@@ -16,3 +16,6 @@ include::modules/nw-osp-services-external-load-balancer.adoc[leveloffset=+1]
 
 // Configuring a user-managed load balancer
 include::modules/nw-osp-configuring-external-load-balancer.adoc[leveloffset=+2]
+
+// Configuring an Ingress controller to use floating IPs
+include::modules/nw-osp-specify-floating-ip.adoc[leveloffset=+1]
diff --git a/networking/metallb/metallb-configure-return-traffic.adoc b/networking/metallb/metallb-configure-return-traffic.adoc
index 498480b74e9b..ef5b9aab5f97 100644
--- a/networking/metallb/metallb-configure-return-traffic.adoc
+++ b/networking/metallb/metallb-configure-return-traffic.adoc
@@ -10,9 +10,6 @@ As a cluster administrator, you can effectively manage traffic for pods behind a
 
 To achieve this functionality, learn how to implement virtual routing and forwarding (VRF) instances with MetalLB, and configure egress services.
 
-:FeatureName: Configuring symmetric traffic by using a VRF instance with MetalLB and an egress service
-include::snippets/technology-preview.adoc[]
-
 [id="challenges-of-managing-symmetric-routing-with-metallb"]
 == Challenges of managing symmetric routing with MetalLB
 
@@ -62,3 +59,5 @@ include::modules/nw-metallb-configure-return-traffic-proc.adoc[leveloffset=+1]
 * xref:../../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#virt-example-host-vrf_k8s-nmstate-updating-node-network-config[Example: Network interface with a VRF instance node network configuration policy]
 
 * xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc#configuring-egress-traffic-loadbalancer-services[Configuring an egress service]
+
+* xref:../../networking/networking_operators/cluster-network-operator.adoc#nw-operator-cr-cno-object_cluster-network-operator[Cluster Network Operator configuration object]
diff --git a/networking/metallb/metallb-configure-services.adoc b/networking/metallb/metallb-configure-services.adoc
index 6883a74ddf5e..11bd6e261624 100644
--- a/networking/metallb/metallb-configure-services.adoc
+++ b/networking/metallb/metallb-configure-services.adoc
@@ -25,7 +25,7 @@ kind: Service
 metadata:
   name: <service_name>
   annotations:
-    metallb.universe.tf/address-pool: <address_pool_name>
+    metallb.io/address-pool: <address_pool_name>
 spec:
   selector:
     <label_key>: <label_value>
@@ -52,7 +52,7 @@ Events:
 [id="request-ip-address-from-pool_{context}"]
 == Request an IP address from a specific pool
 
-To assign an IP address from a specific range, but you are not concerned with the specific IP address, then you can use the `metallb.universe.tf/address-pool` annotation to request an IP address from the specified address pool.
+To assign an IP address from a specific range, but you are not concerned with the specific IP address, then you can use the `metallb.io/address-pool` annotation to request an IP address from the specified address pool.
 
 .Example service YAML for an IP address from a specific pool
 [source,yaml]
@@ -62,7 +62,7 @@ kind: Service
 metadata:
   name: <service_name>
   annotations:
-    metallb.universe.tf/address-pool: <address_pool_name>
+    metallb.io/address-pool: <address_pool_name>
 spec:
   selector:
     <label_key>: <label_value>
@@ -104,7 +104,7 @@ spec:
 == Share a specific IP address
 
 By default, services do not share IP addresses.
-However, if you need to colocate services on a single IP address, you can enable selective IP sharing by adding the `metallb.universe.tf/allow-shared-ip` annotation to the services.
+However, if you need to colocate services on a single IP address, you can enable selective IP sharing by adding the `metallb.io/allow-shared-ip` annotation to the services.
 
 [source,yaml]
 ----
@@ -113,8 +113,8 @@ kind: Service
 metadata:
   name: service-http
   annotations:
-    metallb.universe.tf/address-pool: doc-example
-    metallb.universe.tf/allow-shared-ip: "web-server-svc"  <1>
+    metallb.io/address-pool: doc-example
+    metallb.io/allow-shared-ip: "web-server-svc"  <1>
 spec:
   ports:
     - name: http
@@ -131,8 +131,8 @@ kind: Service
 metadata:
   name: service-https
   annotations:
-    metallb.universe.tf/address-pool: doc-example
-    metallb.universe.tf/allow-shared-ip: "web-server-svc"
+    metallb.io/address-pool: doc-example
+    metallb.io/allow-shared-ip: "web-server-svc"
 spec:
   ports:
     - name: https
@@ -144,7 +144,7 @@ spec:
   type: LoadBalancer
   loadBalancerIP: 172.31.249.7
 ----
-<1> Specify the same value for the `metallb.universe.tf/allow-shared-ip` annotation. This value is referred to as the _sharing key_.
+<1> Specify the same value for the `metallb.io/allow-shared-ip` annotation. This value is referred to as the _sharing key_.
 <2> Specify different port numbers for the services.
 <3> Specify identical pod selectors if you must specify `externalTrafficPolicy: local` so the services send traffic to the same set of pods. If you use the `cluster` external traffic policy, then the pod selectors do not need to be identical.
 <4> Optional: If you specify the three preceding items, MetalLB might colocate the services on the same IP address. To ensure that services share an IP address, specify the IP address to share.
diff --git a/networking/metallb/metallb-frr-k8s.adoc b/networking/metallb/metallb-frr-k8s.adoc
index 55ace527f794..a78390c1f44d 100644
--- a/networking/metallb/metallb-frr-k8s.adoc
+++ b/networking/metallb/metallb-frr-k8s.adoc
@@ -13,7 +13,10 @@ As a cluster administrator, you can use the `FRRConfiguration` custom resource (
 
 image::695_OpenShift_MetalLB_FRRK8s_integration_0624.png[MetalLB integration with FRR]
 
-
+[WARNING]
+====
+When configuring Virtual Route Forwarding (VRF) users must change their VRFs to a table ID lower than 1000 as higher than 1000 is reserved for {product-title}.
+====
 // FRR configurations
 include::modules/nw-metallb-frr-configurations.adoc[leveloffset=+1]
 
diff --git a/networking/metallb/metallb-troubleshoot-support.adoc b/networking/metallb/metallb-troubleshoot-support.adoc
index f76bed881194..419ccfa3a45d 100644
--- a/networking/metallb/metallb-troubleshoot-support.adoc
+++ b/networking/metallb/metallb-troubleshoot-support.adoc
@@ -26,7 +26,7 @@ include::modules/nw-metallb-metrics.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* See xref:../../observability/monitoring/managing-metrics.adoc#about-querying-metrics_managing-metrics[Querying metrics] for information about using the monitoring dashboard.
+* See xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#querying-metrics-for-all-projects-with-mon-dashboard_accessing-metrics-as-an-administrator[Querying metrics for all projects with the monitoring dashboard] for information about using the monitoring dashboard.
 
 // Collecting data
 include::modules/nw-metallb-collecting-data.adoc[leveloffset=+1]
diff --git a/networking/multiple_networks/configuring-additional-network.adoc b/networking/multiple_networks/configuring-additional-network.adoc
index 5cf575ec24d8..ab60bc8a9593 100644
--- a/networking/multiple_networks/configuring-additional-network.adoc
+++ b/networking/multiple_networks/configuring-additional-network.adoc
@@ -15,6 +15,7 @@ As a cluster administrator, you can configure an additional network for your clu
 * xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-macvlan-object_configuring-additional-network[MACVLAN]
 * xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-tap-object_configuring-additional-network[TAP]
 * xref:../../networking/multiple_networks/configuring-additional-network.adoc#configuration-ovnk-additional-networks_configuring-additional-network[OVN-Kubernetes]
+* xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-route-override-cni_configuring-additional-network[Route-override]
 
 [id="approaches-managing-additional-network_{context}"]
 == Approaches to managing an additional network
@@ -177,6 +178,9 @@ include::modules/nw-multus-macvlan-object.adoc[leveloffset=+2]
 // Configuration for a TAP additional network
 include::modules/nw-multus-tap-object.adoc[leveloffset=+2]
 
+// Configuration for route-override additional network
+include::modules/nw-route-override-cni.adoc[leveloffset=+2]
+
 [role="_additional-resources"]
 .Additional resources
 
diff --git a/networking/multiple_networks/primary_networks/about-user-defined-networks.adoc b/networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
index 3d8348f0bd9a..458d9edb37a6 100644
--- a/networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
+++ b/networking/multiple_networks/primary_networks/about-user-defined-networks.adoc
@@ -6,32 +6,20 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:featurename: `UserDefinedNetwork`
-include::snippets/technology-preview.adoc[]
+Before the implementation of user-defined networks (UDN), the OVN-Kubernetes CNI plugin for {product-title} only supported a Layer 3 topology on the primary or _main_ network. Due to Kubernetes design principles: all pods are attached to the main network, all pods communicate with each other by their IP addresses, and inter-pod traffic is restricted according to network policy.
 
-Before the implementation of user-defined networks (UDN), the OVN-Kubernetes CNI plugin only supported a Layer 3 topology on the primary, or main, network that all pods are attached to. This allowed for network models where all pods in the cluster were part of the same global Layer 3 network, but restricted the ability to customize primary network configurations.
+While the Kubernetes design is useful for simple deployments, this Layer 3 topology restricts customization of primary network segment configurations, especially for modern multi-tenant deployments.
 
-User-defined networks provide cluster administrators and users with highly customizable network configuration options for both primary and secondary network types. With UDNs, administrators can create tailored network topologies with enhanced isolation, IP address management for workloads, and advanced networking features. Supporting both Layer 2 and Layer 3 topology types, UDNs enable a wide range of network architectures and topologies, enhancing network flexibility, security, and performance.
+UDN improves the flexibility and segmentation capabilities of the default Layer 3 topology for a Kubernetes pod network by enabling custom Layer 2, Layer 3, and localnet network segments, where all these segments are isolated by default. These segments act as either primary or secondary networks for container pods and virtual machines that use the default OVN-Kubernetes CNI plugin. UDNs enable a wide range of network architectures and topologies, enhancing network flexibility, security, and performance.
 
 [NOTE]
 ====
-* Support for the Localnet topology on both primary and secondary networks will be added in a future version of {product-title}.
+Nodes that use `cgroupv1` Linux Control Groups (cgroup) must be reconfigured from `cgroupv1` to `cgroupv2` before creating a user-defined network. For more information, see xref:../../../nodes/clusters/nodes-cluster-cgroups-2.adoc#nodes-cluster-cgroups-2[Configuring Linux cgroup].
 ====
 
-Unlike NADs, which are only namespaced scope, UDNs offer administrators the ability to create and define additional networks spanning multiple namespaces at the cluster level by leveraging the `ClusterUserDefinedNetwork` custom resource (CR). UDNs also offer both administrators and users the ability to define additional networks at the namespace level with the `UserDefinedNetwork` CR. 
+A cluster administrator can use a UDN to create and define additional networks that span multiple namespaces at the cluster level by leveraging the `ClusterUserDefinedNetwork` custom resource (CR). Additionally, a cluster administrator or a cluster user can use a UDN to define additional networks at the namespace level with the `UserDefinedNetwork` CR.
 
-The following sections further emphasize the benefits and limitations of user-defined networks, the best practices when creating a `ClusterUserDefinedNetwork` or `UserDefinedNetwork` custom resource, how to create the custom resource, and additional configuration details that might be relevant to your deployment.
-
-// Looks like this may be out for 4.17, but in for 4.18 as of 8/19/24
-//. Ingress and egress support
-//+
-//* **Support for ingress and egress traffic**: Cluster ingress and egress traffic is supported for both primary and secondary networks.
-//* **Support for ingress and egress features**: User-defined networks support support the following ingress and egress features:
-//+
-//** EgressQoS
-//** EgressService
-//** EgressIP
-//** Load balancer and NodePort services, as well as services with external IPs.
+The following sections further emphasize the benefits and limitations of user-defined networks, the best practices when creating a `ClusterUserDefinedNetwork` or `UserDefinedNetwork` CR, how to create the CR, and additional configuration details that might be relevant to your deployment.
 
 //benefits of UDN
 include::modules/nw-udn-benefits.adoc[leveloffset=+1]
@@ -39,15 +27,42 @@ include::modules/nw-udn-benefits.adoc[leveloffset=+1]
 //Limitations that users should consider for UDN.
 include::modules/nw-udn-limitations.adoc[leveloffset=+1]
 
+//About CUDN CR
+include::modules/nw-cudn-about.adoc[leveloffset=+1]
+
+//Best practices for using CUDN.
+include::modules/nw-cudn-best-practices.adoc[leveloffset=+2]
+
+//How to implement the CUDN API on a cluster by using the CLI.
+include::modules/nw-cudn-cr.adoc[leveloffset=+2]
+
+//How to implement the CUDN API on a cluster by using the UI.
+include::modules/nw-cudn-cr-ui.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuring-pods-static-ip_configuring-additional-network-ovnk[Configuring pods with a static IP address]
+
+// About the UDN CR
+include::modules/nw-udn-about.adoc[leveloffset=+1]
+
 //Best practices for using UDN.
-include::modules/nw-udn-best-practices.adoc[leveloffset=+1]
+include::modules/nw-udn-best-practices.adoc[leveloffset=+2]
+
+//How to implement the UDN API by using the CLI.
+include::modules/nw-udn-cr.adoc[leveloffset=+2]
 
-//How to implement the UDN API on a cluster.
-include::modules/nw-udn-cr.adoc[leveloffset=+1]
+//How to implement the UDN API by using the UI
+include::modules/nw-udn-cr-ui.adoc[leveloffset=+2]
 
 //Explanation of optional config details
 include::modules/nw-udn-additional-config-details.adoc[leveloffset=+1]
 
+//UDN/CUDN status conditions
+include::modules/cudn-status-conditions.adoc[leveloffset=+1]
+
+include::modules/opening-default-network-ports-udn.adoc[leveloffset=+1]
+
 //Support matrix for UDN
 //include::modules
 
diff --git a/networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc b/networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc
index 0e298d51c1e2..b625232a6181 100644
--- a/networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc
+++ b/networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The following sections provide instructions and information for how to configure IP address assignments for secondary networks.
+The following sections give instructions and information for how to configure IP address assignments for secondary networks.
 
 include::modules/nw-multus-ipam-object.adoc[leveloffset=+1]
 
diff --git a/networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc b/networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc
index 4b517770983c..6a69e21c7870 100644
--- a/networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc
+++ b/networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 Administrators can use the `MultiNetworkPolicy` API to create multiple network policies that manage traffic for pods attached to secondary networks. For example, you can create policies that allow or deny traffic based on specific ports, IPs/ranges, or labels.
 
-Multi-network policies can be used to manage traffic on secondary networks in the cluster. They cannot managed the cluster's default network or primary network of user-defined networks. 
+Multi-network policies can be used to manage traffic on secondary networks in the cluster. These policies cannot manage the default cluster network or primary network of user-defined networks. 
 
 As a cluster administrator, you can configure a multi-network policy for any of the following network types:
 
diff --git a/networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc b/networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
index 393cda80274e..bffcd4706b4c 100644
--- a/networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
+++ b/networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
@@ -26,6 +26,9 @@ include::modules/nw-multus-macvlan-object.adoc[leveloffset=+1]
 // Configuration for a TAP additional network
 include::modules/nw-multus-tap-object.adoc[leveloffset=+1]
 
+// Configuration for a route-override additional network
+include::modules/nw-route-override-cni.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 .Additional resources
 
diff --git a/networking/multiple_networks/understanding-multiple-networks.adoc b/networking/multiple_networks/understanding-multiple-networks.adoc
index cb0d3e0d2bbe..b976b4d234da 100644
--- a/networking/multiple_networks/understanding-multiple-networks.adoc
+++ b/networking/multiple_networks/understanding-multiple-networks.adoc
@@ -67,4 +67,12 @@ networks in your cluster:
 
 * *TAP*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-tap-object_configuring-additional-network-cni[Configure a TAP-based additional network] to create a tap device inside the container namespace. A TAP device enables user space programs to send and receive network packets.
 
-* *SR-IOV*: xref:../../networking/hardware_networks/about-sriov.adoc#about-sriov[Configure an SR-IOV based additional network] to allow pods to attach to a virtual function (VF) interface on SR-IOV capable hardware on the host system.
+ * *SR-IOV*: xref:../../networking/hardware_networks/about-sriov.adoc#about-sriov[Configure an SR-IOV based additional network] to allow pods to attach to a virtual function (VF) interface on SR-IOV capable hardware on the host system.
+
+ * *route-override*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-route-override-cni_configuring-additional-network-cni[Configure a `route-override` based additional network] to allow pods to override and set routes.
+
+include::modules/nw-udn-support-matrix-primary-secondary.adoc[leveloffset=+1]
+
+.Additional resources
+
+* xref:../../networking/ovn_kubernetes_network_provider/enabling-multicast.adoc#nw-ovn-kubernetes-enabling-multicast[Enabling multicast for a project]
diff --git a/networking/network-verification.adoc b/networking/network-verification.adoc
index e72dc99f6582..06f0fe0abcea 100644
--- a/networking/network-verification.adoc
+++ b/networking/network-verification.adoc
@@ -41,7 +41,7 @@ ifdef::openshift-dedicated[]
 * Egress is available to the required domain and port combinations that are specified in the xref:../osd_planning/aws-ccs.adoc#osd-aws-privatelink-firewall-prerequisites_aws-ccs[AWS firewall prerequisites] section.
 endif::openshift-dedicated[]
 ifdef::openshift-rosa[]
-* Egress is available to the required domain and port combinations that are specified in the xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites] section.
+* Egress is available to the required domain and port combinations that are specified in the xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites] section.
 endif::openshift-rosa[]
 
 include::modules/automatic-network-verification-bypassing.adoc[leveloffset=+1]
diff --git a/networking/network_security/logging-network-security.adoc b/networking/network_security/logging-network-security.adoc
index eb854a034a30..d128e8fd9272 100644
--- a/networking/network_security/logging-network-security.adoc
+++ b/networking/network_security/logging-network-security.adoc
@@ -39,5 +39,9 @@ include::modules/nw-networkpolicy-audit-disable.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
+ifdef::openshift-rosa,openshift-enterprise[]
 * xref:../../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[About network policy]
+endif::openshift-rosa,openshift-enterprise[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../networking/network_security/egress_firewall/configuring-egress-firewall-ovn.adoc#configuring-egress-firewall-ovn[Configuring an egress firewall for a project]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/networking/zero-trust-networking.adoc b/networking/network_security/zero-trust-networking.adoc
similarity index 50%
rename from networking/zero-trust-networking.adoc
rename to networking/network_security/zero-trust-networking.adoc
index 1da4a2b15c12..5be4c491fe79 100644
--- a/networking/zero-trust-networking.adoc
+++ b/networking/network_security/zero-trust-networking.adoc
@@ -20,8 +20,8 @@ Public certificates and private keys are critical to zero trust networking. Thes
 
 Leverage:
 
-* {product-title}: OpenShift creates a xref:../security/certificate_types_descriptions/bootstrap-certificates.adoc#cert-types-bootstrap-certificates[cluster CA at installation] that is used to secure the cluster resources. However, {product-title} can also create and sign xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[certificates for services] in the cluster, and can inject the cluster CA bundle into a pod if requested. xref:../security/certificate_types_descriptions/service-ca-certificates.adoc#cert-types-service-ca-certificates[Service certificates] created and signed by {product-title} have a 26-month time to live (TTL) and are rotated automatically at 13 months. They can also be rotated manually if necessary.
-* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: cert-manager allows you to request keys that are signed by an external root of trust. There are many configurable issuers to integrate with external issuers, along with ways to run with a delegated signing certificate. The cert-manager API can be used by other software in zero trust networking to request the necessary certificates (for example, {SMProductName}), or can be used directly by customer software.
+* {product-title}: OpenShift creates a xref:../../security/certificate_types_descriptions/bootstrap-certificates.adoc#cert-types-bootstrap-certificates[cluster CA at installation] that is used to secure the cluster resources. However, {product-title} can also create and sign xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[certificates for services] in the cluster, and can inject the cluster CA bundle into a pod if requested. xref:../../security/certificate_types_descriptions/service-ca-certificates.adoc#cert-types-service-ca-certificates[Service certificates] created and signed by {product-title} have a 26-month time to live (TTL) and are rotated automatically at 13 months. They can also be rotated manually if necessary.
+* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: cert-manager allows you to request keys that are signed by an external root of trust. There are many configurable issuers to integrate with external issuers, along with ways to run with a delegated signing certificate. The cert-manager API can be used by other software in zero trust networking to request the necessary certificates (for example, {SMProductName}), or can be used directly by customer software.
 
 [id="zero-trust-traffic-authentication-and-encryption"]
 == Traffic authentication and encryption
@@ -30,9 +30,9 @@ Ensure that all traffic on the wire is encrypted and the endpoints are identifia
 
 Leverage:
 
-* {product-title}: With transparent xref:../networking/network_security/configuring-ipsec-ovn.adoc#configuring-ipsec-ovn-pod-to-pod-ipsec[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Provides powerful xref:../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[mTLS capabilities] that can transparently augment traffic leaving a pod to provide authentication and encryption.
-* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Use custom resource definitions (CRDs) to request certificates that can be mounted for your programs to use for SSL/TLS protocols.
+* {product-title}: With transparent xref:../../networking/network_security/configuring-ipsec-ovn.adoc#configuring-ipsec-ovn-pod-to-pod-ipsec[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Provides powerful xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[mTLS capabilities] that can transparently augment traffic leaving a pod to provide authentication and encryption.
+* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Use custom resource definitions (CRDs) to request certificates that can be mounted for your programs to use for SSL/TLS protocols.
 
 [id="zero-trust-identification-and-authentication"]
 == Identification and authentication
@@ -41,10 +41,10 @@ After you have the ability to mint certificates using a CA, you can use it to es
 
 Leverage:
 
-* {product-title}: Cluster-signed xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service certificates] to ensure that a client is talking to a trusted endpoint. This requires that the service uses SSL/TLS and that the client uses the xref:../security/certificates/service-serving-certificate.adoc#add-service-certificate-configmap_service-serving-certificate[cluster CA]. The client identity must be provided using some other means.
-* xref:../security/container_security/security-platform.adoc#security-platform-red-hat-sso_security-platform[Red Hat Single Sign-On]: Provides request authentication integration with enterprise user directories or third-party identity providers.
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: xref:../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture[Transparent upgrade] of connections to mTLS, auto-rotation, custom certificate expiration, and request authentication with JSON web token (JWT).
-* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Creation and management of certificates for use by your application. Certificates can be controlled by CRDs and mounted as secrets, or your application can be changed to interact directly with the cert-manager API.
+* {product-title}: Cluster-signed xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[service certificates] to ensure that a client is talking to a trusted endpoint. This requires that the service uses SSL/TLS and that the client uses the xref:../../security/certificates/service-serving-certificate.adoc#add-service-certificate-configmap_service-serving-certificate[cluster CA]. The client identity must be provided using some other means.
+* xref:../../security/container_security/security-platform.adoc#security-platform-red-hat-sso_security-platform[Red Hat Single Sign-On]: Provides request authentication integration with enterprise user directories or third-party identity providers.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture[Transparent upgrade] of connections to mTLS, auto-rotation, custom certificate expiration, and request authentication with JSON web token (JWT).
+* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Creation and management of certificates for use by your application. Certificates can be controlled by CRDs and mounted as secrets, or your application can be changed to interact directly with the cert-manager API.
 
 [id="zero-trust-inter-service-authorization"]
 == Inter-service authorization
@@ -53,8 +53,8 @@ It is critical to be able to control access to services based on the identity of
 
 Leverage:
 
-* {product-title}: Can enforce isolation in the networking layer of the platform using the Kubernetes xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[`NetworkPolicy`] and xref:../networking/network_security/AdminNetworkPolicy/ovn-k-anp.adoc#ovn-k-anp[`AdminNetworkPolicy`] objects.
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Sophisticated L4 and L7 xref:../service_mesh/v2x/ossm-security.adoc#ossm-security[control of traffic] using standard Istio objects and using mTLS to identify the source and destination of traffic and then apply policies based on that information.
+* {product-title}: Can enforce isolation in the networking layer of the platform using the Kubernetes xref:../../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[`NetworkPolicy`] and xref:../../networking/network_security/AdminNetworkPolicy/ovn-k-anp.adoc#ovn-k-anp[`AdminNetworkPolicy`] objects.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Sophisticated L4 and L7 xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security[control of traffic] using standard Istio objects and using mTLS to identify the source and destination of traffic and then apply policies based on that information.
 
 [id="zero-trust-transaction-level-verification"]
 == Transaction-level verification
@@ -63,7 +63,7 @@ In addition to the ability to identify and authenticate connections, it is also
 
 Leverage:
 
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Perform L7 inspection of requests, rejecting malformed HTTP requests, transaction-level xref:../service_mesh/v2x/ossm-architecture.adoc#understanding-kiali[observability and reporting]. {SMProductShortName} can also provide xref:../service_mesh/v2x/ossm-security.adoc#restrict-access-with-json-web-token[request-based authentication] using JWT.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Perform L7 inspection of requests, rejecting malformed HTTP requests, transaction-level xref:../../service_mesh/v2x/ossm-architecture.adoc#understanding-kiali[observability and reporting]. {SMProductShortName} can also provide xref:../../service_mesh/v2x/ossm-security.adoc#restrict-access-with-json-web-token[request-based authentication] using JWT.
 
 [id="zero-trust-risk-assessment"]
 == Risk assessment
@@ -72,7 +72,7 @@ As the number of security policies in a cluster increase, visualization of what
 
 Leverage:
 
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Create and visualize Kubernetes `NetworkPolicy` and `AdminNetworkPolicy`, and OpenShift Networking `EgressFirewall` objects using the xref:../web_console/web-console-overview.adoc#web-console-overview[OpenShift web console].
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Create and visualize Kubernetes `NetworkPolicy` and `AdminNetworkPolicy`, and OpenShift Networking `EgressFirewall` objects using the xref:../../web_console/web-console-overview.adoc#web-console-overview[OpenShift web console].
 * link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]: Advanced link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_security_for_kubernetes/4.3/html/operating/index[visualization of objects].
 
 [id="zero-trust-sitewide-policy-enforcement-and-distribution"]
@@ -82,7 +82,7 @@ After deploying applications on a cluster, it becomes challenging to manage all
 
 Leverage:
 
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: RBAC to xref:../security/container_security/security-platform.adoc#security-platform-multi-tenancy_security-platform[control policy object]s and delegate control.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: RBAC to xref:../../security/container_security/security-platform.adoc#security-platform-multi-tenancy_security-platform[control policy object]s and delegate control.
 * link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]: link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_security_for_kubernetes/4.1/html/operating/manage-security-policies#doc-wrapper[Policy enforcement] engine.
 * link:https://www.redhat.com/en/technologies/management/advanced-cluster-management[{rh-rhacm-first} for Kubernetes]: Centralized policy control.
 
@@ -93,10 +93,10 @@ After you have a running cluster, you want to be able to observe the traffic and
 
 Leverage:
 
-* xref:../observability/network_observability/installing-operators.adoc#installing-network-observability-operators[Network Observability Operator]: Allows for inspection, monitoring, and alerting on network connections to pods and nodes in the cluster.
+* xref:../../observability/network_observability/installing-operators.adoc#installing-network-observability-operators[Network Observability Operator]: Allows for inspection, monitoring, and alerting on network connections to pods and nodes in the cluster.
 * link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[{rh-rhacm-first} for Kubernetes]: Monitors, collects, and evaluates system-level events such as process execution, network connections and flows, and privilege escalation. It can determine a baseline for a cluster, and then detect anomalous activity and alert you about it.
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can xref:../service_mesh/v2x/ossm-architecture.adoc#ossm-kiali-overview_ossm-architecture[monitor traffic] entering and leaving a pod.
-* xref:../service_mesh/v2x/ossm-architecture.adoc#understanding-distributed-tracing[{DTProductName}]: For suitably instrumented applications, you can see all traffic associated with a particular action as it splits into sub-requests to microservices. This allows you to identify bottlenecks within a distributed application.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-kiali-overview_ossm-architecture[monitor traffic] entering and leaving a pod.
+* xref:../../service_mesh/v2x/ossm-architecture.adoc#understanding-distributed-tracing[{DTProductName}]: For suitably instrumented applications, you can see all traffic associated with a particular action as it splits into sub-requests to microservices. This allows you to identify bottlenecks within a distributed application.
 
 [id="zero-trust-endpoint-security"]
 == Endpoint security
@@ -105,7 +105,7 @@ It is important to be able to trust that the software running the services in yo
 
 Leverage:
 
-* {product-title}: Secureboot can ensure that the nodes in the cluster are running trusted software, so the platform itself (including the container runtime) have not been tampered with. You can configure {product-title} to only run images that have been xref:../security/container_security/security-container-signature.adoc#security-container-signature[signed by certain signatures].
+* {product-title}: Secureboot can ensure that the nodes in the cluster are running trusted software, so the platform itself (including the container runtime) have not been tampered with. You can configure {product-title} to only run images that have been xref:../../security/container_security/security-container-signature.adoc#security-container-signature[signed by certain signatures].
 * link:https://catalog.redhat.com/software/container-stacks/detail/6525b71aa53de2eb01ac9628[Red Hat Trusted Artifact Signer]: This can be used in a trusted build chain and produce signed container images.
 
 [id="extending-trust-outside-the-cluster"]
@@ -115,5 +115,5 @@ You might want to extend trust outside of the cluster by allowing a cluster to m
 
 Leverage:
 
-* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: You can use cert-manager to manage delegated CAs so that you can distribute trust across different clusters, or through your organization.
-* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can use SPIFFE to provide remote attestation of workloads to endpoints running in remote or local clusters.
+* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: You can use cert-manager to manage delegated CAs so that you can distribute trust across different clusters, or through your organization.
+* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can use SPIFFE to provide remote attestation of workloads to endpoints running in remote or local clusters.
diff --git a/networking/networking_operators/aws-load-balancer-operator.adoc b/networking/networking_operators/aws-load-balancer-operator.adoc
index c408d888b5b3..5fe77cdd55e3 100644
--- a/networking/networking_operators/aws-load-balancer-operator.adoc
+++ b/networking/networking_operators/aws-load-balancer-operator.adoc
@@ -1,38 +1,39 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="aws-load-balancer"]
 = AWS Load Balancer Operator
-include::_attributes/common-attributes.adoc[]
+include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: aws-load-balancer-operator
 
 toc::[]
 
 The AWS Load Balancer Operator is an Operator supported by Red{nbsp}Hat that users can optionally install on SRE-managed {product-title} (ROSA) clusters. The AWS Load Balancer Operator manages the lifecycle of the AWS Load Balancer Controller that provisions AWS Elastic Load Balancing v2 (ELBv2) services for applications running in ROSA clusters.
 
-// Creating an AWS IAM role by using the Cloud Credential Operator utility
-include::modules/using-ccoctl-create-iam-role-alb-operator.adoc[leveloffset=+1]
+[TIP]
+====
+Load Balancers created by the AWS Load Balancer Operator cannot be used for xref:../../networking/routes/route-configuration.adoc#route-configuration[OpenShift Routes], and should only be used for individual services or ingress resources that do not need the full layer 7 capabilities of an OpenShift Route.
+====
 
-// Creating an AWS IAM role for the controller by using the Cloud Credential Operator utility
-include::modules/using-ccoctl-create-iam-role-alb-controller.adoc[leveloffset=+1]
+The link:https://kubernetes-sigs.github.io/aws-load-balancer-controller/[AWS Load Balancer Controller] manages AWS Elastic Load Balancers for a {product-title} (ROSA) cluster. The controller provisions link:https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html[AWS Application Load Balancers (ALB)] when you create Kubernetes Ingress resources and link:https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html[AWS Network Load Balancers (NLB)] when implementing Kubernetes Service resources with a type of LoadBalancer.
 
-// Installing an AWS Load Balancer Operator
-include::modules/aws-installing-an-aws-load-balancer-operator.adoc[leveloffset=+1]
+Compared with the default AWS in-tree load balancer provider, this controller is developed with advanced annotations for both ALBs and NLBs. Some advanced use cases are:
 
-[role="_additional-resources"]
-.Additional resources
+* Using native Kubernetes Ingress objects with ALBs
+* Integrate ALBs with the AWS Web Application Firewall (WAF) service
+* Specify custom NLB source IP ranges
+* Specify custom NLB internal IP addresses
 
-* For more information about assigning trust policies to AWS IAM roles, see link:https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/[How to use trust policies with IAM roles].
+The link:https://github.com/openshift/aws-load-balancer-operator[AWS Load Balancer Operator] is used to used to install, manage and configure an instance of `aws-load-balancer-controller` in a ROSA cluster.
 
-* For more information about creating AWS IAM roles, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html[Creating IAM roles].
+include::modules/albo-prerequisites.adoc[leveloffset=+1]
 
-* For more information on adding AWS IAM permissions to AWS IAM roles, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html[Adding and removing IAM identity permissions].
+[role="additional_resources"]
 
-* For more information about formatting credentials files, see link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/authentication_and_authorization/managing-cloud-provider-credentials#cco-mode-sts[Using manual mode with Amazon Web Services Security Token Service].
+ifndef::openshift-rosa-hcp[]
+* To set up a ROSA classic cluster with multiple availability zones, see xref:../../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Creating a ROSA cluster with STS using the default options]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* To set up a ROSA classic cluster with multiple availability zones, see link:https://docs.redhat.com/rosa-hcp/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html[A multi-AZ ROSA cluster]
+endif::openshift-rosa-hcp[]
 
-* For more information regarding AWS Load Balancer Controllers configurations, link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/networking/aws-load-balancer-operator-1#nw-multiple-ingress-through-single-alb[Creating multiple ingresses] and link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/networking/aws-load-balancer-operator-1#nw-adding-tls-termination_adding-tls-termination[Adding TLS termination]
-
-* For more information on adding tags to AWS resources, including VPCs and subnets, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html[Tag your Amazon EC2 resources].
-
-* For detailed instructions on verifying that the ELBv2 was created for the application running in the ROSA cluster, see link:https://docs.openshift.com/container-platform/4.13/networking/aws_load_balancer_operator/create-instance-aws-load-balancer-controller.html[Creating an instance of AWS Load Balancer Controller].
-
-// Uninstalling an AWS Load Balancer Operator
-include::modules/aws-uninstalling-an-aws-load-balancer-operator.adoc[leveloffset=+1]
\ No newline at end of file
+include::modules/albo-installation.adoc[leveloffset=+1]
+include::modules/albo-deleting.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/networking/networking_operators/cluster-network-operator.adoc b/networking/networking_operators/cluster-network-operator.adoc
index 23fde6f94163..6db590236d2d 100644
--- a/networking/networking_operators/cluster-network-operator.adoc
+++ b/networking/networking_operators/cluster-network-operator.adoc
@@ -25,3 +25,5 @@ include::modules/nw-operator-cr.adoc[leveloffset=+1]
 == Additional resources
 * xref:../../rest_api/operator_apis/network-operator-openshift-io-v1.adoc#network-operator-openshift-io-v1[`Network` API in the `operator.openshift.io` API group]
 * xref:../../networking/configuring-cluster-network-range.adoc#nw-cluster-network-range-edit_configuring-cluster-network-range[Expanding the cluster network IP address range]
+
+* link:https://access.redhat.com/solutions/6969174[How to configure OVN to use kernel routing table]
\ No newline at end of file
diff --git a/networking/networking_operators/ingress-node-firewall-operator.adoc b/networking/networking_operators/ingress-node-firewall-operator.adoc
index 06727c73a96b..2b6608aa413c 100644
--- a/networking/networking_operators/ingress-node-firewall-operator.adoc
+++ b/networking/networking_operators/ingress-node-firewall-operator.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The Ingress Node Firewall Operator allows administrators to manage firewall configurations at the node level.
+The Ingress Node Firewall Operator provides a stateless, eBPF-based firewall for managing node-level ingress traffic in {product-title}.
 
 include::modules/nw-infw-operator-cr.adoc[leveloffset=+1]
 
diff --git a/networking/networking_operators/ingress-operator.adoc b/networking/networking_operators/ingress-operator.adoc
index 53fa5da80856..0b96a105b353 100644
--- a/networking/networking_operators/ingress-operator.adoc
+++ b/networking/networking_operators/ingress-operator.adoc
@@ -62,7 +62,7 @@ ifndef::openshift-rosa,openshift-dedicated[]
 
 * xref:../../nodes/cma/nodes-cma-autoscaling-custom-install.adoc#nodes-cma-autoscaling-custom-install_nodes-cma-autoscaling-custom-install[Installing the custom metrics autoscaler]
 
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
 
 * xref:../../nodes/cma/nodes-cma-autoscaling-custom-trigger-auth.adoc#nodes-cma-autoscaling-custom-trigger-auth[Understanding custom metrics autoscaler trigger authentications]
 
@@ -97,6 +97,7 @@ include::modules/nw-ingress-set-or-delete-http-headers.adoc[leveloffset=+2]
 
 include::modules/nw-using-ingress-forwarded.adoc[leveloffset=+2]
 
+// Enable or disable HTTP/2 on Ingress Controllers
 include::modules/nw-http2-haproxy.adoc[leveloffset=+2]
 
 // Configuring the PROXY protocol for an Ingress Controller
diff --git a/networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc b/networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc
index 2fbf7b567398..2e0c05073412 100644
--- a/networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc
+++ b/networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc
@@ -41,12 +41,15 @@ You can install the Kubernetes NMState Operator by using the web console or the
 // Installing the Kubernetes NMState Operator by using the web console
 include::modules/k8s-nmstate-installing-the-kubernetes-nmstate-operator.adoc[leveloffset=+2]
 
-// Installing the Kubernetes NMState Operator using the CLI
+// Installing the Kubernetes NMState Operator by using the CLI
 include::modules/k8s-nmstate-deploying-nmstate-CLI.adoc[leveloffset=+2]
 
 // Viewing statistics collected by the Kubernetes NMState Operator
 include::modules/viewing-stats-collected-kubernetes-nmtate-op.adoc[leveloffset=+2]
 
+// Uninstalling the Kubernetes NMState Operator
+include::modules/k8s-nmstate-uninstall-operator.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 [id="additional-resources_k8s-nmstate-view-stats_{context}"]
 == Additional resources
diff --git a/networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc b/networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc
index db67049c50f9..d6f2931d182c 100644
--- a/networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc
+++ b/networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc
@@ -8,20 +8,23 @@ toc::[]
 
 The Single Root I/O Virtualization (SR-IOV) Network Operator manages the SR-IOV network devices and network attachments in your cluster.
 
+// Configuring the SR-IOV Network Operator
 include::modules/nw-sriov-configuring-operator.adoc[leveloffset=+1]
 
+// Deploying the SR-IOV Operator for HCP
 include::modules/sriov-operator-hosted-control-planes.adoc[leveloffset=+2]
 
+// About the SR-IOV network metrics exporter
 include::modules/sriov-network-metrics-exporter.adoc[leveloffset=+1]
 
+// Enabling the SR-IOV network metrics exporter
 include::modules/sriov-operator-metrics.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../../observability/monitoring/managing-metrics.adoc#about-querying-metrics_managing-metrics[Querying metrics]
-* xref:../../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-all-projects-as-an-administrator_managing-metrics[Querying metrics for all projects as a cluster administrator]
-* xref:../../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-user-defined-projects-as-a-developer_managing-metrics[Querying metrics for user-defined projects as a developer]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#querying-metrics-for-all-projects-with-mon-dashboard_accessing-metrics-as-an-administrator[Querying metrics for all projects with the monitoring dashboard]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#querying-metrics-for-user-defined-projects-with-mon-dashboard_accessing-metrics-as-a-developer[Querying metrics for user-defined projects as a developer]
 
 [id="configuring-sriov-operator-next-steps"]
 == Next steps
diff --git a/networking/ovn_kubernetes_network_provider/configure-ovn-kubernetes-subnets.adoc b/networking/ovn_kubernetes_network_provider/configure-ovn-kubernetes-subnets.adoc
index 20786a4192a2..97d7bc772b68 100644
--- a/networking/ovn_kubernetes_network_provider/configure-ovn-kubernetes-subnets.adoc
+++ b/networking/ovn_kubernetes_network_provider/configure-ovn-kubernetes-subnets.adoc
@@ -9,9 +9,12 @@ toc::[]
 [role="_abstract"]
 As a cluster administrator, you can change the IP address ranges that the OVN-Kubernetes network plugin uses for the join and transit subnets.
 
+// Configuring the OVN-Kubernetes join subnet
 include::modules/nw-ovn-kubernetes-change-join-subnet.adoc[leveloffset=+1]
 
-//day 2 operation for changing masquerade subnet in ovn-k
+// Configuring the OVN-Kubernetes masquerade subnet as a post-installation operation
 include::modules/nw-ovn-k-day-2-masq-subnet.adoc[leveloffset=+1]
 
+// Configuring the OVN-Kubernetes transit subnet
 include::modules/nw-ovn-kubernetes-change-transit-subnet.adoc[leveloffset=+1]
+
diff --git a/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc b/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc
index c1d63bb96edb..8195b6f3e7b0 100644
--- a/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc
+++ b/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc
@@ -9,14 +9,23 @@ toc::[]
 
 As a cluster administrator, you can configure the OVN-Kubernetes Container Network Interface (CNI) network plugin to assign one or more egress IP addresses to a namespace, or to specific pods in a namespace.
 
+[IMPORTANT]
+====
+Configuring egress IPs is not supported for {hcp-title} clusters at this time. 
+====
+
+// Egress IP address architectural design and implementation
 include::modules/nw-egress-ips-about.adoc[leveloffset=+1]
 
+// EgressIP object
 include::modules/nw-egress-ips-object.adoc[leveloffset=+1]
 
 ifndef::openshift-rosa[]
+// The egressIPConfig object
 include::modules/nw-egress-ips-config-object.adoc[leveloffset=+1]
 endif::openshift-rosa[]
 
+// Labeling a node to host egress IP addresses
 include::modules/nw-egress-ips-node.adoc[leveloffset=+1]
 
 [id="configuring-egress-ips-next-steps"]
diff --git a/networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc b/networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
index 212fb9a80d5d..bb997d25bff1 100644
--- a/networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
+++ b/networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
@@ -8,8 +8,10 @@ toc::[]
 
 As a cluster administrator, you can configure egress traffic for pods behind a load balancer service by using an egress service.
 
-:FeatureName: Egress service
-include::snippets/technology-preview.adoc[]
+[NOTE]
+====
+To configure an egress service for pods behind a load balancer service, you must configure OVN-Kubernetes with the `gatewayConfig.routingViaHost` specification set to `true`. For more information about this configuration, see xref:../../networking/networking_operators/cluster-network-operator.adoc#nw-operator-cr-cno-object_cluster-network-operator[Cluster Network Operator configuration object] in _Networking Operators_.
+====
 
 You can use the `EgressService` custom resource (CR) to manage egress traffic in the following ways:
 
diff --git a/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn-osd.adoc b/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn-osd.adoc
new file mode 100644
index 000000000000..3624498acffd
--- /dev/null
+++ b/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn-osd.adoc
@@ -0,0 +1,24 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="migrate-from-openshift-sdn-osd"]
+= Migrating from OpenShift SDN network plugin to OVN-Kubernetes network plugin
+include::_attributes/common-attributes.adoc[]
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: migrate-from-openshift-sdn-osd
+
+toc::[]
+
+As an {product-title} cluster administrator, you can initiate the migration from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin and verify the migration status using the OCM CLI.
+
+Some considerations before starting migration initiation are:
+
+* The cluster version must be 4.16.24 and above.
+* The migration process cannot be interrupted.
+* Migrating back to the SDN network plugin is not possible.
+* Cluster nodes will be rebooted during migration.
+* There will be no impact to workloads that are resilient to node disruptions.
+* Migration time can vary between several minutes and hours, depending on the cluster size and workload configurations.
+
+include::modules/migrate-sdn-ovn-osd.adoc[leveloffset=+1]
+
+.Additional resources
+* link:https://docs.openshift.com/container-platform/4.16/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.html#patching-ovnk-address-ranges_migrate-from-openshift-sdn[Patching OVN-Kubernetes address ranges]
\ No newline at end of file
diff --git a/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc b/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc
new file mode 100644
index 000000000000..7a319d49d9e5
--- /dev/null
+++ b/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc
@@ -0,0 +1,30 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="migrate-from-openshift-sdn"]
+= Migrating from OpenShift SDN network plugin to OVN-Kubernetes network plugin
+include::_attributes/common-attributes.adoc[]
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: migrate-from-openshift-sdn
+
+toc::[]
+
+As a {rosa-classic-first} cluster administrator, you can initiate the migration from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin and verify the migration status using the ROSA CLI.
+
+Some considerations before starting migration initiation are:
+
+* The cluster version must be 4.16.24 and above.
+
+* The migration process cannot be interrupted.
+
+* Migrating back to the SDN network plugin is not possible.
+
+* Cluster nodes will be rebooted during migration.
+
+* There will be no impact to workloads that are resilient to node disruptions.
+
+* Migration time can vary between several minutes and hours, depending on the cluster size and workload configurations.
+
+include::modules/migrate-sdn-ovn.adoc[leveloffset=+1]
+
+
+
+
diff --git a/networking/ptp/configuring-ptp.adoc b/networking/ptp/configuring-ptp.adoc
index 88e2d37d62ca..de8b960e4ee6 100644
--- a/networking/ptp/configuring-ptp.adoc
+++ b/networking/ptp/configuring-ptp.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="configuring-ptp"]
-= Configuring Precision Time Protocol devices
+= Configuring PTP devices
 include::_attributes/common-attributes.adoc[]
 :context: configuring-ptp
 
@@ -30,7 +30,7 @@ include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
+* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
 
 include::modules/nw-ptp-grandmaster-clock-configuration-reference.adoc[leveloffset=+2]
 
@@ -56,7 +56,7 @@ include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[lev
 
 * xref:../../networking/ptp/configuring-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_configuring-ptp[Configuring FIFO priority scheduling for PTP hardware]
 
-* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
+* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
 
 include::modules/ptp-configuring-linuxptp-services-as-boundary-clock-dual-nic.adoc[leveloffset=+2]
 
@@ -69,7 +69,7 @@ include::modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc[lev
 
 * xref:../../networking/ptp/configuring-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_configuring-ptp[Configuring FIFO priority scheduling for PTP hardware]
 
-* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
+* xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher]
 
 include::modules/nw-columbiaville-ptp-config-refererence.adoc[leveloffset=+2]
 
diff --git a/networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc b/networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc
index e483b1084ccf..5e99fc562003 100644
--- a/networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc
+++ b/networking/ptp/ptp-cloud-events-consumer-dev-reference-v2.adoc
@@ -50,6 +50,6 @@ include::modules/cnf-monitoring-fast-events-metrics.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
+* xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#accessing-metrics-as-a-developer[Accessing metrics as a developer]
 
 include::modules/nw-ptp-operator-metrics-reference.adoc[leveloffset=+1]
diff --git a/networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc b/networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc
deleted file mode 100644
index 0855cf1ecf1d..000000000000
--- a/networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc
+++ /dev/null
@@ -1,58 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:ptp-events-rest-api: v1
-[id="ptp-cloud-events-consumer-dev-reference-{ptp-events-rest-api}"]
-= Developing PTP events consumer applications with the REST API {ptp-events-rest-api}
-include::_attributes/common-attributes.adoc[]
-:context: ptp-consumer
-
-toc::[]
-
-When developing consumer applications that make use of Precision Time Protocol (PTP) events on a bare-metal cluster node, you deploy your consumer application in a separate application pod.
-The consumer application subscribes to PTP events by using the PTP events REST API {ptp-events-rest-api}.
-
-[NOTE]
-====
-The following information provides general guidance for developing consumer applications that use PTP events.
-A complete events consumer application example is outside the scope of this information.
-====
-
-:FeatureName: PTP events REST API v1 and events consumer application sidecar
-include::snippets/deprecated-feature.adoc[]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#ptp-events-rest-api-reference[PTP events REST API v1 reference]
-
-include::modules/cnf-about-ptp-fast-event-notifications-framework.adoc[leveloffset=+1]
-
-include::modules/cnf-about-ptp-events-consumer-sidecar-and-http-transport.adoc[leveloffset=+1]
-
-include::modules/cnf-configuring-the-ptp-fast-event-publisher.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For a complete example CR that configures `linuxptp` services as an ordinary clock with PTP fast events, see xref:../../networking/ptp/configuring-ptp.adoc#configuring-linuxptp-services-as-ordinary-clock_configuring-ptp[Configuring linuxptp services as ordinary clock].
-
-include::modules/ptp-events-consumer-application.adoc[leveloffset=+1]
-
-include::modules/ptp-reference-deployment-and-service-crs.adoc[leveloffset=+1]
-
-include::modules/ptp-subscribing-consumer-app-to-events.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#api-ocloud-notifications-v1-subscriptions_using-ptp-hardware-fast-events-framework-v1[api/ocloudNotifications/v1/subscriptions]
-
-include::modules/ptp-verifying-events-consumer-app-is-receiving-events.adoc[leveloffset=+1]
-
-include::modules/cnf-monitoring-fast-events-metrics.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
-
-include::modules/nw-ptp-operator-metrics-reference.adoc[leveloffset=+1]
diff --git a/networking/ptp/ptp-events-rest-api-reference-v2.adoc b/networking/ptp/ptp-events-rest-api-reference-v2.adoc
index c7a0421230e9..2d73e1bc3b0a 100644
--- a/networking/ptp/ptp-events-rest-api-reference-v2.adoc
+++ b/networking/ptp/ptp-events-rest-api-reference-v2.adoc
@@ -1,12 +1,12 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="ptp-events-rest-api-reference-v2"]
-= Precision Time Protocol events REST API v2 reference
+= PTP events REST API v2 reference
 include::_attributes/common-attributes.adoc[]
 :context: using-ptp-hardware-fast-events-framework-v2
 
 toc::[]
 
-Use the following REST API v2 endpoints to subscribe the `cloud-event-consumer` application to Precision Time Protocol (PTP) events posted at `\http://localhost:9043/api/ocloudNotifications/v2` in the PTP events producer pod.
+Use the following REST API v2 endpoints to subscribe the `cloud-event-consumer` application to Precision Time Protocol (PTP) events posted at `\http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2` in the PTP events producer pod.
 
 * xref:../../networking/ptp/ptp-events-rest-api-reference-v2.adoc#api-ocloud-notifications-v2-subscriptions_{context}[`api/ocloudNotifications/v2/subscriptions`]
 ** `POST`: Creates a new subscription
diff --git a/networking/ptp/ptp-events-rest-api-reference.adoc b/networking/ptp/ptp-events-rest-api-reference.adoc
deleted file mode 100644
index e68e5002faf9..000000000000
--- a/networking/ptp/ptp-events-rest-api-reference.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="ptp-events-rest-api-reference"]
-= Precision Time Protocol events REST API v1 reference
-include::_attributes/common-attributes.adoc[]
-:context: using-ptp-hardware-fast-events-framework-v1
-
-toc::[]
-
-Use the following Precision Time Protocol (PTP) fast event REST API v1 endpoints to subscribe the `cloud-event-consumer` application to PTP events posted by the `cloud-event-proxy` container at [x-]`http://localhost:8089/api/ocloudNotifications/v1/` in the application pod.
-
-:FeatureName: PTP events REST API v1 and events consumer application sidecar
-include::snippets/deprecated-feature.adoc[]
-
-The following API endpoints are available:
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#api-ocloud-notifications-v1-subscriptions_{context}[`api/ocloudNotifications/v1/subscriptions`]
-** `POST`: Creates a new subscription
-** `GET`: Retrieves a list of subscriptions
-** `DELETE`: Deletes all subscriptions
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#api-ocloud-notifications-v1-subscriptions-subscription_id_{context}[`api/ocloudNotifications/v1/subscriptions/{subscription_id}`]
-** `GET`: Returns details for the specified subscription ID
-** `DELETE`: Deletes the subscription associated with the specified subscription ID
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#api-ocloudnotifications-v1-health_{context}[`api/ocloudNotifications/v1/health`]
-** `GET`: Returns the health status of `ocloudNotifications` API
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#api-ocloudnotifications-v1-publishers_{context}[`api/ocloudNotifications/v1/publishers`]
-** `GET`: Returns a list of PTP event publishers for the cluster node
-
-* xref:../../networking/ptp/ptp-events-rest-api-reference.adoc#resource-address-current-state_{context}[`api/ocloudnotifications/v1/{resource_address}/CurrentState`]
-** `GET`: Returns the current state of one the following event types: `sync-state`, `os-clock-sync-state`, `clock-class`, `lock-state`, or `gnss-sync-status` events
-
-include::modules/cnf-fast-event-notifications-api-reference.adoc[leveloffset=+1]
diff --git a/networking/routes/route-configuration.adoc b/networking/routes/route-configuration.adoc
index b73971b87187..991f129446d1 100644
--- a/networking/routes/route-configuration.adoc
+++ b/networking/routes/route-configuration.adoc
@@ -26,6 +26,11 @@ include::modules/nw-enabling-hsts.adoc[leveloffset=+1]
 //Enabling HTTP strict transport security per-route
 include::modules/nw-enabling-hsts-per-route.adoc[leveloffset=+2]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../networking/networking_operators/ingress-operator.adoc#nw-http2-haproxy_configuring-ingress[Enabling HTTP/2 Ingress connectivity]
+
 //Disabling HTTP strict transport security per-route
 include::modules/nw-disabling-hsts.adoc[leveloffset=+2]
 
diff --git a/networking/understanding-networking.adoc b/networking/understanding-networking.adoc
index b1b505c15b7b..1e9376b41000 100644
--- a/networking/understanding-networking.adoc
+++ b/networking/understanding-networking.adoc
@@ -5,24 +5,84 @@ include::_attributes/common-attributes.adoc[]
 :context: understanding-networking
 
 toc::[]
-Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections:
 
-* Service types, such as node ports or load balancers
+Understanding the fundamentals of networking in {product-title} ensures efficient and secure communication within your clusters and is essential for effective network administration. Key elements of networking in your environment include understanding how pods and services communicate, the role of IP addresses, and the use of DNS for service discovery. 
 
-* API resources, such as `Ingress` and `Route`
+// Introduction
+include::modules/nw-understanding-networking-networking-in-OpenShift.adoc[leveloffset=+1]
 
-By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can network, but clients outside the cluster do not have networking access. When you expose your application to external traffic, giving each pod its own IP address means that pods can be treated like physical hosts or virtual machines in terms of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
+include::modules/nw-understanding-networking-common-practices.adoc[leveloffset=+2]
 
-[NOTE]
-====
-Some cloud platforms offer metadata APIs that listen on the 169.254.169.254 IP address, a link-local IP address in the IPv4 `169.254.0.0/16` CIDR block.
+include::modules/nw-understanding-networking-features.adoc[leveloffset=+2]
 
-This CIDR block is not reachable from the pod network. Pods that need access to these IP addresses must be given host network access by setting the `spec.hostNetwork` field in the pod spec to `true`.
+// Nodes, clusters, clients
+include::modules/nw-understanding-networking-nodes-clients-clusters.adoc[leveloffset=+1]
 
-If you allow a pod host network access, you grant the pod privileged access to the underlying network infrastructure.
-====
+include::modules/nw-understanding-networking-what-is-a-node.adoc[leveloffset=+2]
 
-include::modules/nw-ne-openshift-dns.adoc[leveloffset=+1]
-include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1]
-include::modules/nw-ne-comparing-ingress-route.adoc[leveloffset=+2]
-include::modules/nw-networking-glossary-terms.adoc[leveloffset=+1]
+include::modules/nw-understanding-networking-what-is-a-cluster.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-what-is-a-client.adoc[leveloffset=+2]
+
+// Concepts and components
+include::modules/nw-understanding-networking-concepts-components.adoc[leveloffset=+1]
+
+include::modules/nw-ne-changes-externalip-ovn.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[About network policy]
+
+//Pod communication
+include::modules/nw-understanding-networking-how-pods-communicate.adoc[leveloffset=+1]
+
+include::modules/nw-understanding-networking-pod-to-pod.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-pod-to-pod-example.adoc[leveloffset=+3]
+
+include::modules/nw-understanding-networking-service-to-pod.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-service-to-pod-example.adoc[leveloffset=+3]
+
+//Load balancing
+
+include::modules/nw-load-balancing-about.adoc[leveloffset=+1]
+
+include::modules/nw-load-balancing-configure.adoc[leveloffset=+2]
+
+include::modules/nw-load-balancing-configure-define-type.adoc[leveloffset=+3]
+
+include::modules/nw-load-balancing-configure-specify-behavior.adoc[leveloffset=+3]
+
+//DNS
+include::modules/nw-understanding-networking-dns.adoc[leveloffset=+1]
+
+include::modules/nw-understanding-networking-dns-terms.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-dns-example.adoc[leveloffset=+2]
+
+//Controls
+include::modules/nw-understanding-networking-controls.adoc[leveloffset=+1]
+
+//Routes and Ingress
+include::modules/nw-understanding-networking-routes-ingress.adoc[leveloffset=+1]
+
+include::modules/nw-understanding-networking-routes.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-ingress.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-routes-vs-ingress.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-routes-ingress-example.adoc[leveloffset=+2]
+
+// Security
+include::modules/nw-understanding-networking-security.adoc[leveloffset=+1]
+
+include::modules/nw-understanding-networking-exposing-applications.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-securing-connections.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-security-example.adoc[leveloffset=+2]
+
+include::modules/nw-understanding-networking-choosing-service-types.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/nodes/clusters/nodes-cluster-overcommit.adoc b/nodes/clusters/nodes-cluster-overcommit.adoc
index 28e4529cc049..556177ad6ec6 100644
--- a/nodes/clusters/nodes-cluster-overcommit.adoc
+++ b/nodes/clusters/nodes-cluster-overcommit.adoc
@@ -21,10 +21,8 @@ resource requests and nodes' available capacity into consideration.
 
 ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 {product-title} administrators can control the level of overcommit and manage
-container density on nodes. You can configure cluster-level overcommit using
-the xref:#nodes-cluster-resource-override_nodes-cluster-overcommit[ClusterResourceOverride Operator]
-to override the ratio between requests and limits set on developer containers.
-In conjunction with xref:#nodes-cluster-node-overcommit_nodes-cluster-overcommit[node overcommit], you can adjust the resource limit and request to achieve the desired level of overcommit.
+container density on developer containers by using
+the xref:#nodes-cluster-resource-override_nodes-cluster-overcommit[ClusterResourceOverride Operator].
 
 [NOTE]
 ====
@@ -111,6 +109,6 @@ ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../nodes/clusters/nodes-cluster-limit-ranges.adoc#nodes-cluster-limit-ranges[Restrict resource consumption with limit ranges]
 endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // TODO: Add this xref to ROSA HCP when the Support book is added.
-ifndef::openshift-rosa-hcp,openshift-enterprise[]
-* xref:../../support/troubleshooting/sd-managed-resources.adoc#sd-managed-resources[Red Hat Managed resources]
-endif::openshift-rosa-hcp,openshift-enterprise[]
+ifndef::openshift-rosa-hcp,openshift-enterprise,openshift-dedicated[]
+* xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#sd-managed-resources-overview_sd-managed-resources[Red Hat Managed resources]
+endif::openshift-rosa-hcp,openshift-enterprise,openshift-dedicated[]
diff --git a/nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc b/nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc
index fcb05f5911f9..fc7393a796ce 100644
--- a/nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc
+++ b/nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc
@@ -10,7 +10,7 @@ toc::[]
 
 Triggers, also known as scalers, provide the metrics that the Custom Metrics Autoscaler Operator uses to scale your pods.
 
-The custom metrics autoscaler currently supports only the Prometheus, CPU, memory, and Apache Kafka triggers.
+The custom metrics autoscaler currently supports the Prometheus, CPU, memory, Apache Kafka, and cron triggers.
 
 You use a `ScaledObject` or `ScaledJob` custom resource to configure triggers for specific objects, as described in the sections that follow.
 
@@ -23,8 +23,12 @@ You can configure a certificate authority xref:../../nodes/cma/nodes-cma-autosca
 
 include::modules/nodes-cma-autoscaling-custom-trigger-prom.adoc[leveloffset=+1]
 include::modules/nodes-cma-autoscaling-custom-prometheus-config.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../nodes/cma/nodes-cma-autoscaling-custom-trigger-auth.adoc#nodes-cma-autoscaling-custom-trigger-auth[Understanding custom metrics autoscaler trigger authentications]
+
 include::modules/nodes-cma-autoscaling-custom-trigger-cpu.adoc[leveloffset=+1]
 include::modules/nodes-cma-autoscaling-custom-trigger-memory.adoc[leveloffset=+1]
 include::modules/nodes-cma-autoscaling-custom-trigger-kafka.adoc[leveloffset=+1]
 include::modules/nodes-cma-autoscaling-custom-trigger-cron.adoc[leveloffset=+1]
-
diff --git a/nodes/containers/nodes-containers-sysctls.adoc b/nodes/containers/nodes-containers-sysctls.adoc
index 985ebf140068..7a6aa493ae0f 100644
--- a/nodes/containers/nodes-containers-sysctls.adoc
+++ b/nodes/containers/nodes-containers-sysctls.adoc
@@ -17,7 +17,7 @@ Moreover, only those sysctls considered _safe_ are whitelisted by default; you
 can manually enable other _unsafe_ sysctls on the node to be available to the
 user.
 
-If you are setting the sysctl and it is not node-level, you can find information on this procedure in the section xref:../../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator].
+If you are setting the sysctl and it is node-level, you can find information on this procedure in the section xref:../../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator].
 
 // The following include statements pull in the module files that comprise
 // the assembly. Include any combination of concept, procedure, or reference
diff --git a/nodes/index.adoc b/nodes/index.adoc
index 48abd5295586..c9dd4335a78e 100644
--- a/nodes/index.adoc
+++ b/nodes/index.adoc
@@ -37,6 +37,10 @@ ifndef::openshift-rosa-hcp[]
 image::295_OpenShift_Nodes_Overview_1222.png[Overview of control plane and worker node]
 endif::openshift-rosa-hcp[]
 
+ifdef::openshift-rosa-hcp[]
+image::ROSA-HCP-overview-of-nodes-487.png[Overview of control plane and worker node]
+endif::openshift-rosa-hcp[]
+
 [discrete]
 === Read operations
 
@@ -46,7 +50,7 @@ The read operations allow an administrator or a developer to get information abo
 * Get information about a node, such as memory and CPU usage, health, status, and age.
 * xref:../nodes/nodes/nodes-nodes-viewing.adoc#nodes-nodes-viewing-listing-pods_nodes-nodes-viewing[List pods running on a node].
 
-ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifndef::openshift-enterprise,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [discrete]
 === Management operations
 
@@ -60,7 +64,7 @@ through several tasks:
 * xref:../nodes/nodes/nodes-nodes-managing-max-pods.adoc#nodes-nodes-managing-max-pods-proc_nodes-nodes-managing-max-pods[Configure the number of pods that can run on a node] based on the number of processor cores on the node, a hard limit, or both.
 * Reboot a node gracefully using xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-affinity_nodes-nodes-rebooting[pod anti-affinity].
 * xref:../nodes/nodes/nodes-nodes-working.adoc#deleting-nodes[Delete a node from a cluster] by scaling down the cluster using a compute machine set. To delete a node from a bare-metal cluster, you must first drain all pods on the node and then manually delete the node.
-endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+endif::openshift-enterprise,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [discrete]
 === Enhancement operations
@@ -68,7 +72,6 @@ endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 {product-title} allows you to do more than just access and manage nodes; as an administrator, you can perform the following tasks on nodes to make the cluster more efficient, application-friendly, and to provide a better environment for your developers.
 
 * Manage node-level tuning for high-performance applications that require some level of kernel tuning by xref:../nodes/nodes/nodes-node-tuning-operator.adoc#nodes-node-tuning-operator[using the Node Tuning Operator].
-* xref:../nodes/jobs/nodes-pods-daemonsets.adoc#nodes-pods-daemonsets[Run background tasks on nodes automatically with daemon sets]. You can create and use daemon sets to create shared storage, run a logging pod on every node, or deploy a monitoring agent on all nodes.
 ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Enable TLS security profiles on the node to protect communication between the kubelet and the Kubernetes API server.
 endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
@@ -92,6 +95,7 @@ As an administrator, you can get information about pods in a project through the
 * xref:../nodes/pods/nodes-pods-viewing.adoc#nodes-pods-viewing-project_nodes-pods-viewing[List pods associated with a project], including information such as the number of replicas and restarts, current status, and age.
 * xref:../nodes/pods/nodes-pods-viewing.adoc#nodes-pods-viewing-usage_nodes-pods-viewing[View pod usage statistics] such as CPU, memory, and storage consumption.
 
+
 [discrete]
 === Management operations
 
@@ -141,7 +145,6 @@ As a developer, use a vertical pod autoscaler to ensure your pods stay up during
 |Administrator
 |Some applications need sensitive information, such as passwords and usernames. You can use the `Secret` object to provide such information to an application pod.
 
-
 |===
 endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
@@ -214,12 +217,12 @@ garbage collection::
 The process of cleaning up cluster resources, such as terminated containers and images that are not referenced by any running pods.
 
 //cannot create the required namespace for these operators
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [discrete]
 [id="commonterms-node-hpa"]
 Horizontal Pod Autoscaler(HPA)::
 Implemented as a Kubernetes API resource and a controller. You can use the HPA to specify the minimum and maximum number of pods that you want to run. You can also specify the CPU or memory utilization that your pods should target. The HPA scales out and scales in pods when a given CPU or memory threshold is crossed.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [discrete]
 [id="commonterms-node-ingress"]
@@ -265,4 +268,4 @@ Indicates that the pod is allowed (but not required) to be scheduled on nodes or
 [discrete]
 [id="commonterms-node-taint"]
 Taint::
-A core object that comprises a key,value, and effect. Taints and tolerations work together to ensure that pods are not scheduled on irrelevant nodes.
+A core object that comprises a key, value, and effect. Taints and tolerations work together to ensure that pods are not scheduled on irrelevant nodes.
\ No newline at end of file
diff --git a/nodes/nodes-sigstore-using.adoc b/nodes/nodes-sigstore-using.adoc
index fac9b8354169..6c53189b6c02 100644
--- a/nodes/nodes-sigstore-using.adoc
+++ b/nodes/nodes-sigstore-using.adoc
@@ -6,12 +6,29 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can use the sigstore project with {product-title} to improve supply chain security.
+You can use link:https://www.sigstore.dev/[sigstore] with {product-title} to improve supply chain security.
+
+:FeatureName: sigstore support
+include::snippets/technology-preview.adoc[]
 
 // The following include statements pull in the module files that comprise
 // the assembly. Include any combination of concept, procedure, or reference
 // modules required to cover the user story. You can also include other
 // assemblies.
 
-// AManage secure signatures with SigStore
-include::modules/nodes-sigstore-using-about.adoc[leveloffset=+1]
\ No newline at end of file
+// Manage secure signatures with SigStore
+include::modules/nodes-sigstore-using-about.adoc[leveloffset=+1]
+include::modules/nodes-sigstore-configure.adoc[leveloffset=+1]
+include::modules/nodes-sigstore-configure-cluster-policy.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+xref:../nodes/nodes-sigstore-using.adoc#nodes-sigstore-configure-parameters_nodes-sigstore-using[About cluster and image policy parameters]
+
+include::modules/nodes-sigstore-configure-image-policy.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+xref:../nodes/nodes-sigstore-using.adoc#nodes-sigstore-configure-parameters_nodes-sigstore-using[About cluster and image policy parameters]
+
diff --git a/nodes/nodes/nodes-nodes-adding-node-iso.adoc b/nodes/nodes/nodes-nodes-adding-node-iso.adoc
index 2943fdd85a18..a4d7839e2b36 100644
--- a/nodes/nodes/nodes-nodes-adding-node-iso.adoc
+++ b/nodes/nodes/nodes-nodes-adding-node-iso.adoc
@@ -12,6 +12,11 @@ This process can be used regardless of how you installed your cluster.
 You can add one or more nodes at a time while customizing each node with more complex configurations, such as static network configuration, or you can specify only the MAC address of each node.
 Any required configurations that are not specified during ISO generation are retrieved from the target cluster and applied to the new nodes.
 
+[NOTE]
+====
+`Machine` or `BareMetalHost` resources are not automatically created after a node has been successfully added to the cluster.
+====
+
 Preflight validation checks are also performed when booting the ISO image to inform you of failure-causing issues before you attempt to boot each node.
 
 [id="supported-platforms_{context}"]
@@ -24,6 +29,16 @@ The following platforms are supported for this method of adding nodes:
 * `none`
 * `external`
 
+[id="supported-architectures_{context}"]
+== Supported architectures
+
+The following architecture combinations have been validated to work when adding worker nodes using this process:
+
+* `amd64` worker nodes on `amd64` or `arm64` clusters
+* `arm64` worker nodes on `amd64` or `arm64` clusters
+* `s390x` worker nodes on `s390x` clusters
+* `ppc64le` worker nodes on `ppc64le` clusters
+
 [id="adding-nodes-cluster_{context}"]
 == Adding nodes to your cluster
 You can add nodes with this method in the following two ways:
diff --git a/nodes/nodes/nodes-nodes-resources-configuring.adoc b/nodes/nodes/nodes-nodes-resources-configuring.adoc
index dd274cbbe7ef..30863891e674 100644
--- a/nodes/nodes/nodes-nodes-resources-configuring.adoc
+++ b/nodes/nodes/nodes-nodes-resources-configuring.adoc
@@ -20,6 +20,16 @@ To manually set resource values, you must use a kubelet config CR. You cannot us
 
 include::modules/nodes-nodes-resources-configuring-about.adoc[leveloffset=+1]
 
+include::modules/sd-understanding-process-id-limits.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../machine_configuration/machine-configs-custom.adoc#create-a-kubeletconfig-crd-to-edit-kubelet-parameters_machine-configs-custom[Creating a KubeletConfig CR to edit kubelet parameters]
+* xref:../../nodes/nodes/nodes-nodes-resources-configuring.adoc#nodes-nodes-resources-configuring[Allocating resources for nodes in an {product-title} cluster]
+
+include::modules/risks-setting-higher-process-id-limits.adoc[leveloffset=+2]
+
 include::modules/nodes-nodes-resources-configuring-auto.adoc[leveloffset=+1]
 
 include::modules/nodes-nodes-resources-configuring-setting.adoc[leveloffset=+1]
diff --git a/nodes/pods/nodes-pods-vertical-autoscaler.adoc b/nodes/pods/nodes-pods-vertical-autoscaler.adoc
index 6a6f1b5b9264..833660361ca3 100644
--- a/nodes/pods/nodes-pods-vertical-autoscaler.adoc
+++ b/nodes/pods/nodes-pods-vertical-autoscaler.adoc
@@ -8,7 +8,17 @@ toc::[]
 
 
 
-The {product-title} Vertical Pod Autoscaler Operator (VPA) automatically reviews the historic and current CPU and memory resources for containers in pods and can update the resource limits and requests based on the usage values it learns. The VPA uses individual custom resources (CR) to update all of the pods associated with a workload object, such as a `Deployment`, `DeploymentConfig`, `StatefulSet`, `Job`, `DaemonSet`, `ReplicaSet`, or `ReplicationController`, in a project.
+The {product-title} Vertical Pod Autoscaler Operator (VPA) automatically reviews the historic and current CPU and memory resources for containers in pods and can update the resource limits and requests based on the usage values it learns. The VPA uses individual custom resources (CR) to update all of the pods in a project that are associated with any built-in workload objects, including the following object types: 
+
+* `Deployment`
+* `DeploymentConfig`
+* `StatefulSet`
+* `Job`
+* `DaemonSet`
+* `ReplicaSet`
+* `ReplicationController`
+
+The VPA can also update certain custom resource object that manage pods, as described in xref:../../nodes/pods/nodes-pods-vertical-autoscaler.adoc#nodes-pods-vertical-autoscaler-custom-resource_nodes-pods-vertical-autoscaler[Using the Vertical Pod Autoscaler Operator with Custom Resources].
 
 The VPA helps you to understand the optimal CPU and memory usage for your pods and can automatically maintain pod resources through the pod lifecycle.
 
@@ -36,4 +46,6 @@ include::modules/nodes-pods-vertical-autoscaler-custom.adoc[leveloffset=+2]
 
 include::modules/nodes-pods-vertical-autoscaler-configuring.adoc[leveloffset=+1]
 
+include::modules/nodes-pods-vertical-autoscaler-custom-resource.adoc[leveloffset=+2]
+
 include::modules/nodes-pods-vertical-autoscaler-uninstall.adoc[leveloffset=+1]
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
index 3d42e9836c31..4715e2dc49ff 100644
--- a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+++ b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
@@ -6,24 +6,28 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
-include::snippets/technology-preview.adoc[leveloffset=+2]
 
-The {coo-first} is an optional component of the {product-title}. You can deploy it to create standalone monitoring stacks that are independently configurable for use by different services and users.
+The {coo-first} is an optional component of the {product-title} designed for creating and managing highly customizable monitoring stacks. It enables cluster administrators to automate configuration and management of monitoring needs extensively, offering a more tailored and detailed view of each namespace compared to the default {product-title} monitoring system.
 
 The {coo-short} deploys the following monitoring components:
 
-* Prometheus
-* Thanos Querier (optional)
-* Alertmanager (optional)
+* **Prometheus** - A highly available Prometheus instance capable of sending metrics to an external endpoint by using remote write.
+* **Thanos Querier** (optional) - Enables querying of Prometheus instances from a central location.
+* **Alertmanager** (optional) - Provides alert configuration capabilities for different services.
+* **UI plugins** (optional) - Enhances the observability capabilities with plugins for monitoring, logging, distributed tracing and troubleshooting.
+* **Korrel8r** (optional) - Provides observability signal correlation, powered by the open source Korrel8r project.
 
-The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the {cmo-first}.
-Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the {cmo-short}.
+include::modules/coo-versus-default-ocp-monitoring.adoc[leveloffset=+1]
 
-include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
+include::modules/coo-advantages.adoc[leveloffset=+1]
+
+include::modules/coo-target-users.adoc[leveloffset=+1]
+
+//include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
+
+include::modules/coo-server-side-apply.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
 * link:https://kubernetes.io/docs/reference/using-api/server-side-apply/[Kubernetes documentation for Server-Side Apply (SSA)]
-
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc b/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
index 19f661ec9678..b39b54d0ec58 100644
--- a/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
+++ b/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
@@ -7,24 +7,120 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
-include::snippets/technology-preview.adoc[leveloffset=+2]
-
 The {coo-first} is an optional {product-title} Operator that enables administrators to create standalone monitoring stacks that are independently configurable for use by different services and users.
 
 The {coo-short} complements the built-in monitoring capabilities of {product-title}. You can deploy it in parallel with the default platform and user workload monitoring stacks managed by the {cmo-first}.
 
 These release notes track the development of the {coo-full} in {product-title}.
 
+
+[id="cluster-observability-operator-release-notes-1-1_{context}"]
+== {coo-full} 1.1
+
+// Back fill advisory when it is created by KOnflux
+// The following advisory is available for {coo-full} 1.1:
+//
+// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.1]
+
+
+[id="cluster-observability-operator-1-1-new-features-enhancements_{context}"]
+=== New features and enhancements
+ 
+* You can now install the monitoring UI plugin using {coo-short}. (link:https://issues.redhat.com/browse/COO-262[*COO-262*])
+
+* You can enable incident detection in the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-690[*COO-690*])
+
+* TLS support for the Thanos web endpoint has been added. (link:https://issues.redhat.com/browse/COO-222[*COO-222*])
+
+The following table provides information about which features are available depending on the version of {coo-full} and {product-title}:
+
+[cols="1,1,1,1,1,1,1", options="header"]
+|===
+| COO Version   | OCP Versions       | Distributed tracing   | Logging   | Troubleshooting panel | ACM alerts | Incident detection
+| 1.1           | 4.12 - 4.14        | ✔                     | ✔         | ✘                     | ✘          | ✘
+| 1.1           | 4.15               | ✔                     | ✔         | ✘                     | ✔          | ✘
+| 1.1           | 4.16 - 4.17        | ✔                     | ✔         | ✔                     | ✔          | ✘
+| 1.1           | 4.18+              | ✔                     | ✔         | ✔                     | ✔          | ✔
+|===
+
+
+[id="cluster-observability-operator-1-1-bug-fixes_{context}"]
+=== Bug fixes
+
+* Previously, the logging UI plugin did not support setting a custom LokiStack name or namespace. This release resolves the issue. (link:https://issues.redhat.com/browse/COO-332[*COO-332*])
+
+
+[id="cluster-observability-operator-release-notes-1-0_{context}"]
+== {coo-full} 1.0
+
+// Need to check if there is an advisory generated now that the build system has moved to Konflux
+// The following advisory is available for {coo-full} 1.0:
+//
+// * link:https://access.redhat.com/errata/RHSA-2024:????[RHEA-2024:??? {coo-full} 1.0]
+
+
+[id="cluster-observability-operator-1-0-new-features-enhancements_{context}"]
+=== New features and enhancements
+
+* {coo-short} is now enabled for {product-title} platform monitoring. (link:https://issues.redhat.com/browse/COO-476[*COO-476*])
+** Implements HTTPS support for {coo-short} web server. (link:https://issues.redhat.com/browse/COO-480[*COO-480*])
+** Implements authn/authz for {coo-short} web server. (link:https://issues.redhat.com/browse/COO-481[*COO-481*])
+** Configures ServiceMonitor resource to collect metrics from {coo-short}. (link:https://issues.redhat.com/browse/COO-482[*COO-482*])
+** Adds `operatorframework.io/cluster-monitoring=true` annotation to the OLM bundle. (link:https://issues.redhat.com/browse/COO-483[*COO-483*])
+** Defines the alerting strategy for {coo-short} . (link:https://issues.redhat.com/browse/COO-484[*COO-484*])
+** Configures PrometheusRule for alerting. (link:https://issues.redhat.com/browse/COO-485[*COO-485*])
+
+* Support level annotations have been added to the `UIPlugin` CR when created. The support level is based on the plugin type, with values of `DevPreview`, `TechPreview`, or `GeneralAvailability`. (link:https://issues.redhat.com/browse/COO-318[*COO-318*])
+
+// must-gather postponed to 1.1
+//* You can now gather debugging information about {coo-short} by using the `oc adm must-gather` CLI command. (link:https://issues.redhat.com/browse/COO-194[*COO-194*])
+
+* You can now configure the Alertmanager `scheme` and `tlsConfig` fields in the Prometheus CR. (link:https://issues.redhat.com/browse/COO-219[*COO-219*])
+
+// Dev preview so cannot document 
+//* You can now install the Monitoring UI plugin using {coo-short}. (link:https://issues.redhat.com/browse/COO-262[*COO-262*])
+
+* The extended Technical Preview for the troubleshooting panel adds support for correlating traces with Kubernetes resources and directly with other observable signals including logs, alerts, metrics, and network events. (link:https://issues.redhat.com/browse/COO-450[*COO-450*])
+** You can select a Tempo instance and tenant when you navigate to the tracing page by clicking *Observe -> Tracing* in the web console. The preview troubleshooting panel only works with the `openshift-tracing / platform` instance and the `platform` tenant.
+** The troubleshooting panel works best in the *Administrator* perspective. It has limited functionality in the Developer perspective due to authorization issues with some back ends, most notably Prometheus for metrics and alerts. This will be addressed in a future release.
+
 The following table provides information about which features are available depending on the version of {coo-full} and {product-title}:
 
+[cols="1,1,1,1,1", options="header"]
+|===
+| COO Version   | OCP Versions       | Distributed Tracing   | Logging   | Troubleshooting Panel
+| 1.0           | 4.12 - 4.15        | ✔                     | ✔         | ✘
+| 1.0           | 4.16+              | ✔                     | ✔         | ✔
+|===
+
+
+[id="cluster-observability-operator-1-0-CVEs"]
+=== CVEs
+
+* link:https://access.redhat.com/security/cve/CVE-2023-26159[CVE-2023-26159]
+* link:https://access.redhat.com/security/cve/CVE-2024-28849[CVE-2024-28849]
+* link:https://access.redhat.com/security/cve/CVE-2024-45338[CVE-2024-45338]
+
+[id="cluster-observability-operator-1-0-bug-fixes_{context}"]
+=== Bug fixes
+
+* Previously, the default namespace for the {coo-short}  installation was `openshift-operators`. With this release, the defaullt namespace changes to `openshift-cluster-observability-operator`. (link:https://issues.redhat.com/browse/COO-32[*COO-32*])
+
+* Previously, `korrel8r` was only able to parse time series selector expressions. With this release, `korrel8r` can parse any valid PromQL expression to extract the time series selectors that it uses for correlation. (link:https://issues.redhat.com/browse/COO-558[*COO-558*])
+
+* Previously, when viewing a Tempo instance from the Distributed Tracing UI plugin, the scatter plot graph showing the traces duration was not rendered correctly. The bubble size was too large and overlapped the x and y axis. With this release, the graph is rendered correctly. (link:https://issues.redhat.com/browse/COO-319[*COO-319*])
+
+== Features available on older, Technology Preview releases
+
+The following table provides information about which features are available depending on older version of {coo-full} and {product-title}:
+
 [cols="1,1,1,1,1,1", options="header"]
 |===
-| COO Version   | OCP Versions       | Dashboards   | Distributed Tracing   | Logging   | Troubleshooting Panel
+| COO Version    | OCP Versions       | Dashboards   | Distributed Tracing   | Logging   | Troubleshooting Panel
 
-| 0.2.0         | 4.11               | ✔            | ✘                     | ✘         | ✘ 
-| 0.3.0+        | 4.11 - 4.15        | ✔            | ✔                     | ✔         | ✘ 
-| 0.3.0+        | 4.16+              | ✔            | ✔                     | ✔         | ✔ 
+| 0.2.0          | 4.11               | ✔            | ✘                     | ✘         | ✘ 
+| 0.3.0+, 0.4.0+ | 4.11 - 4.15        | ✔            | ✔                     | ✔         | ✘ 
+| 0.3.0+, 0.4.0+ | 4.16+              | ✔            | ✔                     | ✔         | ✔ 
 |===
 
 [id="cluster-observability-operator-release-notes-0-4-1_{context}"]
diff --git a/observability/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc b/observability/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc
index ad91404bee2f..d7751c3586bb 100644
--- a/observability/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc
+++ b/observability/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc
@@ -6,9 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
-include::snippets/technology-preview.adoc[leveloffset=+2]
-
 You can monitor metrics for a service by configuring monitoring stacks managed by the {coo-first}.
 
 To test monitoring a service, follow these steps:
@@ -25,3 +22,7 @@ include::modules/monitoring-specifying-how-a-service-is-monitored-by-cluster-obs
 
 // Create a MonitoringStack object to discover the service monitor
 include::modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc[leveloffset=+1]
+
+// Validate a MonitoringStack 
+include::modules/monitoring-validating-a-monitoringstack-for-cluster-observability-operator.adoc[leveloffset=+1]
+
diff --git a/observability/cluster_observability_operator/installing-the-cluster-observability-operator.adoc b/observability/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
index 51fcae69e440..1aab682cec82 100644
--- a/observability/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
+++ b/observability/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
@@ -6,9 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
-include::snippets/technology-preview.adoc[leveloffset=+2]
-
 As a cluster administrator, you can install or remove the {coo-first} from OperatorHub by using the {product-title} web console.
 OperatorHub is a user interface that works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster.
 
diff --git a/observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc b/observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc
index 68fc00d8d947..6a6144982867 100644
--- a/observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc
+++ b/observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc
@@ -6,9 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
-include::snippets/technology-preview.adoc[leveloffset=+2]
-
 The dashboard UI plugin supports enhanced dashboards in the OpenShift web console at *Observe* -> *Dashboards* . You can add other Prometheus datasources from the cluster to the default dashboards, in addition to the in-cluster datasource. This results in a unified observability experience across different data sources.
 
 The plugin searches for datasources from `ConfigMap` resources in the `openshift-config-managed` namespace, that have the label `console.openshift.io/dashboard-datasource: 'true'`. 
diff --git a/observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc b/observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc
index f9804102e5f2..dd57008021ad 100644
--- a/observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc
+++ b/observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
+:FeatureName: The {coo-full} distributed tracing UI plugin
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
 The distributed tracing UI plugin adds tracing-related features to the Administrator perspective of the OpenShift web console at **Observe** → **Traces**. You can follow requests through the front end and into the backend of microservices, helping you identify code errors and performance bottlenecks in distributed systems. 
diff --git a/observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc b/observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc
index eea95c04e0f8..5e169c3dc702 100644
--- a/observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc
+++ b/observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc
@@ -6,11 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-[IMPORTANT]
-====
-Until the approaching General Availability (GA) release of the Cluster Observability Operator (COO), which is currently in link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview] (TP), Red{nbsp}Hat provides support to customers who are using Logging 6.0 or later with the COO for the logging UI plugin on {product-title} 4.14 or later. This support exception is temporary as the COO includes several independent features, some of which are still TP features, but the logging UI plugin is ready for GA.
-====
-
 The logging UI plugin surfaces logging data in the {product-title} web console on the *Observe* -> *Logs* page. 
 You can specify filters, queries, time ranges and refresh rates, with the results displayed as a list of collapsed logs, which can then be expanded to show more detailed information for each log.
 
diff --git a/observability/cluster_observability_operator/ui_plugins/monitoring-ui-plugin.adoc b/observability/cluster_observability_operator/ui_plugins/monitoring-ui-plugin.adoc
new file mode 100644
index 000000000000..414affa4726f
--- /dev/null
+++ b/observability/cluster_observability_operator/ui_plugins/monitoring-ui-plugin.adoc
@@ -0,0 +1,24 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="monitoring-ui-plugin"]
+= Monitoring UI plugin
+include::_attributes/common-attributes.adoc[]
+:context: monitoring-ui-plugin
+
+toc::[]
+
+:FeatureName: The {coo-full} monitoring UI plugin
+include::snippets/technology-preview.adoc[leveloffset=+2]
+
+The monitoring UI plugin adds monitoring features to the Administrator perspective of the OpenShift web console.
+
+* **{rh-rhacm}:** The monitoring plugin in {coo-first} allows it to function in {rh-rhacm-first} environments, providing {rh-rhacm} with the same alerting capabilities as {product-title}. You can configure the plugin to fetch alerts from the {rh-rhacm} Alertmanager backend. This enables seamless integration and user experience by aligning {rh-rhacm} and {product-title} monitoring workflows.
+
+* **Incident detection:** The incident detection feature groups related alerts into incidents, to help you identify the root causes of alert bursts, instead of being overwhelmed by individual alerts. It presents a timeline of incidents, color-coded by severity, and you can drill down into the individual alerts within an incident. The system also categorizes alerts by affected component, grouped by severity. This helps you focus on the most critical areas first.
++
+The incident detection feature is available in the Administrator perspective of the OpenShift web console at **Observe** → **Incidents**. 
+
+include::modules/coo-monitoring-ui-plugin-install.adoc[leveloffset=+1]
+
+include::modules/coo-incident-detection-overview.adoc[leveloffset=+1]
+
+include::modules/coo-incident-detection-using.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/observability/cluster_observability_operator/ui_plugins/observability-ui-plugins-overview.adoc b/observability/cluster_observability_operator/ui_plugins/observability-ui-plugins-overview.adoc
index 706cc34cdf6c..d69e4216464d 100644
--- a/observability/cluster_observability_operator/ui_plugins/observability-ui-plugins-overview.adoc
+++ b/observability/cluster_observability_operator/ui_plugins/observability-ui-plugins-overview.adoc
@@ -6,24 +6,34 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {coo-full}
-include::snippets/technology-preview.adoc[leveloffset=+2]
-
 You can use the {coo-first} to install and manage UI plugins to enhance the observability capabilities of the {product-title} web console.
-The plugins extend the default functionality, providing new UI features for monitoring, troubleshooting, distributed tracing, and cluster logging.
+The plugins extend the default functionality, providing new UI features for troubleshooting, distributed tracing, and cluster logging.
 
-[id="dashboards_{context}"]
-== Dashboards
+[id="monitoring_{context}"]
+== Monitoring
 
-The dashboard UI plugin supports enhanced dashboards in the {product-title} web console at *Observe* -> *Dashboards*.
-You can add other Prometheus data sources from the cluster to the default dashboards, in addition to the in-cluster data source.
-This results in a unified observability experience across different data sources.
+The monitoring UI plugin adds monitoring related UI features to the OpenShift web console, for the Advance Cluster Management (ACM) perspective and for incident detection.
+
+* **ACM:** The monitoring plugin in {coo-first} allows it to function in {rh-rhacm-first} environments, providing ACM with the same monitoring capabilities as {product-title}.
 
-For more information, see the xref:../../../observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc#dashboard-ui-plugin[dashboard UI plugin] page.
+* **Incident Detection:** The incident detection feature groups alerts into incidents to help you identify the root causes of alert bursts instead of being overwhelmed by individual alerts. It presents a timeline of incidents, color-coded by severity, and you can drill down into the individual alerts within an incident. The system also categorizes alerts by affected component to help you focus on the most critical areas first.
+
+For more information, see the xref:../../../observability/cluster_observability_operator/ui_plugins/monitoring-ui-plugin.adoc#monitoring-ui-plugin[monitoring UI plugin] page.
+
+[id="cluster-logging_{context}"]
+== Cluster logging
+
+The logging UI plugin surfaces logging data in the web console on the  *Observe* -> *Logs* page. 
+You can specify filters, queries, time ranges and refresh rates. The results displayed a list of collapsed logs, which can then be expanded to show more detailed information for each log.
+
+For more information, see the xref:../../../observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc#logging-ui-plugin[logging UI plugin] page.
 
 [id="troubleshooting_{context}"]
 == Troubleshooting
 
+:FeatureName: The {coo-full} troubleshooting panel UI plugin
+include::snippets/technology-preview.adoc[leveloffset=+2]
+
 The troubleshooting panel UI plugin for {product-title} version 4.16+ provides observability signal correlation, powered by the open source Korrel8r project.
 You can use the troubleshooting panel available from the *Observe* -> *Alerting* page to easily correlate metrics, logs, alerts, netflows, and additional observability signals and resources, across different data stores.
 Users of {product-title} version 4.17+ can also access the troubleshooting UI panel from the Application Launcher {launch}.
@@ -35,17 +45,23 @@ For more information, see the xref:../../../observability/cluster_observability_
 [id="distributed-tracing_{context}"]
 == Distributed tracing
 
+:FeatureName: The {coo-full} distributed tracing UI plugin
+include::snippets/technology-preview.adoc[leveloffset=+2]
+
 The distributed tracing UI plugin adds tracing-related features to the web console on the *Observe* -> *Traces* page.
 You can follow requests through the front end and into the backend of microservices, helping you identify code errors and performance bottlenecks in distributed systems.
 You can select a supported `TempoStack` or `TempoMonolithic` multi-tenant instance running in the cluster and set a time range and query to view the trace data.
 
 For more information, see the xref:../../../observability/cluster_observability_operator/ui_plugins/distributed-tracing-ui-plugin.adoc#distributed-tracing-ui-plugin[distributed tracing UI plugin] page.
 
+////
+[id="dashboards_{context}"]
+== Dashboards
 
-[id="cluster-logging_{context}"]
-== Cluster logging
+The dashboard UI plugin supports enhanced dashboards in the {product-title} web console at *Observe* -> *Dashboards*.
+You can add other Prometheus data sources from the cluster to the default dashboards, in addition to the in-cluster data source.
+This results in a unified observability experience across different data sources.
 
-The logging UI plugin surfaces logging data in the web console on the  *Observe* -> *Logs* page. 
-You can specify filters, queries, time ranges and refresh rates. The results displayed a list of collapsed logs, which can then be expanded to show more detailed information for each log.
+For more information, see the xref :../../../observability/cluster_observability_operator/ui_plugins/dashboard-ui-plugin.adoc#dashboard-ui-plugin[dashboard UI plugin] page.
 
-For more information, see the xref:../../../observability/cluster_observability_operator/ui_plugins/logging-ui-plugin.adoc#logging-ui-plugin[logging UI plugin] page.
+////
diff --git a/observability/cluster_observability_operator/ui_plugins/troubleshooting-ui-plugin.adoc b/observability/cluster_observability_operator/ui_plugins/troubleshooting-ui-plugin.adoc
index 7905602a4acc..12706dbc78a7 100644
--- a/observability/cluster_observability_operator/ui_plugins/troubleshooting-ui-plugin.adoc
+++ b/observability/cluster_observability_operator/ui_plugins/troubleshooting-ui-plugin.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The Cluster Observability Operator
+:FeatureName: The {coo-full} troubleshooting panel UI plugin
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
 The troubleshooting UI plugin for {product-title} version 4.16+ provides observability signal correlation, powered by the open source Korrel8r project.
diff --git a/observability/distr_tracing/distr-tracing-rn.adoc b/observability/distr_tracing/distr-tracing-rn.adoc
index c82bb1d6ce02..d4551d216a06 100644
--- a/observability/distr_tracing/distr-tracing-rn.adoc
+++ b/observability/distr_tracing/distr-tracing-rn.adoc
@@ -12,6 +12,120 @@ You can use the {TempoName} xref:../../observability/otel/otel-forwarding-teleme
 
 include::snippets/distr-tracing-and-otel-disclaimer-about-docs-for-supported-features-only.adoc[]
 
+[id="distr-tracing_3-5_{context}"]
+== Release notes for {DTProductName} 3.5
+
+This release of the {DTProductName} includes the {TempoName} and the deprecated {JaegerName}.
+
+////
+[id="distr-tracing_3-5_cves_{context}"]
+=== CVEs
+
+This release fixes the following CVEs:
+
+* ???
+////
+
+[id="distr-tracing_3-5_tempo-release-notes_{context}"]
+=== {TempoName}
+
+The {TempoName} 3.5 is provided through the link:https://catalog.redhat.com/software/containers/rhosdt/tempo-operator-bundle/642c3e0eacf1b5bdbba7654a/history[{TempoOperator} 0.15.3].
+
+[NOTE]
+====
+The {TempoName} 3.5 is based on the open source link:https://grafana.com/oss/tempo/[Grafana Tempo] 2.7.1.
+====
+
+[id="distr-tracing_3-5_tempo-release-notes_new-features-and-enhancements_{context}"]
+==== New features and enhancements
+
+This update introduces the following enhancements:
+
+* With this update, you can configure the Tempo backend services to report the internal tracing data by using the OpenTelemetry Protocol (OTLP).
+* With this update, the `traces.span.metrics` namespace becomes the default metrics namespace on which the Jaeger query retrieves the Prometheus metrics. The purpose of this change is to provide compatibility with the OpenTelemetry Collector version 0.109.0 and later where this namespace is the default. Customers who are still using an earlier OpenTelemetry Collector version can configure this namespace by adding the following field and value: `spec.template.queryFrontend.jaegerQuery.monitorTab.redMetricsNamespace: ""`.
+
+[id="distr-tracing_3-5_tempo-release-notes_bug-fixes_{context}"]
+==== Bug fixes
+
+This update introduces the following bug fix:
+
+////
+* Before this update, the `oauth-proxy` container did not have any compute resources assigned to it. With this update, the container correctly sets the resources as specified in the `TempoStack` custom resource.
+////
+
+* Before this update, the {TempoOperator} failed when the `TempoStack` custom resource had the `spec.storage.tls.enabled` field set to `true` and used an Amazon S3 object store with the Security Token Service (STS) authentication. With this update, such a `TempoStack` custom resource configuration does not cause the {TempoOperator} to fail.
+
+[id="distr-tracing_3-5_jaeger-release-notes_{context}"]
+=== {JaegerName}
+
+The {JaegerName} 3.5 is the last release of the {JaegerName} that Red Hat plans to support.
+
+In the {DTProductName} 3.5, Jaeger and support for Elasticsearch remain deprecated.
+
+[WARNING]
+====
+Support for the {JaegerName} ends on November 3, 2025.
+
+The {JaegerOperator} Operator (Jaeger) will be removed from the `redhat-operators` catalog on November 3, 2025.
+====
+
+You must migrate to the {OTELName} Operator and the {TempoOperator} for distributed tracing collection and storage. For more information, see the following resources:
+
+* xref:../../observability/otel/otel-migrating.adoc#dist-tracing-otel-migrating[Migrating] ({OTELShortName} documentation)
+
+* xref:../../observability/otel/otel-installing.adoc#install-otel[Installing] ({OTELName} documentation)
+
+* xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[Installing] ({TempoShortName} documentation)
+
+* link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift] (Red Hat Knowledgebase solution)
+
+[NOTE]
+====
+The {JaegerName} 3.5 is based on the open source link:https://www.jaegertracing.io/[Jaeger] release 1.65.0.
+====
+// 1.62.0 was fixed until Jaeger's removal
+
+The {JaegerName} 3.5 is provided through the link:https://catalog.redhat.com/software/containers/rhosdt/jaeger-operator-bundle/613b50f3a052bb39f2c5f31e/history[{JaegerOperator} Operator 1.65.0].
+
+[IMPORTANT]
+====
+Jaeger does not use FIPS validated cryptographic modules.
+====
+
+[id="distr-tracing_3-5_jaeger-release-notes_support-for-elasticsearch-operator_{context}"]
+==== Support for the {es-op}
+
+The {JaegerName} 3.5 is supported for use with the {es-op} 5.6, 5.7, and 5.8.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift] (Red Hat Knowledgebase)
+* xref:../../observability/otel/otel-migrating.adoc#dist-tracing-otel-migrating[Migrating] ({OTELName} documentation)
+* xref:../../observability/otel/otel-installing.adoc#install-otel[Installing] ({OTELName} documentation)
+* xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[Installing] (Distributed tracing platform (Tempo) documentation)
+
+////
+[id="distr-tracing_3-5_jaeger-release-notes_bug-fixes_{context}"]
+==== Bug fixes
+
+This update introduces the following bug fix:
+
+* ???
+
+////
+
+[id="distr-tracing_3-5_jaeger-release-notes_known-issues_{context}"]
+==== Known issues
+
+There are currently known issues:
+
+* Currently, Apache Spark is not supported.
+
+ifndef::openshift-rosa[]
+
+* Currently, the streaming deployment via AMQ/Kafka is not supported on the {ibm-z-title} and {ibm-power-title} architectures.
+endif::openshift-rosa[]
+
 [id="distr-tracing_3-4_{context}"]
 == Release notes for {DTProductName} 3.4
 
@@ -106,7 +220,16 @@ The {JaegerName} 3.4 is supported for use with the {es-op} 5.6, 5.7, and 5.8.
 In the {DTProductName} 3.4, Jaeger and support for Elasticsearch remain deprecated, and both are planned to be removed in a future release.
 Red{nbsp}Hat will provide support for these components and fixes for CVEs and bugs with critical and higher severity during the current release lifecycle, but these components will no longer receive feature enhancements.
 
-The {JaegerOperator} Operator link:https://access.redhat.com/solutions/7083722[is planned to be removed] from the `redhat-operators` catalog in a future release. You must xref:../../observability/otel/otel-migrating.adoc#dist-tracing-otel-migrating[migrate] to the xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[{TempoOperator}] and the xref:../../observability/otel/otel-installing.adoc#install-otel[{OTELName}] for distributed tracing collection and storage.
+The {JaegerOperator} Operator (Jaeger) will be removed from the `redhat-operators` catalog in a future release. For more information, see the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift].
+
+You must migrate to the {OTELName} Operator and the {TempoOperator} for distributed tracing collection and storage. For more information, see xref:../../observability/otel/otel-migrating.adoc#dist-tracing-otel-migrating[Migrating] in the {OTELShortName} documentation, xref:../../observability/otel/otel-installing.adoc#install-otel[Installing] in the {OTELName} documentation, and xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[Installing] in the {TempoShortName} documentation.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift (Red Hat Knowledgebase)]
+* xref:../../observability/otel/otel-migrating.adoc#dist-tracing-otel-migrating[Migrating ({OTELName} documentation)]
+* xref:../../observability/otel/otel-installing.adoc#install-otel[Installing ({OTELName} documentation)]
+* xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[Installing (Distributed tracing platform (Tempo) documentation)]
 
 [id="distr-tracing_3-4_jaeger-release-notes_bug-fixes_{context}"]
 ==== Bug fixes
@@ -130,7 +253,7 @@ endif::openshift-rosa[]
 [id="distr-tracing_3-3-1_{context}"]
 == Release notes for {DTProductName} 3.3.1
 
-The {DTProductName} 3.3.1 is a maintenance release with no changes because the {DTProductName} is bundled with the {OTELName} that is xref:../otel/otel-rn.adoc#otel-rn[released] with a bug fix.
+The {DTProductName} 3.3.1 is a maintenance release with no changes because the {DTProductName} is bundled with the {OTELName} that is xref:../otel/otel-rn.adoc#otel_rn[released] with a bug fix.
 
 This release of the {DTProductName} includes the {TempoName} and the deprecated {JaegerName}.
 
@@ -223,12 +346,8 @@ The {JaegerName} 3.3.1 is supported for use with the {es-op} 5.6, 5.7, and 5.8.
 
 In the {DTProductName} 3.3.1, Jaeger and support for Elasticsearch remain deprecated, and both are planned to be removed in a future release.
 Red{nbsp}Hat will provide support for these components and fixes for CVEs and bugs with critical and higher severity during the current release lifecycle, but these components will no longer receive feature enhancements.
-The {TempoOperator} and the {OTELName} are the preferred Operators for distributed tracing collection and storage.
-Users must adopt the OpenTelemetry and Tempo distributed tracing stack because it is the stack to be enhanced going forward.
 
-In the {DTProductName} 3.3.1, the Jaeger agent is deprecated and planned to be removed in the following release.
-Red{nbsp}Hat will provide bug fixes and support for the Jaeger agent during the current release lifecycle, but the Jaeger agent will no longer receive enhancements and will be removed.
-The OpenTelemetry Collector provided by the {OTELName} is the preferred Operator for injecting the trace collector agent.
+The {JaegerOperator} Operator (Jaeger) link:https://access.redhat.com/solutions/7083722[will be removed] from the `redhat-operators` catalog in a future release. Users must xref:../otel/otel-migrating.adoc#dist-tracing-otel-migrating[migrate] to the xref:distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[{TempoOperator}] and the xref:../otel/otel-installing.adoc#install-otel[{OTELName}] for distributed tracing collection and storage.
 
 ////
 [id="distr-tracing_3-3-1_jaeger-release-notes_removal-notice_{context}"]
@@ -357,7 +476,7 @@ The {JaegerName} 3.3 is supported for use with the {es-op} 5.6, 5.7, and 5.8.
 In the {DTProductName} 3.3, Jaeger and support for Elasticsearch remain deprecated, and both are planned to be removed in a future release.
 Red{nbsp}Hat will provide support for these components and fixes for CVEs and bugs with critical and higher severity during the current release lifecycle, but these components will no longer receive feature enhancements.
 
-The {JaegerOperator} Operator link:https://access.redhat.com/solutions/7083722[will be removed] from the `redhat-operators` catalog in a future release. Users must xref:../otel/otel-migrating.adoc#dist-tracing-otel-migrating[migrate] to the xref:distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[{TempoOperator}] and the xref:../otel/otel-installing.adoc#install-otel[{OTELName}] for distributed tracing collection and storage.
+The {JaegerOperator} Operator (Jaeger) link:https://access.redhat.com/solutions/7083722[will be removed] from the `redhat-operators` catalog in a future release. Users must xref:../otel/otel-migrating.adoc#dist-tracing-otel-migrating[migrate] to the xref:distr_tracing_tempo/distr-tracing-tempo-installing.adoc#dist-tracing-tempo-installing[{TempoOperator}] and the xref:../otel/otel-installing.adoc#install-otel[{OTELName}] for distributed tracing collection and storage.
 
 ////
 [id="distr-tracing_3-3_jaeger-release-notes_removal-notice_{context}"]
diff --git a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc
index 2146d81d5e5f..8b69b3ac5347 100644
--- a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc
+++ b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {JaegerName}
-include::modules/deprecated-feature.adoc[]
+include::snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc[]
 
 The {JaegerName} Operator uses a custom resource definition (CRD) file that defines the architecture and configuration settings to be used when creating and deploying the {JaegerShortName} resources. You can install the default configuration or modify the file.
 
diff --git a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-installing.adoc b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-installing.adoc
index bdeeb981a596..0e6b667fdf37 100644
--- a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-installing.adoc
+++ b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-installing.adoc
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {JaegerName}
-include::modules/deprecated-feature.adoc[]
+include::snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc[]
 
 You can install {DTProductName} on {product-title} in either of two ways:
 
diff --git a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc
index 4275ed6f7dae..4a3d1f7d4a69 100644
--- a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc
+++ b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {JaegerName}
-include::modules/deprecated-feature.adoc[]
+include::snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc[]
 
 The steps for removing {DTProductName} from an {product-title} cluster are as follows:
 
diff --git a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-updating.adoc b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-updating.adoc
index 920aabaeb3d8..06da2f7add50 100644
--- a/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-updating.adoc
+++ b/observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-updating.adoc
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {JaegerName}
-include::modules/deprecated-feature.adoc[]
+include::snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc[]
 
 Operator Lifecycle Manager (OLM) controls the installation, upgrade, and role-based access control (RBAC) of Operators in a cluster. The OLM runs by default in {product-title}.
 OLM queries for available Operators as well as upgrades for installed Operators.
@@ -16,7 +15,7 @@ During an update, the {DTProductName} Operators upgrade the managed {DTShortName
 
 [IMPORTANT]
 ====
-If you have not already updated your {es-op} as described in xref:../../../observability/logging/cluster-logging-upgrading.adoc#cluster-logging-upgrading[Updating OpenShift Logging], complete that update before updating your {JaegerName} Operator.
+If you have not already updated your {es-op}, complete that update before updating your {JaegerName} Operator.
 ====
 
 [role="_additional-resources"]
@@ -25,4 +24,3 @@ If you have not already updated your {es-op} as described in xref:../../../obser
 
 * xref:../../../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Operator Lifecycle Manager concepts and resources]
 * xref:../../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators]
-* xref:../../../observability/logging/cluster-logging-upgrading.adoc#cluster-logging-upgrading[Updating OpenShift Logging]
diff --git a/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc b/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc
index 2d66a2dcf677..85ffc53b57c3 100644
--- a/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc
+++ b/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc
@@ -67,6 +67,6 @@ include::modules/distr-tracing-tempo-configuring-tempostack-metrics-and-alerts.a
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
 
 include::modules/distr-tracing-tempo-configuring-tempooperator-metrics-and-alerts.adoc[leveloffset=+2]
diff --git a/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc b/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc
index 15d7284a230b..7c87e7731734 100644
--- a/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc
+++ b/observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc
@@ -71,6 +71,16 @@ include::modules/distr-tracing-tempo-object-storage-setup-aws-sts-install.adoc[l
 * xref:../../../authentication/identity_providers/configuring-oidc-identity-provider.adoc#configuring-oidc-identity-provider[Configuring an OpenID Connect identity provider]
 * link:https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html[Identify AWS resources with Amazon Resource Names (ARNs)]
 
+include::modules/distr-tracing-tempo-object-storage-setup-ibm-storage.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#cli-getting-started[Getting started with the OpenShift CLI]
+* link:https://cloud.ibm.com/docs/cli?topic=cli-getting-started[Getting started with the {ibm-cloud-title} CLI] ({ibm-cloud-title} Docs)
+* link:https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-provision[Choosing a plan and creating an instance] ({ibm-cloud-title} Docs)
+* link:https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage&q=credential&tags=cloud-object-storage&offset=10#getting-started[Getting started with {ibm-cloud-title} Object Storage: Before you begin] ({ibm-cloud-title} Docs)
+
 [role="_additional-resources"]
 [id="additional-resources_dist-tracing-tempo-installing"]
 == Additional resources
diff --git a/observability/logging/cluster-logging.adoc b/observability/logging/cluster-logging.adoc
index ea791ff07bd8..49e3049e6fde 100644
--- a/observability/logging/cluster-logging.adoc
+++ b/observability/logging/cluster-logging.adoc
@@ -11,7 +11,7 @@ As a cluster administrator, you can deploy {logging} on an {product-title} clust
 
 include::snippets/logging-kibana-dep-snip.adoc[]
 
-{product-title} cluster administrators can deploy {logging} by using Operators. For information, see xref:../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing {logging}].
+{product-title} cluster administrators can deploy {logging} by using Operators. For information, see xref:../../observability/logging/cluster-logging-deploying.adoc#cluster-logging-deploying[Installing logging].
 
 The Operators are responsible for deploying, upgrading, and maintaining {logging}. After the Operators are installed, you can create a `ClusterLogging` custom resource (CR) to schedule {logging} pods and other resources necessary to support {logging}. You can also create a `ClusterLogForwarder` CR to specify which logs are collected, how they are transformed, and where they are forwarded to.
 
@@ -37,13 +37,13 @@ include::modules/cluster-logging-json-logging-about.adoc[leveloffset=+2]
 
 include::modules/cluster-logging-collecting-storing-kubernetes-events.adoc[leveloffset=+2]
 
-For information, see xref:../../observability/logging/log_collection_forwarding/cluster-logging-eventrouter.adoc#cluster-logging-eventrouter[About collecting and storing Kubernetes events].
+For information, see xref:../../observability/logging/log_collection_forwarding/cluster-logging-eventrouter.adoc#cluster-logging-eventrouter[Collecting and storing Kubernetes events].
 
 include::modules/cluster-logging-troubleshoot-logging.adoc[leveloffset=+2]
 
 include::modules/cluster-logging-export-fields.adoc[leveloffset=+2]
 
-For information, see xref:../../observability/logging/cluster-logging-exported-fields.adoc#cluster-logging-exported-fields[About exporting fields].
+For information, see xref:../../observability/logging/cluster-logging-exported-fields.adoc#cluster-logging-exported-fields[Log record fields].
 
 include::modules/cluster-logging-eventrouter-about.adoc[leveloffset=+2]
 
diff --git a/observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc b/observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc
index 456ccd3f1f4e..4547ddf00adf 100644
--- a/observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc
+++ b/observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc
@@ -72,6 +72,6 @@ endif::[]
 [role="_additional-resources"]
 .Additional resources
 * link:https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html[AWS STS API Reference]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[Cloud Credential Operator (CCO)]
-endif::[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/observability/logging/log_collection_forwarding/log-forwarding.adoc b/observability/logging/log_collection_forwarding/log-forwarding.adoc
index 277bdc6d8418..fa9bfdee0c9a 100644
--- a/observability/logging/log_collection_forwarding/log-forwarding.adoc
+++ b/observability/logging/log_collection_forwarding/log-forwarding.adoc
@@ -35,7 +35,7 @@ To use the multi log forwarder feature, you must create a service account and cl
 
 [IMPORTANT]
 ====
-In order to support multi log forwarding in additional namespaces other than the `openshift-logging` namespace, you must xref:../../../observability/logging/cluster-logging-upgrading.adoc#logging-operator-upgrading-all-ns_cluster-logging-upgrading[update the {clo} to watch all namespaces]. This functionality is supported by default in new {clo} version 5.8 installations.
+In order to support multi log forwarding in additional namespaces other than the `openshift-logging` namespace, you must update the {clo} to watch all namespaces]. This functionality is supported by default in new {clo} version 5.8 installations.
 ====
 
 include::modules/log-collection-rbac-permissions.adoc[leveloffset=+3]
diff --git a/observability/logging/log_visualization/log-visualization-ocp-console.adoc b/observability/logging/log_visualization/log-visualization-ocp-console.adoc
index 63fabcadc13f..b826e724ed3c 100644
--- a/observability/logging/log_visualization/log-visualization-ocp-console.adoc
+++ b/observability/logging/log_visualization/log-visualization-ocp-console.adoc
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 
 toc::[]
 
-You can use the {product-title} web console to visualize log data by configuring the {log-plug}. Options for configuration are available during installation of {logging} on the web console. 
+You can use the {product-title} web console to visualize log data by configuring the {log-plug}. Options for configuration are available during installation of {logging} on the web console.
 
 If you have already installed {logging} and want to configure the plugin, use one of the following procedures.
 
diff --git a/observability/logging/logging-6.0/log6x-about.adoc b/observability/logging/logging-6.0/log6x-about.adoc
index c6514c40d8bb..1f9b8acaa0af 100644
--- a/observability/logging/logging-6.0/log6x-about.adoc
+++ b/observability/logging/logging-6.0/log6x-about.adoc
@@ -34,14 +34,16 @@ The Cluster Logging Operator manages the deployment and configuration of the col
 == Validation
 Logging includes extensive validation rules and default values to ensure a smooth and error-free configuration experience. The `ClusterLogForwarder` resource enforces validation checks on required fields, dependencies between fields, and the format of input values. Default values are provided for certain fields, reducing the need for explicit configuration in common scenarios.
 
-=== Quick Start
+== Quick Start
 
 .Prerequisites
-* Cluster administrator permissions
+* You have access to an {product-title} cluster with `cluster-admin` permissions.
+* You installed the {oc-first}.
+* You have access to a supported object store. For example, AWS S3, Google Cloud Storage, {azure-short}, Swift, Minio, or {rh-storage}.
 
 .Procedure
 
-. Install the `OpenShift Logging` and `Loki` Operators from OperatorHub.
+. Install the `{clo}`, `{loki-op}`, and `{coo-first}` from OperatorHub.
 
 . Create a secret to access an existing object storage bucket: 
 +
@@ -95,8 +97,6 @@ $ oc create sa collector -n openshift-logging
 $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector -n openshift-logging
 ----
 
-. Install the Cluster Observability Operator.
-
 . Create a `UIPlugin` to enable the Log section in the Observe tab:
 +
 [source,yaml]
@@ -156,4 +156,5 @@ spec:
     - default-lokistack
 ----
 
-. Verify that logs are visible in the Log section of the Observe tab in the OpenShift web console.
+.Verification
+* Verify that logs are visible in the *Log* section of the *Observe* tab in the {product-title} web console.
diff --git a/observability/logging/logging-6.0/log6x-clf.adoc b/observability/logging/logging-6.0/log6x-clf.adoc
index 5df89bc898df..6172e7722e3e 100644
--- a/observability/logging/logging-6.0/log6x-clf.adoc
+++ b/observability/logging/logging-6.0/log6x-clf.adoc
@@ -62,9 +62,13 @@ Filters:: Transform or drop log messages in the pipeline. Users can define filte
 
 Inputs are configured in an array under `spec.inputs`. There are three built-in input types:
 
-application:: Selects logs from all application containers, excluding those in infrastructure namespaces such as `default`, `openshift`, or any namespace with the `kube-` or `openshift-` prefix.
+application:: Selects logs from all application containers, excluding those in infrastructure namespaces.
 
-infrastructure:: Selects logs from infrastructure components running in `default` and `openshift` namespaces and node logs.
+infrastructure:: Selects logs from nodes and from infrastructure components running in the following namespaces:
+** `default`
+** `kube`
+** `openshift`
+** Containing the `kube-` or `openshift-` prefix
 
 audit:: Selects logs from the OpenShift API server audit logs, Kubernetes API server audit logs, ovn audit logs, and node audit logs from auditd.
 
diff --git a/observability/logging/logging-6.0/log6x-meta-contributing.adoc b/observability/logging/logging-6.0/log6x-meta-contributing.adoc
index 5abbd1b3a267..53067d40cf66 100644
--- a/observability/logging/logging-6.0/log6x-meta-contributing.adoc
+++ b/observability/logging/logging-6.0/log6x-meta-contributing.adoc
@@ -9,10 +9,10 @@ include::_attributes/common-attributes.adoc[]
 Do not include this file in the topic map. This is a guide meant for contributors, and is not intended to be published.
 ====
 
-Logging consists of the Red Hat Openshift Logging Operator (also known as the Cluster Logging Operator), and an accompanying log store Operator. Either the Loki Operator (current/future), or Elasticsearch (deprecated). Either vector (current/future) or fluentd (deprecated) handles log collection and aggregation. Operators use custom resources (CR) to manage applications and their components. High-level configuration and settings are provided by the user within a CR. The Operator translates high-level directives into low-level actions, based on best practices embedded within the Operator’s logic. A custom resource definition (CRD) defines a CR and lists all the configurations available to users of the Operator. Installing an Operator creates the CRDs, which are then used to generate CRs.
+Logging consists of the Red Hat OpenShift Logging Operator (also known as the Cluster Logging Operator), and an accompanying log store Operator. Either the Loki Operator (current/future), or Elasticsearch (deprecated). Either vector (current/future) or fluentd (deprecated) handles log collection and aggregation. Operators use custom resources (CR) to manage applications and their components. High-level configuration and settings are provided by the user within a CR. The Operator translates high-level directives into low-level actions, based on best practices embedded within the Operator’s logic. A custom resource definition (CRD) defines a CR and lists all the configurations available to users of the Operator. Installing an Operator creates the CRDs, which are then used to generate CRs.
 
 == Operator CRs:
-* `Red Hat Openshift Logging Operator`
+* `Red Hat OpenShift Logging Operator`
 ** (Deprecated) `ClusterLogging` (CL) - Deploys the collector and forwarder which currently are both implemented by a daemonset running on each node.
 ** `ClusterLogForwarder` (CLF) - Generates collector configuration to forward logs per user configuration.
 * `Loki Operator`:
diff --git a/observability/logging/logging-6.0/log6x-upgrading-to-6.adoc b/observability/logging/logging-6.0/log6x-upgrading-to-6.adoc
index 84c15f88d1b6..468a3849ea8e 100644
--- a/observability/logging/logging-6.0/log6x-upgrading-to-6.adoc
+++ b/observability/logging/logging-6.0/log6x-upgrading-to-6.adoc
@@ -58,6 +58,7 @@ $ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences"
 ----
 
 . Set *ClusterLogging* to state `Managed`
++
 [source,terminal]
 ----
 $ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge
@@ -250,13 +251,48 @@ metadata:
   name: instance
   namespace: openshift-logging
 spec:
+  serviceAccount:
+    name: <service_account_name>
+  managementState: Managed
   outputs:
-  - name: default-elasticsearch
+  - name: audit-elasticsearch
+    type: elasticsearch
+    elasticsearch:
+      url: https://elasticsearch:9200
+      version: 6
+      index: audit-write
+    tls:
+      ca:
+        key: ca-bundle.crt
+        secretName: collector
+      certificate:
+        key: tls.crt
+        secretName: collector
+      key:
+        key: tls.key
+        secretName: collector
+  - name: app-elasticsearch
+    type: elasticsearch
+    elasticsearch:
+      url: https://elasticsearch:9200
+      version: 6
+      index: app-write
+    tls:
+      ca:
+        key: ca-bundle.crt
+        secretName: collector
+      certificate:
+        key: tls.crt
+        secretName: collector
+      key:
+        key: tls.key
+        secretName: collector
+  - name: infra-elasticsearch
     type: elasticsearch
     elasticsearch:
       url: https://elasticsearch:9200
       version: 6
-      index: <log_type>-write-{+yyyy.MM.dd}
+      index: infra-write
     tls:
       ca:
         key: ca-bundle.crt
@@ -268,18 +304,23 @@ spec:
         key: tls.key
         secretName: collector
   pipelines:
-  - outputRefs:
-    - default-elasticsearch
-  - inputRefs:
+  - name: app
+    inputRefs:
     - application
+    outputRefs:
+    - app-elasticsearch
+  - name: audit
+    inputRefs:
+    - audit
+    outputRefs:
+    - audit-elasticsearch
+  - name: infra
+    inputRefs:
     - infrastructure
+    outputRefs:
+    - infra-elasticsearch
 ----
 
-[NOTE]
-====
-In this example, application logs are written to the `application-write` alias/index instead of `app-write`.
-====
-
 == Red Hat Managed LokiStack
 
 .v5.9 Forwarding to Red Hat Managed LokiStack
@@ -306,6 +347,8 @@ metadata:
   name: instance
   namespace: openshift-logging
 spec:
+  serviceAccount:
+    name: <service_account_name>
   outputs:
   - name: default-lokistack
     type: lokiStack
diff --git a/observability/logging/logging-6.1/log6x-clf-6.1.adoc b/observability/logging/logging-6.1/log6x-clf-6.1.adoc
index 68ec13e67184..23072522a83a 100644
--- a/observability/logging/logging-6.1/log6x-clf-6.1.adoc
+++ b/observability/logging/logging-6.1/log6x-clf-6.1.adoc
@@ -62,9 +62,13 @@ Filters:: Transform or drop log messages in the pipeline. Users can define filte
 
 Inputs are configured in an array under `spec.inputs`. There are three built-in input types:
 
-application:: Selects logs from all application containers, excluding those in infrastructure namespaces such as `default`, `openshift`, or any namespace with the `kube-` or `openshift-` prefix.
+application:: Selects logs from all application containers, excluding those in infrastructure namespaces.
 
-infrastructure:: Selects logs from infrastructure components running in `default` and `openshift` namespaces and node logs.
+infrastructure:: Selects logs from nodes and from infrastructure components running in the following namespaces:
+** `default`
+** `kube`
+** `openshift`   
+** Containing the `kube-` or `openshift-` prefix
 
 audit:: Selects logs from the OpenShift API server audit logs, Kubernetes API server audit logs, ovn audit logs, and node audit logs from auditd.
 
diff --git a/observability/logging/logging_alerts/custom-logging-alerts.adoc b/observability/logging/logging_alerts/custom-logging-alerts.adoc
index 027049a27b56..f405a4702b94 100644
--- a/observability/logging/logging_alerts/custom-logging-alerts.adoc
+++ b/observability/logging/logging_alerts/custom-logging-alerts.adoc
@@ -30,8 +30,12 @@ include::modules/logging-enabling-loki-alerts.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_custom-logging-alerts"]
 == Additional resources
+ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../../observability/monitoring/monitoring-overview.adoc#about-openshift-monitoring[About {product-title} monitoring]
-
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-enterprise[]
 * xref:../../../post_installation_configuration/configuring-alert-notifications.adoc#configuring-alert-notifications[Configuring alert notifications]
 endif::[]
diff --git a/observability/logging/logging_alerts/default-logging-alerts.adoc b/observability/logging/logging_alerts/default-logging-alerts.adoc
index 5c6200089cfd..5f149ce10b36 100644
--- a/observability/logging/logging_alerts/default-logging-alerts.adoc
+++ b/observability/logging/logging_alerts/default-logging-alerts.adoc
@@ -19,4 +19,9 @@ include::modules/cluster-logging-elasticsearch-rules.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_default-logging-alerts"]
 == Additional resources
+ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../../observability/monitoring/managing-alerts.adoc#modifying-core-platform-alerting-rules_managing-alerts[Modifying core platform alerting rules]
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#modifying-core-platform-alerting-rules_managing-alerts-as-an-administrator[Modifying core platform alerting rules]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc b/observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc
index 66d130f11f96..f17e01622a42 100644
--- a/observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc
+++ b/observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc
@@ -12,7 +12,12 @@ include::modules/es-cluster-health-is-red.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
+ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[Reviewing monitoring dashboards]
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[Reviewing monitoring dashboards as a cluster administrator]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * link:https://www.elastic.co/guide/en/elasticsearch/reference/7.13/fix-common-cluster-issues.html#fix-red-yellow-cluster-status[Fix a red or yellow cluster status]
 
 [id="elasticsearch-cluster-health-is-yellow"]
diff --git a/scalability_and_performance/low_latency_tuning/_attributes b/observability/monitoring/about-ocp-monitoring/_attributes
similarity index 100%
rename from scalability_and_performance/low_latency_tuning/_attributes
rename to observability/monitoring/about-ocp-monitoring/_attributes
diff --git a/observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc b/observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc
new file mode 100644
index 000000000000..c4db245903c7
--- /dev/null
+++ b/observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc
@@ -0,0 +1,26 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="about-ocp-monitoring"]
+= About {product-title} monitoring
+:context: about-ocp-monitoring
+
+toc::[]
+
+ifndef::openshift-dedicated,openshift-rosa[]
+{product-title} includes a preconfigured, preinstalled, and self-updating monitoring stack that provides monitoring for core platform components. You also have the option to xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[enable monitoring for user-defined projects].
+
+A cluster administrator can xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[configure the monitoring stack] with the supported configurations. {product-title} delivers monitoring best practices out of the box.
+
+A set of alerts are included by default that immediately notify administrators about issues with a cluster. Default dashboards in the {product-title} web console include visual representations of cluster metrics to help you to quickly understand the state of your cluster. With the {product-title} web console, you can xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[access metrics] and xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[manage alerts].
+
+After installing {product-title}, cluster administrators can optionally enable monitoring for user-defined projects. By using this feature, cluster administrators, developers, and other users can specify how services and pods are monitored in their own projects.
+As a cluster administrator, you can find answers to common problems such as user metrics unavailability and high consumption of disk space by Prometheus in xref:../../../observability/monitoring/troubleshooting-monitoring-issues.adoc#troubleshooting-monitoring-issues[Troubleshooting monitoring issues].
+endif::openshift-dedicated,openshift-rosa[]
+
+ifdef::openshift-dedicated,openshift-rosa[]
+In {product-title}, you can monitor your own projects in isolation from Red{nbsp}Hat Site Reliability Engineering (SRE) platform metrics. You can monitor your own projects without the need for an additional monitoring solution.
+endif::openshift-dedicated,openshift-rosa[]
+
+
+
+
diff --git a/scalability_and_performance/low_latency_tuning/images b/observability/monitoring/about-ocp-monitoring/images
similarity index 100%
rename from scalability_and_performance/low_latency_tuning/images
rename to observability/monitoring/about-ocp-monitoring/images
diff --git a/observability/monitoring/about-ocp-monitoring/key-concepts.adoc b/observability/monitoring/about-ocp-monitoring/key-concepts.adoc
new file mode 100644
index 000000000000..51388771d2d7
--- /dev/null
+++ b/observability/monitoring/about-ocp-monitoring/key-concepts.adoc
@@ -0,0 +1,131 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="key-concepts"]
+= Understanding the monitoring stack - key concepts
+:context: key-concepts
+
+toc::[]
+
+Get familiar with the {product-title} monitoring concepts and terms. Learn about how you can improve performance and scale of your cluster, store and record data, manage metrics and alerts, and more.
+
+[id="about-performance-and-scalability_{context}"]
+== About performance and scalability
+
+You can optimize the performance and scale of your clusters.
+You can configure the default monitoring stack by performing any of the following actions:
+
+* Control the placement and distribution of monitoring components:
+** Use node selectors to move components to specific nodes.
+** Assign tolerations to enable moving components to tainted nodes.
+* Use pod topology spread constraints.
+* Set the body size limit for metrics scraping.
+* Manage CPU and memory resources.
+* Use metrics collection profiles.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#configuring-performance-and-scalability[Configuring performance and scalability for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc#configuring-performance-and-scalability-uwm[Configuring performance and scalability for user workload monitoring]
+
+include::modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc[leveloffset=+2]
+
+include::modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc[leveloffset=+2]
+
+include::modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2]
+
+include::modules/monitoring-configuring-metrics-collection-profiles.adoc[leveloffset=+2]
+
+[id="about-storing-and-recording-data_{context}"]
+== About storing and recording data
+
+You can store and record data to help you protect the data and use them for troubleshooting.
+You can configure the default monitoring stack by performing any of the following actions:
+
+* Configure persistent storage:
+** Protect your metrics and alerting data from data loss by storing them in a persistent volume (PV). As a result, they can survive pods being restarted or recreated.
+** Avoid getting duplicate notifications and losing silences for alerts when the Alertmanager pods are restarted.
+* Modify the retention time and size for Prometheus and Thanos Ruler metrics data.
+* Configure logging to help you troubleshoot issues with your cluster:
+** Configure audit logs for Metrics Server.
+** Set log levels for monitoring.
+** Enable the query logging for Prometheus and Thanos Querier.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#storing-and-recording-data[Storing and recording data for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/storing-and-recording-data-uwm.adoc#storing-and-recording-data-uwm[Storing and recording data for user workload monitoring]
+
+include::modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+2]
+
+// Understanding metrics
+include::modules/monitoring-understanding-metrics.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc#configuring-metrics[Configuring metrics for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#configuring-metrics-uwm[Configuring metrics for user workload monitoring]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[Accessing metrics as an administrator]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#accessing-metrics-as-a-developer[Accessing metrics as a developer]
+
+include::modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-adding-cluster-id-labels-to-metrics.adoc[leveloffset=+2]
+
+//About monitoring dashboards
+[id="about-monitoring-dashboards_{context}"]
+== About monitoring dashboards
+
+{product-title} provides a set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[Reviewing monitoring dashboards as a cluster administrator]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#reviewing-monitoring-dashboards-developer_accessing-metrics-as-a-developer[Reviewing monitoring dashboards as a developer]
+
+include::modules/monitoring-about-monitoring-dashboards.adoc[leveloffset=+2]
+
+//Managing alerts
+include::modules/monitoring-about-managing-alerts.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alerts-and-notifications[Configuring alerts and notifications for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alerts-and-notifications-uwm[Configuring alerts and notifications for user workload monitoring]
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[Managing alerts as an Administrator]
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#managing-alerts-as-a-developer[Managing alerts as a Developer]
+
+include::modules/monitoring-managing-silences.adoc[leveloffset=+2]
+
+include::modules/monitoring-managing-core-platform-alerting-rules.adoc[leveloffset=+2]
+include::modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc[leveloffset=+2]
+
+include::modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc[leveloffset=+2]
+
+include::modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc[leveloffset=+2]
+
+
+// Overview of setting up alert routing for user-defined projects
+include::modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Enabling alert routing for user-defined projects]
+
+// Sending notifications to external systems
+include::modules/monitoring-sending-notifications-to-external-systems.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alert-notifications_configuring-alerts-and-notifications[Configuring alert notifications for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alert-notifications_configuring-alerts-and-notifications-uwm[Configuring alert notifications for user workload monitoring]
+
+
diff --git a/scalability_and_performance/low_latency_tuning/modules b/observability/monitoring/about-ocp-monitoring/modules
similarity index 100%
rename from scalability_and_performance/low_latency_tuning/modules
rename to observability/monitoring/about-ocp-monitoring/modules
diff --git a/observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc b/observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc
new file mode 100644
index 000000000000..2f84137c3860
--- /dev/null
+++ b/observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc
@@ -0,0 +1,54 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="monitoring-stack-architecture"]
+= Monitoring stack architecture
+:context: monitoring-stack-architecture
+
+toc::[]
+
+The {product-title}
+ifdef::openshift-rosa[]
+(ROSA)
+endif::openshift-rosa[]
+monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. The monitoring stack includes default monitoring components and components for monitoring user-defined projects.
+
+// Understanding the monitoring stack
+include::modules/monitoring-understanding-the-monitoring-stack.adoc[leveloffset=+1]
+ifndef::openshift-dedicated,openshift-rosa[]
+//Default monitoring components
+include::modules/monitoring-default-monitoring-components.adoc[leveloffset=+1]
+include::modules/monitoring-default-monitoring-targets.adoc[leveloffset=+2]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#getting-detailed-information-about-a-target_accessing-metrics-as-an-administrator[Getting detailed information about a metrics target]
+endif::openshift-dedicated,openshift-rosa[]
+
+//Components for monitoring user-defined projects
+include::modules/monitoring-components-for-monitoring-user-defined-projects.adoc[leveloffset=+1]
+include::modules/monitoring-targets-for-user-defined-projects.adoc[leveloffset=+2]
+
+//The monitoring stack in high-availability clusters
+include::modules/monitoring-monitoring-stack-in-ha-clusters.adoc[leveloffset=+1]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../operators/operator_sdk/osdk-ha-sno.adoc#osdk-ha-sno[High-availability or single-node cluster detection and support]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#configuring-persistent-storage_storing-and-recording-data[Configuring persistent storage]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#configuring-performance-and-scalability[Configuring performance and scalability]
+
+//Glossary of common terms for OCP monitoring
+include::modules/monitoring-common-terms.adoc[leveloffset=+1]
+
+ifndef::openshift-dedicated,openshift-rosa[]
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+* xref:../../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-monitor-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Granting users permissions for monitoring for user-defined projects]
+* xref:../../../security/tls-security-profiles.adoc#tls-security-profiles[Configuring TLS security profiles]
+endif::openshift-dedicated,openshift-rosa[]
+
+
+
+
+
+
diff --git a/scalability_and_performance/low_latency_tuning/snippets b/observability/monitoring/about-ocp-monitoring/snippets
similarity index 100%
rename from scalability_and_performance/low_latency_tuning/snippets
rename to observability/monitoring/about-ocp-monitoring/snippets
diff --git a/scalability_and_performance/telco_ref_design_specs/core/_attributes b/observability/monitoring/accessing-metrics/_attributes
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/core/_attributes
rename to observability/monitoring/accessing-metrics/_attributes
diff --git a/observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc b/observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc
new file mode 100644
index 000000000000..348aaf79e11d
--- /dev/null
+++ b/observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc
@@ -0,0 +1,37 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="accessing-metrics-as-a-developer"]
+= Accessing metrics as a developer
+:context: accessing-metrics-as-a-developer
+
+toc::[]
+
+You can access metrics to monitor the performance of your cluster workloads.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-metrics_key-concepts[Understanding metrics]
+
+//Viewing a list of available metrics
+include::modules/monitoring-viewing-a-list-of-available-metrics.adoc[leveloffset=+1]
+
+//Querying metrics for user-defined projects with the OCP web console
+include::modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Querying Prometheus] (Prometheus documentation)
+
+//Reviewing monitoring dashboards as a developer
+include::modules/monitoring-reviewing-monitoring-dashboards-developer.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-monitoring-dashboards_key-concepts[About monitoring dashboards]
+* xref:../../../applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc#monitoring-project-and-application-metrics-using-developer-perspective[Monitoring project and application metrics using the Developer perspective]
+
+
+
diff --git a/observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc b/observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc
new file mode 100644
index 000000000000..d552bf30d171
--- /dev/null
+++ b/observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc
@@ -0,0 +1,37 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="accessing-metrics-as-an-administrator"]
+= Accessing metrics as an administrator
+:context: accessing-metrics-as-an-administrator
+
+toc::[]
+
+You can access metrics to monitor the performance of cluster components and your workloads.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-metrics_key-concepts[Understanding metrics]
+
+//Viewing a list of available metrics
+include::modules/monitoring-viewing-a-list-of-available-metrics.adoc[leveloffset=+1]
+
+//Querying metrics for all projects with the OCP web console
+include::modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Querying Prometheus] (Prometheus documentation)
+
+//Getting detailed information about a metrics target
+include::modules/monitoring-getting-detailed-information-about-a-target.adoc[leveloffset=+1]
+
+//Reviewing monitoring dashboards as a cluster administrator
+include::modules/monitoring-reviewing-monitoring-dashboards-admin.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-monitoring-dashboards_key-concepts[About monitoring dashboards]
+
diff --git a/observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc b/observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc
new file mode 100644
index 000000000000..ac3bd4e24ce6
--- /dev/null
+++ b/observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc
@@ -0,0 +1,52 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="accessing-monitoring-apis-by-using-the-cli"]
+= Accessing monitoring APIs by using the CLI
+:context: accessing-monitoring-apis-by-using-the-cli
+
+toc::[]
+
+In {product-title}, you can access web service APIs for some monitoring components from the command-line interface (CLI).
+
+[IMPORTANT]
+====
+In certain situations, accessing API endpoints can degrade the performance and scalability of your cluster, especially if you use endpoints to retrieve, send, or query large amounts of metrics data.
+
+To avoid these issues, consider the following recommendations:
+
+* Avoid querying endpoints frequently. Limit queries to a maximum of one every 30 seconds.
+* Do not retrieve all metrics data through the `/federate` endpoint for Prometheus. Query the endpoint only when you want to retrieve a limited, aggregated data set. For example, retrieving fewer than 1,000 samples for each request helps minimize the risk of performance degradation.
+====
+
+// About accessing monitoring web service APIs
+include::modules/monitoring-about-accessing-monitoring-web-service-apis.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[Reviewing monitoring dashboards as a cluster administrator]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#reviewing-monitoring-dashboards-developer_accessing-metrics-as-a-developer[Reviewing monitoring dashboards as a developer]
+
+// Accessing a monitoring web service API
+include::modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc[leveloffset=+1]
+
+// Querying metrics by using the federation endpoint for Prometheus
+include::modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc[leveloffset=+1]
+
+// Accessing metrics from outside the cluster for custom applications
+include::modules/accessing-metrics-outside-cluster.adoc[leveloffset=+1]
+
+// Resources reference for the Cluster Monitoring Operator
+include::modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc#configuring-remote-write-storage_configuring-metrics[Configuring remote write storage for core platform monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#configuring-remote-write-storage_configuring-metrics-uwm[Configuring remote write storage for monitoring of user-defined projects]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[Accessing metrics as an administrator]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#accessing-metrics-as-a-developer[Accessing metrics as a developer]
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[Managing alerts as an Administrator]
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#managing-alerts-as-a-developer[Managing alerts as a Developer]
diff --git a/scalability_and_performance/telco_ref_design_specs/core/images b/observability/monitoring/accessing-metrics/images
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/core/images
rename to observability/monitoring/accessing-metrics/images
diff --git a/scalability_and_performance/telco_ref_design_specs/core/modules b/observability/monitoring/accessing-metrics/modules
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/core/modules
rename to observability/monitoring/accessing-metrics/modules
diff --git a/scalability_and_performance/telco_ref_design_specs/core/snippets b/observability/monitoring/accessing-metrics/snippets
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/core/snippets
rename to observability/monitoring/accessing-metrics/snippets
diff --git a/observability/monitoring/accessing-third-party-monitoring-apis.adoc b/observability/monitoring/accessing-third-party-monitoring-apis.adoc
index afa25fea4e35..d91e9a95c469 100644
--- a/observability/monitoring/accessing-third-party-monitoring-apis.adoc
+++ b/observability/monitoring/accessing-third-party-monitoring-apis.adoc
@@ -2,12 +2,11 @@
 [id="accessing-third-party-monitoring-apis"]
 = Accessing monitoring APIs by using the CLI
 include::_attributes/common-attributes.adoc[]
-:context: accessing-monitoring-apis-by-using-the-cli
+:context: accessing-third-party-monitoring-apis
 
 toc::[]
 
-[role="_abstract"]
-In {product-title} {product-version}, you can access web service APIs for some monitoring components from the command line interface (CLI).
+In {product-title}, you can access web service APIs for some monitoring components from the command line interface (CLI).
 
 [IMPORTANT]
 ====
@@ -22,6 +21,7 @@ To avoid these issues, follow these recommendations:
 // Accessing service APIs for third-party monitoring components
 include::modules/monitoring-about-accessing-monitoring-web-service-apis.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
 .Additional resources
 * xref:../../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[Reviewing monitoring dashboards]
 
@@ -36,14 +36,13 @@ include::modules/accessing-metrics-outside-cluster.adoc[leveloffset=+1]
 // Resources reference for accessing API endpoints
 include::modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc[leveloffset=+1]
 
-
 [role="_additional-resources"]
-[id="additional-resources_accessing-monitoring-apis-by-using-the-cli"]
+[id="additional-resources_{context}"]
 == Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects-uwm_enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-remote-write-storage_configuring-the-monitoring-stack[Configuring remote write storage]
 * xref:../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
 * xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[Managing alerts]
diff --git a/observability/monitoring/common-monitoring-configuration-scenarios.adoc b/observability/monitoring/common-monitoring-configuration-scenarios.adoc
index 3b6714f6cce6..03cbdb91b4b5 100644
--- a/observability/monitoring/common-monitoring-configuration-scenarios.adoc
+++ b/observability/monitoring/common-monitoring-configuration-scenarios.adoc
@@ -28,7 +28,7 @@ Any other configuration options listed here are optional.
 
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#creating-cluster-monitoring-configmap_configuring-the-monitoring-stack[Create the `cluster-monitoring-config` `ConfigMap` object] if it does not exist.
 * xref:../../observability/monitoring/managing-alerts.adoc#sending-notifications-to-external-systems_managing-alerts[Configure alert receivers] so that Alertmanager can send alerts to an external notification system such as email, Slack, or PagerDuty.
-* xref:../../observability/monitoring/managing-alerts.adoc#configuring-notifications-for-default-platform-alerts_managing-alerts[Configure notifications for default platform alerts].
+* xref:../../observability/monitoring/managing-alerts.adoc#configuring-alert-routing-default-platform-alerts_managing-alerts[Configure notifications for default platform alerts].
 * For shorter term data retention, xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-persistent-storage_configuring-the-monitoring-stack[configure persistent storage] for Prometheus and Alertmanager to store metrics and alert data.
 Specify the metrics data retention parameters for Prometheus and Thanos Ruler.
 +
@@ -57,7 +57,7 @@ With the monitoring stack configured to suit your needs, Prometheus collects met
 You can go to the *Observe* pages in the {product-title} web console to view and query collected metrics, manage alerts, identify performance bottlenecks, and scale resources as needed:
 
 * xref:../../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[View dashboards] to visualize collected metrics, troubleshoot alerts, and monitor other information about your cluster.
-* xref:../../observability/monitoring/managing-metrics.adoc#about-querying-metrics_managing-metrics[Query collected metrics] by creating PromQL queries or using predefined queries.
+* xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-all-projects-with-mon-dashboard_managing-metrics[Query collected metrics] by creating PromQL queries or using predefined queries.
 
 [id="configuring-monitoring-for-user-defined-projects-getting-started_{context}"]
 == Configuring monitoring for user-defined projects: Getting started
@@ -67,20 +67,20 @@ Non-administrator users such as developers can then monitor their own projects o
 
 Cluster administrators typically complete the following activities to configure user-defined projects so that users can view collected metrics, query these metrics, and receive alerts for their own projects:
 
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Enable user-defined projects].
+* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects-uwm_enabling-monitoring-for-user-defined-projects[Enable user-defined projects].
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-users-permission-to-monitor-user-defined-projects_enabling-monitoring-for-user-defined-projects[Assign the `monitoring-rules-view`, `monitoring-rules-edit`, or `monitoring-edit` cluster roles] to grant non-administrator users permissions to monitor user-defined projects.
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-users-permission-to-configure-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Assign the `user-workload-monitoring-config-edit` role] to grant non-administrator users permission to configure user-defined projects.
+* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-users-permission-to-configure-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Grant non-administrator users permission to configure user-defined projects] by assigning the `user-workload-monitoring-config-edit` role.
 * xref:../../observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc#enabling-alert-routing-for-user-defined-projects[Enable alert routing for user-defined projects] so that developers and other users can configure custom alerts and alert routing for their projects.
 * If needed, configure alert routing for user-defined projects to xref:../../observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc#enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing_enabling-alert-routing-for-user-defined-projects[use an optional Alertmanager instance dedicated for use only by user-defined projects].
 * xref:../../observability/monitoring/managing-alerts.adoc#configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts_managing-alerts[Configure alert receivers] for user-defined projects.
-* xref:../../observability/monitoring/managing-alerts.adoc#configuring-notifications-for-user-defined-alerts_managing-alerts[Configure notifications for user-defined alerts].
+* xref:../../observability/monitoring/managing-alerts.adoc#configuring-alert-routing-user-defined-alerts-secret_managing-alerts[Configure notifications for user-defined alerts].
 
 After monitoring for user-defined projects is enabled and configured, developers and other non-administrator users can then perform the following activities to set up and use monitoring for their own projects:
 
 * xref:../../observability/monitoring/managing-metrics.adoc#setting-up-metrics-collection-for-user-defined-projects_managing-metrics[Deploy and monitor services].
 * xref:../../observability/monitoring/managing-alerts.adoc#creating-alerting-rules-for-user-defined-projects_managing-alerts[Create and manage alerting rules].
 * xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[Receive and manage alerts] for their projects.
-* If granted the `user-workload-monitoring-config-edit` role, xref:../../observability/monitoring/managing-alerts.adoc#creating-alert-routing-for-user-defined-projects_managing-alerts[configure alert routing].
+* If granted the `user-workload-monitoring-config-edit` role, xref:../../observability/monitoring/managing-alerts.adoc#configuring-alert-routing-for-user-defined-projects_managing-alerts[configure alert routing].
 * Use the {product-title} web console to xref:../../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards-developer_reviewing-monitoring-dashboards[view dashboards].
-* xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-user-defined-projects-as-a-developer_managing-metrics[Query the collected metrics] by creating PromQL queries or using predefined queries.
+* xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-user-defined-projects-with-mon-dashboard_managing-metrics[Query the collected metrics] by creating PromQL queries or using predefined queries.
 
diff --git a/observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc b/observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc
index 4ee35e301ffd..dd2a0aff6d15 100644
--- a/observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc
+++ b/observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc
@@ -18,8 +18,11 @@ toc::[]
 Parts of {product-title} cluster monitoring are configurable.
 The API is accessible by setting parameters defined in various config maps.
 
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * To configure monitoring components, edit the `ConfigMap` object named `cluster-monitoring-config` in the `openshift-monitoring` namespace.
 These configurations are defined by link:#clustermonitoringconfiguration[ClusterMonitoringConfiguration].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
 * To configure monitoring components that monitor user-defined projects, edit the `ConfigMap` object named `user-workload-monitoring-config` in the `openshift-user-workload-monitoring` namespace.
 These configurations are defined by link:#userworkloadconfiguration[UserWorkloadConfiguration].
 
@@ -29,10 +32,17 @@ The configuration file is always defined under the `config.yaml` key in the conf
 ====
 * Not all configuration parameters for the monitoring stack are exposed.
 Only the parameters and fields listed in this reference are supported for configuration.
-For more information about supported configurations, see xref:../monitoring/configuring-the-monitoring-stack.adoc#maintenance-and-support_configuring-the-monitoring-stack[Maintenance and support for monitoring].
+For more information about supported configurations, see 
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc#maintenance-and-support-for-monitoring[Maintenance and support for monitoring]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#maintenance-and-support_configuring-the-monitoring-stack[Maintenance and support for monitoring].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
 * Configuring cluster monitoring is optional.
 * If a configuration does not exist or is empty, default values are used.
-* If the configuration is invalid YAML data, the Cluster Monitoring Operator stops reconciling the resources and reports `Degraded=True` in the status conditions of the Operator.
+* If the configuration has invalid YAML data, or if it contains unsupported or duplicated fields that bypassed early validation, the Cluster Monitoring Operator stops reconciling the resources and reports the `Degraded=True` status in the status conditions of the Operator.
 ====
 
 == AdditionalAlertmanagerConfig
@@ -142,6 +152,8 @@ The `ClusterMonitoringConfiguration` resource defines settings that customize th
 
 |enableUserWorkload|*bool|`UserWorkloadEnabled` is a Boolean flag that enables monitoring for user-defined projects.
 
+|userWorkload|*link:#userworkloadconfig[UserWorkloadConfig]|`UserWorkload` defines settings for the monitoring of user-defined projects.
+
 |kubeStateMetrics|*link:#kubestatemetricsconfig[KubeStateMetricsConfig]|`KubeStateMetricsConfig` defines settings for the `kube-state-metrics` agent.
 
 |metricsServer|*link:#metricsserverconfig[MetricsServerConfig]|`MetricsServer` defines settings for the Metrics Server component.
@@ -535,6 +547,10 @@ Appears in: link:#userworkloadconfiguration[UserWorkloadConfiguration]
 [options="header"]
 |===
 | Property | Type | Description
+|scrapeInterval|string|Configures the default interval between consecutive scrapes in case the `ServiceMonitor` or `PodMonitor` resource does not specify any value. The interval must be set between 5 seconds and 5 minutes. The value can be expressed in: seconds (for example `30s`), minutes (for example `1m`) or a mix of minutes and seconds (for example `1m30s`). The default value is `30s`.
+
+|evaluationInterval|string|Configures the default interval between rule evaluations in case the `PrometheusRule` resource does not specify any value. The interval must be set between 5 seconds and 5 minutes. The value can be expressed in: seconds (for example `30s`), minutes (for example `1m`) or a mix of minutes and seconds (for example `1m30s`). It only applies to `PrometheusRule` resources with the `openshift.io/prometheus-rule-evaluation-scope=\"leaf-prometheus\"` label. The default value is `30s`.
+
 |additionalAlertmanagerConfigs|[]link:#additionalalertmanagerconfig[AdditionalAlertmanagerConfig]|Configures additional Alertmanager instances that receive alerts from the Prometheus component. By default, no additional Alertmanager instances are configured.
 
 |enforcedLabelLimit|*uint64|Specifies a per-scrape limit on the number of labels accepted for a sample. If the number of labels exceeds this limit after metric relabeling, the entire scrape is treated as failed. The default value is `0`, which means that no limit is set.
@@ -600,7 +616,7 @@ link:#prometheusrestrictedconfig[PrometheusRestrictedConfig]
 
 |oauth2|*monv1.OAuth2|Defines OAuth2 authentication settings for the remote write endpoint.
 
-|proxyUrl|string|Defines an optional proxy URL. It is superseded by the cluster-wide proxy, if enabled.
+|proxyUrl|string|Defines an optional proxy URL. If the cluster-wide proxy is enabled, it replaces the proxyUrl setting. The cluster-wide proxy supports both HTTP and HTTPS proxies, with HTTPS taking precedence.
 
 |queueConfig|*monv1.QueueConfig|Allows tuning configuration for remote write queue parameters.
 
@@ -710,6 +726,8 @@ Appears in: link:#userworkloadconfiguration[UserWorkloadConfiguration]
 | Property | Type | Description
 |additionalAlertmanagerConfigs|[]link:#additionalalertmanagerconfig[AdditionalAlertmanagerConfig]|Configures how the Thanos Ruler component communicates with additional Alertmanager instances. The default value is `nil`.
 
+|evaluationInterval|string|Configures the default interval between Prometheus rule evaluations in case the `PrometheusRule` resource does not specify any value. The interval must be set between 5 seconds and 5 minutes. The value can be expressed in: seconds (for example `30s`), minutes (for example `1m`) or a mix of minutes and seconds (for example `1m30s`). It applies to `PrometheusRule` resources without the `openshift.io/prometheus-rule-evaluation-scope=\"leaf-prometheus\"` label. The default value is `15s`.
+
 |logLevel|string|Defines the log level setting for Thanos Ruler. The possible values are `error`, `warn`, `info`, and `debug`. The default value is `info`.
 
 |nodeSelector|map[string]string|Defines the nodes on which the Pods are scheduled.
@@ -726,6 +744,21 @@ Appears in: link:#userworkloadconfiguration[UserWorkloadConfiguration]
 
 |===
 
+== UserWorkloadConfig
+
+=== Description
+
+The `UserWorkloadConfig` resource defines settings for the monitoring of user-defined projects.
+
+Appears in: link:#clustermonitoringconfiguration[ClusterMonitoringConfiguration]
+
+[options="header"]
+|===
+| Property | Type | Description
+|rulesWithoutLabelEnforcementAllowed|*bool|A Boolean flag that enables or disables the ability to deploy user-defined `PrometheusRules` objects for which the `namespace` label is not enforced to the namespace of the object. Such objects should be created in a namespace configured under the `namespacesWithoutLabelEnforcement` property of the `UserWorkloadConfiguration` resource. The default value is `true`.
+
+|===
+
 == UserWorkloadConfiguration
 
 === Description
@@ -743,4 +776,10 @@ The `UserWorkloadConfiguration` resource defines the settings responsible for us
 
 |thanosRuler|*link:#thanosrulerconfig[ThanosRulerConfig]|Defines the settings for the Thanos Ruler component in user workload monitoring.
 
+|namespacesWithoutLabelEnforcement|[]string|Defines the list of namespaces for which Prometheus and Thanos Ruler in user-defined monitoring do not enforce the `namespace` label value in `PrometheusRule` objects.
+
+The `namespacesWithoutLabelEnforcement` property allows users to define recording and alerting rules that can query across multiple projects (not limited to user-defined projects) instead of deploying identical `PrometheusRule` objects in each user project.
+
+To make the resulting alerts and metrics visible to project users, the query expressions should return a `namespace` label with a non-empty value.
+
 |===
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/_attributes b/observability/monitoring/configuring-core-platform-monitoring/_attributes
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/ran/_attributes
rename to observability/monitoring/configuring-core-platform-monitoring/_attributes
diff --git a/observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc b/observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc
new file mode 100644
index 000000000000..5bbb75ff78f9
--- /dev/null
+++ b/observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc
@@ -0,0 +1,59 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-alerts-and-notifications"]
+= Configuring alerts and notifications for core platform monitoring
+:context: configuring-alerts-and-notifications
+
+toc::[]
+
+You can configure a local or external Alertmanager instance to route alerts from Prometheus to endpoint receivers. You can also attach custom labels to all time series and alerts to add useful metadata information.
+
+//Configuring external Alertmanager instances
+include::modules/monitoring-configuring-external-alertmanagers.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+// Disabling the local Alertmanager
+include::modules/monitoring-disabling-the-local-alertmanager.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/alerting/latest/alertmanager/[Alertmanager] (Prometheus documentation)
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerts-as-an-administrator[Managing alerts as an Administrator]
+
+//Configuring secrets for Alertmanager
+include::modules/monitoring-configuring-secrets-for-alertmanager.adoc[leveloffset=+1]
+
+include::modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+//Attaching additional labels to your time series and alerts
+include::modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure core platform monitoring stack]
+
+[id="configuring-alert-notifications_{context}"]
+== Configuring alert notifications
+
+In {product-title} {product-version}, you can view firing alerts in the Alerting UI. You can configure Alertmanager to send notifications about default platform alerts by configuring alert receivers.
+
+[IMPORTANT]
+====
+Alertmanager does not send notifications by default. It is strongly recommended to configure Alertmanager to receive notifications by configuring alert receivers through the web console or through the `alertmanager-main` secret.
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#sending-notifications-to-external-systems_key-concepts[Sending notifications to external systems]
+* link:https://www.pagerduty.com/[PagerDuty] (PagerDuty official site)
+* link:https://www.pagerduty.com/docs/guides/prometheus-integration-guide/[Prometheus Integration Guide] (PagerDuty official site)
+* xref:../../../observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc#support-version-matrix-for-monitoring-components_maintenance-and-support-for-monitoring[Support version matrix for monitoring components]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Enabling alert routing for user-defined projects]
+
+include::modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc[leveloffset=+2]
+
+include::modules/monitoring-configuring-alert-routing-console.adoc[leveloffset=+2]
+
+include::modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc[leveloffset=+2]
diff --git a/observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc b/observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc
new file mode 100644
index 000000000000..7d46aa6de349
--- /dev/null
+++ b/observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc
@@ -0,0 +1,43 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-metrics"]
+= Configuring metrics for core platform monitoring
+:context: configuring-metrics
+
+toc::[]
+
+Configure the collection of metrics to monitor how cluster components and your own workloads are performing.
+
+You can send ingested metrics to remote systems for long-term storage and add cluster ID labels to the metrics to identify the data coming from different clusters.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-metrics_key-concepts[Understanding metrics]
+
+// Configuring remote write storage
+include::modules/monitoring-configuring-remote-write-storage.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+include::modules/monitoring-supported-remote-write-authentication-settings.adoc[leveloffset=+2]
+
+include::modules/monitoring-example-remote-write-authentication-settings.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+include::modules/monitoring-example-remote-write-queue-configuration.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#spec-remotewrite-2[Prometheus REST API reference for remote write]
+* link:https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage[Setting up remote write compatible endpoints] (Prometheus documentation)
+* link:https://prometheus.io/docs/practices/remote_write/#remote-write-tuning[Tuning remote write settings] (Prometheus documentation)
+* xref:../../../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets-about_nodes-pods-secrets[Understanding secrets]
+
+//Creating cluster ID labels for metrics for core platform monitoring
+include::modules/monitoring-creating-cluster-id-labels-for-metrics.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#adding-cluster-id-labels-to-metrics_key-concepts[Adding cluster ID labels to metrics]
+* xref:../../../support/gathering-cluster-data.adoc#support-get-cluster-id_gathering-cluster-data[Obtaining your cluster ID]
+
diff --git a/observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc b/observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc
new file mode 100644
index 000000000000..c2cb06cc0025
--- /dev/null
+++ b/observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc
@@ -0,0 +1,93 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-performance-and-scalability"]
+= Configuring performance and scalability for core platform monitoring
+:context: configuring-performance-and-scalability
+
+toc::[]
+
+You can configure the monitoring stack to optimize the performance and scale of your clusters. The following documentation provides information about how to distribute the monitoring components and control the impact of the monitoring stack on CPU and memory resources.
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-performance-and-scalability_key-concepts[About performance and scalability]
+
+[id="controlling-placement-and-distribution-of-monitoing-components_{context}"]
+== Controlling the placement and distribution of monitoring components
+
+You can move the monitoring stack components to specific nodes:
+
+* Use the `nodeSelector` constraint with labeled nodes to move any of the monitoring stack components to specific nodes.
+* Assign tolerations to enable moving components to tainted nodes.
+
+By doing so, you control the placement and distribution of the monitoring components across a cluster.
+
+By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-node-selectors-to-move-monitoring-components_key-concepts[Using node selectors to move monitoring components]
+
+include::modules/monitoring-moving-monitoring-components-to-different-nodes.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure core platform monitoring stack]
+* xref:../../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
+* xref:../../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
+* link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector[nodeSelector] (Kubernetes documentation)
+
+include::modules/monitoring-assigning-tolerations-to-monitoring-components.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure core platform monitoring stack]
+* xref:../../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
+* link:https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/[Taints and Tolerations] (Kubernetes documentation)
+
+// Setting the body size limit for metrics scraping
+include::modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config[scrape_config configuration] (Prometheus documentation)
+
+[id="managing-cpu-and-memory-resources-for-monitoring-components_{context}"]
+== Managing CPU and memory resources for monitoring components
+
+You can ensure that the containers that run monitoring components have enough CPU and memory resources by specifying values for resource limits and requests for those components.
+
+You can configure these limits and requests for core platform monitoring components in the `openshift-monitoring` namespace.
+
+include::modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-specifying-limits-and-requests-for-monitoring-components_key-concepts[About specifying limits and requests]
+* link:https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits[Kubernetes requests and limits documentation] (Kubernetes documentation)
+
+// Choosing a metrics collection profile
+include::modules/monitoring-choosing-a-metrics-collection-profile.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#configuring-metrics-collection-profiles_key-concepts[About metrics collection profiles]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#viewing-a-list-of-available-metrics_accessing-metrics-as-an-administrator[Viewing a list of available metrics]
+* xref:../../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
+
+//Configuring pod topology spread constraints for core platform monitoring
+include::modules/monitoring-configuring-pod-topology-spread-constraints.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-pod-topology-spread-constraints-for-monitoring_key-concepts[About pod topology spread constraints for monitoring]
+* xref:../../../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints-about[Controlling pod placement by using pod topology spread constraints]
+* link:https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/[Pod Topology Spread Constraints] (Kubernetes documentation)
+
+
+
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/images b/observability/monitoring/configuring-core-platform-monitoring/images
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/ran/images
rename to observability/monitoring/configuring-core-platform-monitoring/images
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/modules b/observability/monitoring/configuring-core-platform-monitoring/modules
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/ran/modules
rename to observability/monitoring/configuring-core-platform-monitoring/modules
diff --git a/observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc b/observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc
new file mode 100644
index 000000000000..fd96114170c0
--- /dev/null
+++ b/observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc
@@ -0,0 +1,39 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+
+[id="preparing-to-configure-the-monitoring-stack"]
+= Preparing to configure core platform monitoring stack
+:context: preparing-to-configure-the-monitoring-stack
+
+toc::[]
+
+The {product-title} installation program provides only a low number of configuration options before installation. Configuring most {product-title} framework components, including the cluster monitoring stack, happens after the installation.
+
+This section explains which monitoring components can be configured and how to prepare for configuring the monitoring stack.
+
+[IMPORTANT]
+====
+* Not all configuration parameters for the monitoring stack are exposed.
+Only the parameters and fields listed in the xref:../../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}] are supported for configuration.
+
+* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator_recommended-infrastructure-practices[Scaling the {cmo-full}] and verify that you have sufficient resources.
+====
+
+// Configurable monitoring components
+include::modules/monitoring-configurable-monitoring-components.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+// Creating a cluster monitoring config map
+include::modules/monitoring-creating-cluster-monitoring-configmap.adoc[leveloffset=+1]
+
+// Granting users permissions for core platform monitoring
+include::modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#resources-reference-for-the-cluster-monitoring-operator_accessing-monitoring-apis-by-using-the-cli[Resources reference for the {cmo-full}]
+* xref:../../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#cmo-services-resources_accessing-monitoring-apis-by-using-the-cli[CMO services resources]
+
+include::modules/monitoring-granting-user-permissions-using-the-web-console.adoc[leveloffset=+2]
+include::modules/monitoring-granting-user-permissions-using-the-cli.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/snippets b/observability/monitoring/configuring-core-platform-monitoring/snippets
similarity index 100%
rename from scalability_and_performance/telco_ref_design_specs/ran/snippets
rename to observability/monitoring/configuring-core-platform-monitoring/snippets
diff --git a/observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc b/observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc
new file mode 100644
index 000000000000..cb70873c1dec
--- /dev/null
+++ b/observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc
@@ -0,0 +1,60 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="storing-and-recording-data"]
+= Storing and recording data for core platform monitoring
+:context: storing-and-recording-data
+
+toc::[]
+
+Store and record your metrics and alerting data, configure logs to specify which activities are recorded, control how long Prometheus retains stored data, and set the maximum amount of disk space for the data. These actions help you protect your data and use them for troubleshooting.
+
+// Configuring persistent storage
+include::modules/monitoring-configuring-persistent-storage.adoc[leveloffset=+1]
+
+include::modules/monitoring-configuring-a-persistent-volume-claim.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
+* link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[PersistentVolumeClaims] (Kubernetes documentation)
+
+include::modules/monitoring-resizing-a-persistent-volume.adoc[leveloffset=+2,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_recommended-infrastructure-practices[Prometheus database storage requirements]
+* xref:../../../storage/expanding-persistent-volumes.adoc#expanding-pvc-filesystem_expanding-persistent-volumes[Expanding persistent volume claims (PVCs) with a file system]
+
+// Modifying the retention time and size for Prometheus metrics data
+
+include::modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#retention-time-and-size-for-prometheus-metrics-data_key-concepts[Retention time and size for Prometheus metrics]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure core platform monitoring stack]
+* xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_cluster-monitoring-operator[Prometheus database storage requirements]
+* xref:../../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
+* xref:../../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
+* xref:../../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Optimizing storage]
+
+// Configuring audit logs for Metrics Server
+include::modules/monitoring-configuring-audit-logs-for-metrics-server.adoc[leveloffset=+1]
+
+// Setting log levels for monitoring components
+include::modules/monitoring-setting-log-levels-for-monitoring-components.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+// Enabling the query log file for Prometheus
+include::modules/monitoring-setting-query-log-file-for-prometheus.adoc[leveloffset=+1,tags=**;CPM;!UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure core platform monitoring stack]
+
+// Enabling query logging for Thanos Querier
+include::modules/monitoring-enabling-query-logging-for-thanos-querier.adoc[leveloffset=+1]
+
diff --git a/observability/monitoring/configuring-the-monitoring-stack.adoc b/observability/monitoring/configuring-the-monitoring-stack.adoc
index 392e099ab39b..e371520cc755 100644
--- a/observability/monitoring/configuring-the-monitoring-stack.adoc
+++ b/observability/monitoring/configuring-the-monitoring-stack.adoc
@@ -2,21 +2,21 @@
 [id="configuring-the-monitoring-stack"]
 = Configuring the monitoring stack
 include::_attributes/common-attributes.adoc[]
-:context: configuring-the-monitoring-stack
+:context: configuring-the-monitoring-stack 
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 The {product-title} installation program provides only a low number of configuration options before installation. Configuring most {product-title} framework components, including the cluster monitoring stack, happens after the installation.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 This section explains what configuration is supported,
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 shows how to configure the monitoring stack,
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 shows how to configure the monitoring stack for user-defined projects,
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 and demonstrates several common configuration scenarios.
 
 [IMPORTANT]
@@ -25,11 +25,11 @@ Not all configuration parameters for the monitoring stack are exposed.
 Only the parameters and fields listed in the xref:../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}] are supported for configuration.
 ====
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 == Prerequisites
 
 * The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scaling the {cmo-full}] and verify that you have sufficient resources.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Maintenance and support for monitoring
 // include::modules/monitoring-maintenance-and-support.adoc[leveloffset=+1]
@@ -44,21 +44,21 @@ Not all configuration options for the monitoring stack are exposed. The only sup
 
 Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}], your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 Installing another Prometheus instance is not supported by the Red Hat Site Reliability Engineers (SRE).
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/monitoring-support-considerations.adoc[leveloffset=+2]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-support-policy-for-monitoring-operators.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/monitoring-support-version-matrix-for-monitoring-components.adoc[leveloffset=+2]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Preparing to configure the monitoring stack
 [id="preparing-to-configure-the-monitoring-stack"]
 == Preparing to configure the monitoring stack
@@ -72,9 +72,9 @@ include::modules/monitoring-creating-user-defined-workload-monitoring-configmap.
 .Additional resources
 
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Granting users permissions for core platform monitoring
 include::modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc[leveloffset=+1]
 
@@ -82,10 +82,10 @@ include::modules/monitoring-granting-users-permissions-for-core-platform-monitor
 .Additional resources
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-user-permissions-using-the-web-console_enabling-monitoring-for-user-defined-projects[Granting user permissions by using the web console] 
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-user-permissions-using-the-cli_enabling-monitoring-for-user-defined-projects[Granting user permissions by using the CLI]
-* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#resources-reference-for-the-cluster-monitoring-operator_accessing-monitoring-apis-by-using-the-cli[Resources reference for the {cmo-full}]
-* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#cmo-services-resources[CMO services resources]
+* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#resources-reference-for-the-cluster-monitoring-operator_accessing-third-party-monitoring-apis[Resources reference for the {cmo-full}]
+* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#cmo-services-resources_accessing-third-party-monitoring-apis[CMO services resources]
 
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configuring the monitoring stack
 include::modules/monitoring-configuring-the-monitoring-stack.adoc[leveloffset=+1]
@@ -93,62 +93,64 @@ include::modules/monitoring-configuring-the-monitoring-stack.adoc[leveloffset=+1
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Configuration reference for the xref:../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#clustermonitoringconfiguration[`cluster-monitoring-config`] config map
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Configuration reference for the xref:../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#userworkloadconfiguration[`user-workload-monitoring-config`] config map
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configurable monitoring components
-include::modules/monitoring-configurable-monitoring-components.adoc[leveloffset=+1]
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-configurable-monitoring-components.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
 // Moving monitoring components to different nodes
 include::modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 // The nodes topics may apply to OSD/ROSA when that content is ported from OCP.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
 * xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
 * xref:../../nodes/scheduling/nodes-scheduler-pod-affinity.adoc[Placing pods relative to other pods using affinity and anti-affinity rules]
 * xref:../../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc[Controlling pod placement by using pod topology spread constraints]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#using-pod-topology-spread-constraints-for-monitoring_configuring-the-monitoring-stack[Using pod topology spread constraints for monitoring]
 * link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector[Kubernetes documentation about node selectors]
 
-include::modules/monitoring-moving-monitoring-components-to-different-nodes.adoc[leveloffset=+2]
-
+// The module should only include monitoring for user-defined projects
+include::modules/monitoring-moving-monitoring-components-to-different-nodes.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
 // This xref might be relevant for ROSA/OSD if the Node content is reused:
 * xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
 // This xref might be relevant for ROSA/OSD if the Node content is reused:
 * xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * See the link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector[Kubernetes documentation] for details on the `nodeSelector` constraint
 
 // Assigning tolerations to monitoring components
-include::modules/monitoring-assigning-tolerations-to-monitoring-components.adoc[leveloffset=+1]
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-assigning-tolerations-to-monitoring-components.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
 // This xref might be relevant for ROSA/OSD if the Node content is reused:
 * See the xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[{product-title} documentation] on taints and tolerations
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * See the link:https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/[Kubernetes documentation] on taints and tolerations
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Setting the body size limit for metrics scraping
 include::modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc[leveloffset=+1]
 
@@ -156,7 +158,7 @@ include::modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.ado
 .Additional resources
 
 * link:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config[Prometheus scrape configuration documentation]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configuring limits and resource requests for monitoring components
 
@@ -168,76 +170,107 @@ You can ensure that the containers that run monitoring components have enough CP
 You can configure these limits and requests for core platform monitoring components in the `openshift-monitoring` namespace and for the components that monitor user-defined projects in the `openshift-user-workload-monitoring` namespace.
 
 include::modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2]
-include::modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2]
+
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 // Configuring persistent storage
 include::modules/monitoring-configuring-persistent-storage.adoc[leveloffset=+1]
-include::modules/monitoring-configuring-a-persistent-volume-claim.adoc[leveloffset=+2]
 
-ifndef::openshift-dedicated,openshift-rosa[]
-include::modules/monitoring-resizing-a-persistent-volume.adoc[leveloffset=+2]
+// Configuring a persistent volume claim
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-configuring-a-persistent-volume-claim.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[PersistentVolumeClaims](Kubernetes documentation about how to specify `volumeClaimTemplate`)
+
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+// Resizing a persistent volume
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-resizing-a-persistent-volume.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_recommended-infrastructure-practices[Prometheus database storage requirements]
 * xref:../../storage/expanding-persistent-volumes.adoc#expanding-pvc-filesystem_expanding-persistent-volumes[Expanding persistent volume claims (PVCs) with a file system]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
+// The retention time and size for Prometheus metrics data
+// This section will be moved in the future PR. Therefore, some of the repetition in the introduction for the following procedure modules does not matter for the time being
+include::modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+2]
+
+// Modifying the retention time and size for Prometheus metrics data
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
-include::modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+2]
 include::modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#creating-cluster-monitoring-configmap_configuring-the-monitoring-stack[Creating a cluster monitoring config map]
 * xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_cluster-monitoring-operator[Prometheus database storage requirements]
 * xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
 * xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
 * xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Optimizing storage]
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configuring remote write storage for Prometheus
-include::modules/monitoring-configuring-remote-write-storage.adoc[leveloffset=+1]
+
+// Configuring remote write storage
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-configuring-remote-write-storage.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
 include::modules/monitoring-supported-remote-write-authentication-settings.adoc[leveloffset=+2]
-include::modules/monitoring-example-remote-write-authentication-settings.adoc[leveloffset=+2]
-include::modules/monitoring-example-remote-write-queue-configuration.adoc[leveloffset=+2]
+
+// Example remote write authentication settings
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-example-remote-write-authentication-settings.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+// Example remote write queue configuration
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-example-remote-write-queue-configuration.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#spec-remotewrite-2[Prometheus REST API reference for remote write]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * link:https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage[Setting up remote write compatible endpoints] (Prometheus documentation)
 * link:https://prometheus.io/docs/practices/remote_write/#remote-write-tuning[Tuning remote write settings] (Prometheus documentation)
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // This xref might be relevant for ROSA/OSD if this content is reused:
 * xref:../../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets-about_nodes-pods-secrets[Understanding secrets]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configuring labels for outgoing metrics
 include::modules/monitoring-adding-cluster-id-labels-to-metrics.adoc[leveloffset=+1]
-include::modules/monitoring-creating-cluster-id-labels-for-metrics.adoc[leveloffset=+2]
+
+// Creating cluster ID labels for metrics
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-creating-cluster-id-labels-for-metrics.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-remote-write-storage_configuring-the-monitoring-stack[Configuring remote write storage]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../support/gathering-cluster-data.adoc#support-get-cluster-id_gathering-cluster-data[Obtaining your cluster ID]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Configuring audit logs for Metrics Server
 include::modules/monitoring-configuring-audit-logs-for-metrics-server.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Configuring metrics collection profiles
 // TP features are excluded from OSD and ROSA. When this feature is GA, it can be included in the OSD/ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-configuring-metrics-collection-profiles.adoc[leveloffset=+1]
 include::modules/monitoring-choosing-a-metrics-collection-profile.adoc[leveloffset=+2]
 
@@ -246,12 +279,12 @@ include::modules/monitoring-choosing-a-metrics-collection-profile.adoc[leveloffs
 
 * See xref:../../observability/monitoring/managing-metrics.adoc#viewing-a-list-of-available-metrics_managing-metrics[Viewing a list of available metrics] for steps to view a list of metrics being collected for a cluster.
 * See xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc[Enabling features using feature gates] for steps to enable Technology Preview features.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-// Managing scrape and evaluation intervals and enforced limits for user-defined projects
-include::modules/monitoring-limiting-scrape-samples-in-user-defined-projects.adoc[leveloffset=+1]
+// Controlling the impact of unbound metrics attributes in user-defined projects
+include::modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc[leveloffset=+1]
 include::modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc[leveloffset=+2]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-creating-scrape-sample-alerts.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
@@ -260,77 +293,78 @@ include::modules/monitoring-creating-scrape-sample-alerts.adoc[leveloffset=+2]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#creating-user-defined-workload-monitoring-configmap_configuring-the-monitoring-stack[Creating a user-defined workload monitoring config map]
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
 * See xref:../../observability/monitoring/troubleshooting-monitoring-issues.adoc#determining-why-prometheus-is-consuming-disk-space_troubleshooting-monitoring-issues[Determining why Prometheus is consuming a lot of disk space] for steps to query which metrics have the highest number of scrape samples.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-//Configuring external alertmanagers
-include::modules/monitoring-configuring-external-alertmanagers.adoc[leveloffset=1]
+//Configuring external Alertmanager instances
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-configuring-external-alertmanagers.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
 //Configuring secrets for Alertmanager
-include::modules/monitoring-configuring-secrets-for-alertmanager.adoc[leveloffset=1]
-include::modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc[leveloffset=2]
+include::modules/monitoring-configuring-secrets-for-alertmanager.adoc[leveloffset=+1]
+
+// Adding a secret to the Alertmanager configuration
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 //Attaching additional labels to your time series and alerts
-include::modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc[leveloffset=+1]
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps.
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Using topology spread constraints for monitoring components
-include::modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc[leveloffset=1]
+include::modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // This xref might be relevant to ROSA/OSD if the Node content is reused:
 * xref:../../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints-about[Controlling pod placement by using pod topology spread constraints]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * link:https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/[Kubernetes Pod Topology Spread Constraints documentation]
 
 // Configuring pod topology spread constraints
-include::modules/monitoring-configuring-pod-topology-spread-constraints.adoc[leveloffset=2]
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-configuring-pod-topology-spread-constraints.adoc[leveloffset=+2,tags=**;!CPM;UWM]
 
 // Setting log levels for monitoring components
-include::modules/monitoring-setting-log-levels-for-monitoring-components.adoc[leveloffset=+1]
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-setting-log-levels-for-monitoring-components.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
-// Setting query log for Prometheus
-include::modules/monitoring-setting-query-log-file-for-prometheus.adoc[leveloffset=+1]
+// Enabling the query log file for Prometheus
+// The following module should only include monitoring for user-defined projects (UWM tags)
+include::modules/monitoring-setting-query-log-file-for-prometheus.adoc[leveloffset=+1,tags=**;!CPM;UWM]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps
 * See xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects] for steps to enable user-defined monitoring.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Enabling query logging for Thanos Querier
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-enabling-query-logging-for-thanos-querier.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps.
-endif::openshift-dedicated,openshift-rosa[]
-
-[role="_additional-resources"]
-.Additional resources
-
-ifndef::openshift-dedicated,openshift-rosa[]
-* See xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps.
-endif::openshift-dedicated,openshift-rosa[]
+* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Disabling the local Alertmanager
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-disabling-the-local-alertmanager.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 * link:https://prometheus.io/docs/alerting/latest/alertmanager/[Prometheus Alertmanager documentation]
 * xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[Managing alerts]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/observability/monitoring/configuring-user-workload-monitoring/_attributes b/observability/monitoring/configuring-user-workload-monitoring/_attributes
new file mode 120000
index 000000000000..20cc1dcb77bf
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/_attributes
@@ -0,0 +1 @@
+../../_attributes/
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc b/observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc
new file mode 100644
index 000000000000..35300ecbf9fa
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc
@@ -0,0 +1,60 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-alerts-and-notifications-uwm"]
+= Configuring alerts and notifications for user workload monitoring
+:context: configuring-alerts-and-notifications-uwm
+
+toc::[]
+
+You can configure a local or external Alertmanager instance to route alerts from Prometheus to endpoint receivers. You can also attach custom labels to all time series and alerts to add useful metadata information.
+
+//Configuring external Alertmanager instances
+include::modules/monitoring-configuring-external-alertmanagers.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+//Configuring secrets for Alertmanager
+include::modules/monitoring-configuring-secrets-for-alertmanager.adoc[leveloffset=+1]
+
+include::modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+//Attaching additional labels to your time series and alerts
+include::modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+
+[id="configuring-alert-notifications_{context}"]
+== Configuring alert notifications
+
+In {product-title}, an administrator can enable alert routing for user-defined projects with one of the following methods:
+
+* Use the default platform Alertmanager instance.
+* Use a separate Alertmanager instance only for user-defined projects.
+
+Developers and other users with the `alert-routing-edit` cluster role can configure custom alert notifications for their user-defined projects by configuring alert receivers.
+
+[NOTE]
+====
+Review the following limitations of alert routing for user-defined projects:
+
+* User-defined alert routing is scoped to the namespace in which the resource is defined. For example, a routing configuration in namespace `ns1` only applies to `PrometheusRules` resources in the same namespace.
+
+* When a namespace is excluded from user-defined monitoring, `AlertmanagerConfig` resources in the namespace cease to be part of the Alertmanager configuration.
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-alert-routing-for-user-defined-projects_key-concepts[Understanding alert routing for user-defined projects]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#sending-notifications-to-external-systems_key-concepts[Sending notifications to external systems]
+* link:https://www.pagerduty.com/[PagerDuty] (PagerDuty official site)
+* link:https://www.pagerduty.com/docs/guides/prometheus-integration-guide/[Prometheus Integration Guide] (PagerDuty official site)
+* xref:../../../observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc#support-version-matrix-for-monitoring-components_maintenance-and-support-for-monitoring[Support version matrix for monitoring components]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Enabling alert routing for user-defined projects]
+
+include::modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc[leveloffset=+2]
+
+include::modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc[leveloffset=+2]
+
+include::modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc[leveloffset=+2]
diff --git a/observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc b/observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc
new file mode 100644
index 000000000000..9037e8e5adfb
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc
@@ -0,0 +1,60 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-metrics-uwm"]
+= Configuring metrics for user workload monitoring
+:context: configuring-metrics-uwm
+
+toc::[]
+
+Configure the collection of metrics to monitor how cluster components and your own workloads are performing.
+
+You can send ingested metrics to remote systems for long-term storage and add cluster ID labels to the metrics to identify the data coming from different clusters.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-metrics_key-concepts[Understanding metrics]
+
+// Configuring remote write storage
+include::modules/monitoring-configuring-remote-write-storage.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+include::modules/monitoring-supported-remote-write-authentication-settings.adoc[leveloffset=+2]
+
+include::modules/monitoring-example-remote-write-authentication-settings.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+include::modules/monitoring-example-remote-write-queue-configuration.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#spec-remotewrite-2[Prometheus REST API reference for remote write]
+* link:https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage[Setting up remote write compatible endpoints] (Prometheus documentation)
+* link:https://prometheus.io/docs/practices/remote_write/#remote-write-tuning[Tuning remote write settings] (Prometheus documentation)
+* xref:../../../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets-about_nodes-pods-secrets[Understanding secrets]
+
+// Creating cluster ID labels for metrics for monitoring of user-defined projects
+include::modules/monitoring-creating-cluster-id-labels-for-metrics.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#adding-cluster-id-labels-to-metrics_key-concepts[Adding cluster ID labels to metrics]
+* xref:../../../support/gathering-cluster-data.adoc#support-get-cluster-id_gathering-cluster-data[Obtaining your cluster ID]
+
+// Setting up metrics collection for user-defined projects
+
+include::modules/monitoring-setting-up-metrics-collection-for-user-defined-projects.adoc[leveloffset=+1]
+
+include::modules/monitoring-deploying-a-sample-service.adoc[leveloffset=+2]
+
+include::modules/monitoring-specifying-how-a-service-is-monitored.adoc[leveloffset=+2]
+
+include::modules/monitoring-example-service-endpoint-authentication-settings.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* link:https://access.redhat.com/articles/6675491[Scrape Prometheus metrics using TLS in ServiceMonitor configuration] (Red{nbsp}Hat Customer Portal article)
+* xref:../../../rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc#podmonitor-monitoring-coreos-com-v1[PodMonitor API]
+* xref:../../../rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc#servicemonitor-monitoring-coreos-com-v1[ServiceMonitor API]
diff --git a/observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc b/observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc
new file mode 100644
index 000000000000..91c15c52110b
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc
@@ -0,0 +1,98 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="configuring-performance-and-scalability-uwm"]
+= Configuring performance and scalability for user workload monitoring
+:context: configuring-performance-and-scalability-uwm
+
+toc::[]
+
+You can configure the monitoring stack to optimize the performance and scale of your clusters. The following documentation provides information about how to distribute the monitoring components and control the impact of the monitoring stack on CPU and memory resources.
+
+[id="controlling-placement-and-distribution-of-monitoing-components_{context}"]
+== Controlling the placement and distribution of monitoring components
+
+You can move the monitoring stack components to specific nodes:
+
+* Use the `nodeSelector` constraint with labeled nodes to move any of the monitoring stack components to specific nodes.
+* Assign tolerations to enable moving components to tainted nodes.
+
+By doing so, you control the placement and distribution of the monitoring components across a cluster.
+
+By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-node-selectors-to-move-monitoring-components_key-concepts[Using node selectors to move monitoring components]
+
+include::modules/monitoring-moving-monitoring-components-to-different-nodes.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
+* xref:../../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
+* link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector[nodeSelector] (Kubernetes documentation)
+
+include::modules/monitoring-assigning-tolerations-to-monitoring-components.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
+* link:https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/[Taints and Tolerations] (Kubernetes documentation)
+
+[id="managing-cpu-and-memory-resources-for-monitoring-components_{context}"]
+== Managing CPU and memory resources for monitoring components
+
+You can ensure that the containers that run monitoring components have enough CPU and memory resources by specifying values for resource limits and requests for those components.
+
+You can configure these limits and requests for monitoring components that monitor user-defined projects in the `openshift-user-workload-monitoring` namespace.
+
+include::modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-specifying-limits-and-requests-for-monitoring-components_key-concepts[About specifying limits and requests for monitoring components]
+* link:https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits[Kubernetes requests and limits documentation] (Kubernetes documentation)
+
+[id="controlling-the-impact-of-unbound-attributes-in-user-defined-projects_{context}"]
+== Controlling the impact of unbound metrics attributes in user-defined projects
+
+ifndef::openshift-dedicated,openshift-rosa[]
+Cluster administrators
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+A `dedicated-admin`
+endif::openshift-dedicated,openshift-rosa[]
+can use the following measures to control the impact of unbound metrics attributes in user-defined projects:
+
+* Limit the number of samples that can be accepted per target scrape in user-defined projects
+* Limit the number of scraped labels, the length of label names, and the length of label values
+* Configure the intervals between consecutive scrapes and between Prometheus rule evaluations
+* Create alerts that fire when a scrape sample threshold is reached or when the target cannot be scraped
+
+[NOTE]
+====
+Limiting scrape samples can help prevent the issues caused by adding many unbound attributes to labels. Developers can also prevent the underlying cause by limiting the number of unbound attributes that they define for metrics. Using attributes that are bound to a limited set of possible values reduces the number of potential key-value pair combinations.
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#controlling-the-impact-of-unbound-attributes-in-user-defined-projects_key-concepts[Controlling the impact of unbound metrics attributes in user-defined projects]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../observability/monitoring/troubleshooting-monitoring-issues.adoc#determining-why-prometheus-is-consuming-disk-space_troubleshooting-monitoring-issues[Determining why Prometheus is consuming a lot of disk space]
+
+include::modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-creating-scrape-sample-alerts.adoc[leveloffset=+2]
+
+//Configuring pod topology spread constraints for monitoring of user-defined projects
+include::modules/monitoring-configuring-pod-topology-spread-constraints.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-pod-topology-spread-constraints-for-monitoring_key-concepts[About pod topology spread constraints for monitoring]
+* xref:../../../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints-about[Controlling pod placement by using pod topology spread constraints]
+* link:https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/[Pod Topology Spread Constraints] (Kubernetes documentation)
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/images b/observability/monitoring/configuring-user-workload-monitoring/images
new file mode 120000
index 000000000000..847b03ed0541
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/images
@@ -0,0 +1 @@
+../../images/
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/modules b/observability/monitoring/configuring-user-workload-monitoring/modules
new file mode 120000
index 000000000000..36719b9de743
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/modules
@@ -0,0 +1 @@
+../../modules/
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc b/observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc
new file mode 100644
index 000000000000..259aecf491cb
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc
@@ -0,0 +1,76 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="preparing-to-configure-the-monitoring-stack-uwm"]
+= Preparing to configure the user workload monitoring stack
+:context: preparing-to-configure-the-monitoring-stack-uwm
+
+toc::[]
+
+This section explains which user-defined monitoring components can be configured, how to enable user workload monitoring, and how to prepare for configuring the user workload monitoring stack.
+
+[IMPORTANT]
+====
+* Not all configuration parameters for the monitoring stack are exposed.
+Only the parameters and fields listed in the xref:../../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}] are supported for configuration.
+
+* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator_recommended-infrastructure-practices[Scaling the {cmo-full}] and verify that you have sufficient resources.
+====
+
+// Configurable monitoring components
+include::modules/monitoring-configurable-monitoring-components.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+// Enabling monitoring for user-defined projects
+[id="enabling-monitoring-for-user-defined-projects-uwm_{context}"]
+== Enabling monitoring for user-defined projects
+
+In {product-title}, you can enable monitoring for user-defined projects in addition to the default platform monitoring. You can monitor your own projects in {product-title} without the need for an additional monitoring solution. Using this feature centralizes monitoring for core platform components and user-defined projects.
+
+include::snippets/monitoring-custom-prometheus-note.adoc[]
+
+include::modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/getting-started/user-workload-monitoring-first-steps.adoc#user-workload-monitoring-first-steps[User workload monitoring first steps] 
+
+include::modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc[leveloffset=+2]
+
+// Enabling alert routing for user-defined projects
+include::modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#understanding-alert-routing-for-user-defined-projects_key-concepts[Understanding alert routing for user-defined projects]
+
+// Enabling the platform Alertmanager instance for user-defined alert routing
+ifndef::openshift-dedicated,openshift-rosa[]
+include::modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc[leveloffset=+2]
+endif::openshift-dedicated,openshift-rosa[]
+
+include::modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc[leveloffset=+2]
+include::modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alert-notifications_configuring-alerts-and-notifications-uwm[Configuring alert notifications]
+
+// Granting users permissions for monitoring for user-defined projects
+include::modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#cmo-services-resources_accessing-monitoring-apis-by-using-the-cli[CMO services resources]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-configure-monitoring-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Granting users permission to configure monitoring for user-defined projects]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-configure-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Granting users permission to configure alert routing for user-defined projects]
+
+include::modules/monitoring-granting-user-permissions-using-the-web-console.adoc[leveloffset=+2]
+include::modules/monitoring-granting-user-permissions-using-the-cli.adoc[leveloffset=+2,tags=**;UWM;!CPM]
+
+// Excluding a user-defined project from monitoring
+include::modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc[leveloffset=+1]
+
+// Disabling monitoring for user-defined projects
+include::modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/snippets b/observability/monitoring/configuring-user-workload-monitoring/snippets
new file mode 120000
index 000000000000..5a3f5add140e
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/snippets
@@ -0,0 +1 @@
+../../snippets/
\ No newline at end of file
diff --git a/observability/monitoring/configuring-user-workload-monitoring/storing-and-recording-data-uwm.adoc b/observability/monitoring/configuring-user-workload-monitoring/storing-and-recording-data-uwm.adoc
new file mode 100644
index 000000000000..ee27889c5663
--- /dev/null
+++ b/observability/monitoring/configuring-user-workload-monitoring/storing-and-recording-data-uwm.adoc
@@ -0,0 +1,58 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="storing-and-recording-data-uwm"]
+= Storing and recording data for user workload monitoring
+:context: storing-and-recording-data-uwm
+
+toc::[]
+
+Store and record your metrics and alerting data, configure logs to specify which activities are recorded, control how long Prometheus retains stored data, and set the maximum amount of disk space for the data. These actions help you protect your data and use them for troubleshooting.
+
+// Configuring persistent storage
+include::modules/monitoring-configuring-persistent-storage.adoc[leveloffset=+1]
+
+include::modules/monitoring-configuring-a-persistent-volume-claim.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
+* link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[PersistentVolumeClaims] (Kubernetes documentation)
+
+include::modules/monitoring-resizing-a-persistent-volume.adoc[leveloffset=+2,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_recommended-infrastructure-practices[Prometheus database storage requirements]
+* xref:../../../storage/expanding-persistent-volumes.adoc#expanding-pvc-filesystem_expanding-persistent-volumes[Expanding persistent volume claims (PVCs) with a file system]
+
+// Modifying the retention time and size 
+
+include::modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+include::modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#retention-time-and-size-for-prometheus-metrics-data_key-concepts[Retention time and size for Prometheus metrics]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#prometheus-database-storage-requirements_cluster-monitoring-operator[Prometheus database storage requirements]
+* xref:../../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
+* xref:../../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
+* xref:../../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Optimizing storage]
+
+// Setting log levels for monitoring components
+include::modules/monitoring-setting-log-levels-for-monitoring-components.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+// Enabling the query log file for Prometheus
+include::modules/monitoring-setting-query-log-file-for-prometheus.adoc[leveloffset=+1,tags=**;!CPM;UWM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+
+
+
diff --git a/observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc b/observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc
index c03b06ffafa9..c593260ba41b 100644
--- a/observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc
+++ b/observability/monitoring/enabling-alert-routing-for-user-defined-projects.adoc
@@ -6,21 +6,15 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
-ifndef::openshift-dedicated,openshift-rosa[]
-In {product-title} {product-version}, a cluster administrator can enable alert routing for user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-In {product-title}, a `dedicated-admin` can enable alert routing for user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-This process consists of two general steps:
-
-ifndef::openshift-dedicated,openshift-rosa[]
+In {product-title}, an administrator can enable alert routing for user-defined projects.
+This process consists of the following steps:
+
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Enable alert routing for user-defined projects to use the default platform Alertmanager instance or, optionally, a separate Alertmanager instance only for user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Enable alert routing for user-defined projects to use a separate Alertmanager instance.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Grant users permission to configure alert routing for user-defined projects.
 
 After you complete these steps, developers and other users can configure custom alerts and alert routing for their user-defined projects.
@@ -29,9 +23,9 @@ After you complete these steps, developers and other users can configure custom
 include::modules/monitoring-understanding-alert-routing-for-user-defined-projects.adoc[leveloffset=+1]
 
 // Enabling user-defined alerts using the default Alertmanager instance
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Enabling a dedicated Alertmanager instance for use in user-defined projects
 include::modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc[leveloffset=+1]
@@ -42,7 +36,7 @@ include::modules/monitoring-granting-users-permission-to-configure-alert-routing
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user defined projects]
-endif::openshift-dedicated,openshift-rosa[]
-* xref:../../observability/monitoring/managing-alerts.adoc#creating-alert-routing-for-user-defined-projects_managing-alerts[Creating alert routing for user-defined projects]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/managing-alerts.adoc#configuring-alert-routing-for-user-defined-projects_managing-alerts[Configuring alert routing for user-defined projects]
diff --git a/observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc b/observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc
index 64788eeaeadb..0c3e7a8b31de 100644
--- a/observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc
+++ b/observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc
@@ -1,11 +1,15 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="enabling-monitoring-for-user-defined-projects"]
-= Enabling monitoring for user-defined projects
+= Enabling the user workload monitoring
 include::_attributes/common-attributes.adoc[]
 :context: enabling-monitoring-for-user-defined-projects
 
 toc::[]
 
+// Preparing the following short assembly introduction into a module, because this assembly will be deleted and divided into just modules
+// Introduction enabling monitoring for user-defined projects
+//include::modules/monitoring-intro-enabling-monitoring-for-user-defined-projects.adoc[leveloffset=+1]
+
 In {product-title}, you can enable monitoring for user-defined projects in addition to the default platform monitoring. You can monitor your own projects in {product-title} without the need for an additional monitoring solution. Using this feature centralizes monitoring for core platform components and user-defined projects.
 
 include::snippets/monitoring-custom-prometheus-note.adoc[]
@@ -25,22 +29,14 @@ include::modules/monitoring-granting-users-permission-to-monitor-user-defined-pr
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#cmo-services-resources[CMO services resources]
+* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#cmo-services-resources_accessing-third-party-monitoring-apis[CMO services resources]
 
 include::modules/monitoring-granting-user-permissions-using-the-web-console.adoc[leveloffset=+2]
-include::modules/monitoring-granting-user-permissions-using-the-cli.adoc[leveloffset=+2]
+include::modules/monitoring-granting-user-permissions-using-the-cli.adoc[leveloffset=+2,tags=**;CPM;!UWM]
 
 // Granting users permission to configure monitoring for user-defined projects
 include::modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc[leveloffset=+1]
 
-// Accessing metrics from outside the cluster for custom applications
-include::modules/accessing-metrics-outside-cluster.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-
 // Excluding a user-defined project from monitoring
 include::modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc[leveloffset=+1]
 
diff --git a/observability/monitoring/getting-started/_attributes b/observability/monitoring/getting-started/_attributes
new file mode 120000
index 000000000000..20cc1dcb77bf
--- /dev/null
+++ b/observability/monitoring/getting-started/_attributes
@@ -0,0 +1 @@
+../../_attributes/
\ No newline at end of file
diff --git a/observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc b/observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc
new file mode 100644
index 000000000000..2cb5d6128a8b
--- /dev/null
+++ b/observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc
@@ -0,0 +1,58 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="core-platform-monitoring-first-steps"]
+= Core platform monitoring first steps
+:context: core-platform-monitoring-first-steps
+
+toc::[]
+
+After {product-title} is installed, core platform monitoring components immediately begin collecting metrics, which you can query and view.
+The default in-cluster monitoring stack includes the core platform Prometheus instance that collects metrics from your cluster and the core Alertmanager instance that routes alerts, among other components.
+Depending on who will use the monitoring stack and for what purposes, as a cluster administrator, you can further configure these monitoring components to suit the needs of different users in various scenarios.
+
+[id="configuring-core-platform-monitoring-postinstallation-steps_{context}"]
+== Configuring core platform monitoring: Postinstallation steps
+
+After {product-title} is installed, cluster administrators typically configure core platform monitoring to suit their needs.
+These activities include setting up storage and configuring options for Prometheus, Alertmanager, and other monitoring components.
+
+[NOTE]
+====
+By default, in a newly installed {product-title} system, users can query and view collected metrics.
+You need only configure an alert receiver if you want users to receive alert notifications.
+Any other configuration options listed here are optional.
+====
+
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#creating-cluster-monitoring-configmap_preparing-to-configure-the-monitoring-stack[Create the `cluster-monitoring-config` `ConfigMap` object] if it does not exist.
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alert-notifications_configuring-alerts-and-notifications[Configure notifications for default platform alerts] so that Alertmanager can send alerts to an external notification system such as email, Slack, or PagerDuty.
+* For shorter term data retention, xref:../../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#configuring-persistent-storage_storing-and-recording-data[configure persistent storage] for Prometheus and Alertmanager to store metrics and alert data.
+Specify the metrics data retention parameters for Prometheus and Thanos Ruler.
++
+[IMPORTANT]
+====
+* In multi-node clusters, you must configure persistent storage for Prometheus, Alertmanager, and Thanos Ruler to ensure high availability.
+
+* By default, in a newly installed {product-title} system, the monitoring `ClusterOperator` resource reports a `PrometheusDataPersistenceNotConfigured` status message to remind you that storage is not configured.
+====
++
+* For longer term data retention, xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc#configuring-remote-write-storage_configuring-metrics[configure the remote write feature] to enable Prometheus to send ingested metrics to remote systems for storage.
++
+[IMPORTANT]
+====
+Be sure to xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-metrics.adoc#creating-cluster-id-labels-for-metrics_configuring-metrics[add cluster ID labels to metrics] for use with your remote write storage configuration.
+====
++
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/preparing-to-configure-the-monitoring-stack.adoc#granting-users-permissions-for-core-platform-monitoring_preparing-to-configure-the-monitoring-stack[Grant monitoring cluster roles] to any non-administrator users that need to access certain monitoring features.
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#assigning-tolerations-to-monitoring-components_configuring-performance-and-scalability[Assign tolerations] to monitoring stack components so that administrators can move them to tainted nodes.
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#setting-the-body-size-limit-for-metrics-scraping_configuring-performance-and-scalability[Set the body size limit] for metrics collection to help avoid situations in which Prometheus consumes excessive amounts of memory when scraped targets return a response that contains a large amount of data.
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc#managing-alerting-rules-for-core-platform-monitoring_managing-alerts-as-an-administrator[Modify or create alerting rules] for your cluster.
+These rules specify the conditions that trigger alerts, such as high CPU or memory usage, network latency, and so forth.
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/configuring-performance-and-scalability.adoc#managing-cpu-and-memory-resources-for-monitoring-components_configuring-performance-and-scalability[Specify resource limits and requests for monitoring components] to ensure that the containers that run monitoring components have enough CPU and memory resources.
+
+With the monitoring stack configured to suit your needs, Prometheus collects metrics from the specified services and stores these metrics according to your settings.
+You can go to the *Observe* pages in the {product-title} web console to view and query collected metrics, manage alerts, identify performance bottlenecks, and scale resources as needed:
+
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[View dashboards] to visualize collected metrics, troubleshoot alerts, and monitor other information about your cluster.
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#querying-metrics-for-all-projects-with-mon-dashboard_accessing-metrics-as-an-administrator[Query collected metrics] by creating PromQL queries or using predefined queries.
+
+
diff --git a/observability/monitoring/getting-started/developer-and-non-administrator-steps.adoc b/observability/monitoring/getting-started/developer-and-non-administrator-steps.adoc
new file mode 100644
index 000000000000..43aa98574405
--- /dev/null
+++ b/observability/monitoring/getting-started/developer-and-non-administrator-steps.adoc
@@ -0,0 +1,16 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="developer-and-non-administrator-steps"]
+= Developer and non-administrator steps
+:context: developer-and-non-administrator-steps
+
+toc::[]
+
+After monitoring for user-defined projects is enabled and configured, developers and other non-administrator users can then perform the following activities to set up and use monitoring for their own projects:
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#setting-up-metrics-collection-for-user-defined-projects_configuring-metrics-uwm[Deploy and monitor services].
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#managing-alerting-rules-for-user-defined-projects-uwm_managing-alerts-as-a-developer[Create and manage alerting rules].
+* xref:../../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#managing-alerts-as-a-developer[Receive and manage alerts] for your projects.
+* If granted the `alert-routing-edit` cluster role, xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alert-routing-for-user-defined-projects_configuring-alerts-and-notifications-uwm[configure alert routing].
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#reviewing-monitoring-dashboards-developer_accessing-metrics-as-a-developer[View dashboards] by using the {product-title} web console.
+* xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#querying-metrics-for-user-defined-projects-with-mon-dashboard_accessing-metrics-as-a-developer[Query the collected metrics] by creating PromQL queries or using predefined queries.
diff --git a/observability/monitoring/getting-started/images b/observability/monitoring/getting-started/images
new file mode 120000
index 000000000000..847b03ed0541
--- /dev/null
+++ b/observability/monitoring/getting-started/images
@@ -0,0 +1 @@
+../../images/
\ No newline at end of file
diff --git a/observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc b/observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc
new file mode 100644
index 000000000000..157e969aa013
--- /dev/null
+++ b/observability/monitoring/getting-started/maintenance-and-support-for-monitoring.adoc
@@ -0,0 +1,28 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="maintenance-and-support-for-monitoring"]
+= Maintenance and support for monitoring
+:context: maintenance-and-support-for-monitoring
+
+toc::[]
+
+Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the xref:../../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}]. *Do not use other configurations, as they are unsupported.*
+
+Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../../../observability/monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}], your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
+
+ifdef::openshift-dedicated,openshift-rosa[]
+[IMPORTANT]
+====
+Installing another Prometheus instance is not supported by the Red Hat Site Reliability Engineers (SRE).
+====
+endif::openshift-dedicated,openshift-rosa[]
+
+include::modules/monitoring-support-considerations.adoc[leveloffset=+1]
+ifndef::openshift-dedicated,openshift-rosa[]
+include::modules/monitoring-support-policy-for-monitoring-operators.adoc[leveloffset=+1]
+endif::openshift-dedicated,openshift-rosa[]
+
+include::modules/monitoring-support-version-matrix-for-monitoring-components.adoc[leveloffset=+1]
+
+
+
diff --git a/observability/monitoring/getting-started/modules b/observability/monitoring/getting-started/modules
new file mode 120000
index 000000000000..36719b9de743
--- /dev/null
+++ b/observability/monitoring/getting-started/modules
@@ -0,0 +1 @@
+../../modules/
\ No newline at end of file
diff --git a/observability/monitoring/getting-started/snippets b/observability/monitoring/getting-started/snippets
new file mode 120000
index 000000000000..5a3f5add140e
--- /dev/null
+++ b/observability/monitoring/getting-started/snippets
@@ -0,0 +1 @@
+../../snippets/
\ No newline at end of file
diff --git a/observability/monitoring/getting-started/user-workload-monitoring-first-steps.adoc b/observability/monitoring/getting-started/user-workload-monitoring-first-steps.adoc
new file mode 100644
index 000000000000..7b193b5e75e8
--- /dev/null
+++ b/observability/monitoring/getting-started/user-workload-monitoring-first-steps.adoc
@@ -0,0 +1,20 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="user-workload-monitoring-first-steps"]
+= User workload monitoring first steps
+:context: user-workload-monitoring-first-steps
+
+toc::[]
+
+As a cluster administrator, you can optionally enable monitoring for user-defined projects in addition to core platform monitoring.
+Non-administrator users such as developers can then monitor their own projects outside of core platform monitoring.
+
+Cluster administrators typically complete the following activities to configure user-defined projects so that users can view collected metrics, query these metrics, and receive alerts for their own projects:
+
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enable user workload monitoring].
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-monitor-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Grant non-administrator users permissions to monitor user-defined projects] by assigning the `monitoring-rules-view`, `monitoring-rules-edit`, or `monitoring-edit` cluster roles.
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-configure-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Assign the `user-workload-monitoring-config-edit` role] to grant non-administrator users permission to configure user-defined projects.
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-alert-routing-for-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Enable alert routing for user-defined projects] so that developers and other users can configure custom alerts and alert routing for their projects.
+* If needed, configure alert routing for user-defined projects to xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing_preparing-to-configure-the-monitoring-stack-uwm[use an optional Alertmanager instance dedicated for use only by user-defined projects].
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alert-notifications_configuring-alerts-and-notifications-uwm[Configure notifications for user-defined alerts].
+* If you use the platform Alertmanager instance for user-defined alert routing, xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts_configuring-alerts-and-notifications-uwm[configure different alert receivers] for default platform alerts and user-defined alerts.
diff --git a/observability/monitoring/managing-alerts.adoc b/observability/monitoring/managing-alerts.adoc
index ceb8bdcbbaa1..fb9dcddbbe09 100644
--- a/observability/monitoring/managing-alerts.adoc
+++ b/observability/monitoring/managing-alerts.adoc
@@ -18,13 +18,15 @@ The alerts, silences, and alerting rules that are available in the Alerting UI r
 ====
 
 // Accessing the Alerting UI in the Administrator and Developer perspectives
-include::modules/monitoring-accessing-the-alerting-ui.adoc[leveloffset=+1]
+include::modules/monitoring-accessing-the-alerting-ui.adoc[leveloffset=+1,tags=**;ADM;!DEV]
+include::modules/monitoring-accessing-the-alerting-ui.adoc[leveloffset=+1,tags=**;DEV;!ADM]
 
 // Searching and filtering alerts, silences, and alerting rules
 include::modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc[leveloffset=+1]
 
 // Getting information about alerts, silences and alerting rules
-include::modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc[leveloffset=+1]
+include::modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc[leveloffset=+1,tags=**;ADM;!DEV]
+include::modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc[leveloffset=+1,tags=**;DEV;!ADM]
 
 [role="_additional-resources"]
 .Additional resources
@@ -36,9 +38,15 @@ include::modules/monitoring-managing-silences.adoc[leveloffset=+1]
 .Additional resources
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-persistent-storage_configuring-the-monitoring-stack[Configuring persistent storage]
 
-include::modules/monitoring-silencing-alerts.adoc[leveloffset=+2]
-include::modules/monitoring-editing-silences.adoc[leveloffset=+2]
-include::modules/monitoring-expiring-silences.adoc[leveloffset=+2]
+include::modules/monitoring-silencing-alerts.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+include::modules/monitoring-silencing-alerts.adoc[leveloffset=+2,tags=**;DEV;!ADM]
+
+
+include::modules/monitoring-editing-silences.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+include::modules/monitoring-editing-silences.adoc[leveloffset=+2,tags=**;DEV;!ADM]
+
+include::modules/monitoring-expiring-silences.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+include::modules/monitoring-expiring-silences.adoc[leveloffset=+2,tags=**;DEV;!ADM]
 
 // Managing core platform alerting rules
 ifndef::openshift-dedicated,openshift-rosa[]
@@ -56,7 +64,7 @@ include::modules/monitoring-modifying-core-platform-alerting-rules.adoc[leveloff
 * See the link:https://prometheus.io/docs/practices/alerting/[Prometheus alerting documentation] for further guidelines on optimizing alerts.
 endif::openshift-dedicated,openshift-rosa[]
 
-// Creating alerting rules for user-defined projects
+// Creating alerting rules for user workload monitoring
 include::modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc[leveloffset=+1]
 include::modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc[leveloffset=+2]
 include::modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
@@ -67,7 +75,7 @@ include::modules/monitoring-creating-cross-project-alerting-rules-for-user-defin
 * link:https://prometheus.io/docs/practices/alerting/[Prometheus alerting documentation]
 * xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
 
-// Managing alerting rules for user-defined projects
+// Managing alerting rules for user workload monitoring
 include::modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc[leveloffset=+1]
 include::modules/monitoring-accessing-alerting-rules-for-your-project.adoc[leveloffset=+2]
 include::modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc[leveloffset=+2]
@@ -83,12 +91,12 @@ include::modules/monitoring-disabling-cross-project-alerting-rules-for-user-defi
 include::modules/monitoring-sending-notifications-to-external-systems.adoc[leveloffset=+1]
 // Configuring alert receivers
 ifndef::openshift-dedicated,openshift-rosa[]
-include::modules/monitoring-configuring-alert-receivers.adoc[leveloffset=+2]
+include::modules/monitoring-configuring-alert-routing-console.adoc[leveloffset=+2]
 endif::openshift-dedicated,openshift-rosa[]
 // Configuring different alert receivers for default platform alerts and user-defined alerts
 include::modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc[leveloffset=+2]
 // Creating alert routing for user-defined projects
-include::modules/monitoring-creating-alert-routing-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc[leveloffset=+2]
 
 [id="configuring-alertmanager-to-send-notifications"]
 == Configuring Alertmanager to send notifications
@@ -106,14 +114,14 @@ All features of a supported version of upstream Alertmanager are also supported
 
 // Configuring notifications for default platform alerts
 ifndef::openshift-dedicated,openshift-rosa[]
-include::modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc[leveloffset=+2]
+include::modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc[leveloffset=+2]
 endif::openshift-dedicated,openshift-rosa[]
 
 // Configuring notifications for user-defined alerts
-include::modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc[leveloffset=+2]
+include::modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
-[id="additional-resources_configuring-alertmanager-to-send-notifications"]
+[id="additional-resources_{context}"]
 == Additional resources
 
 * link:https://www.pagerduty.com/[PagerDuty official site]
diff --git a/observability/monitoring/managing-alerts/_attributes b/observability/monitoring/managing-alerts/_attributes
new file mode 120000
index 000000000000..20cc1dcb77bf
--- /dev/null
+++ b/observability/monitoring/managing-alerts/_attributes
@@ -0,0 +1 @@
+../../_attributes/
\ No newline at end of file
diff --git a/observability/monitoring/managing-alerts/images b/observability/monitoring/managing-alerts/images
new file mode 120000
index 000000000000..847b03ed0541
--- /dev/null
+++ b/observability/monitoring/managing-alerts/images
@@ -0,0 +1 @@
+../../images/
\ No newline at end of file
diff --git a/observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc b/observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc
new file mode 100644
index 000000000000..ebfe0a61b704
--- /dev/null
+++ b/observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc
@@ -0,0 +1,79 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="managing-alerts-as-a-developer"]
+= Managing alerts as a Developer
+:context: managing-alerts-as-a-developer
+
+toc::[]
+
+In {product-title}, the Alerting UI enables you to manage alerts, silences, and alerting rules.
+
+[NOTE]
+====
+The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to.
+====
+
+// Accessing the Alerting UI from the Developer perspective
+include::modules/monitoring-accessing-the-alerting-ui.adoc[leveloffset=+1,tags=**;DEV;!ADM]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#searching-alerts-silences-and-alerting-rules_key-concepts[Searching and filtering alerts, silences, and alerting rules]
+
+// Getting information about alerts, silences and alerting rules from the Developer perspective
+include::modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc[leveloffset=+1,tags=**;DEV;!ADM]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[{cmo-full} runbooks] ({cmo-full} GitHub repository)
+
+[id="managing-silences_{context}"]
+== Managing silences
+
+You can create a silence for an alert in the {product-title} web console in the *Developer* perspective.
+After you create silences, you can view, edit, and expire them. You also do not receive notifications about a silenced alert when the alert fires.
+
+[NOTE]
+====
+When you create silences, they are replicated across Alertmanager pods. However, if you do not configure persistent storage for Alertmanager, silences might be lost. This can happen, for example, if all Alertmanager pods restart at the same time.
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#managing-silences_key-concepts[Managing silences]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#configuring-persistent-storage_storing-and-recording-data[Configuring persistent storage]
+
+include::modules/monitoring-silencing-alerts.adoc[leveloffset=+2,tags=**;DEV;!ADM]
+include::modules/monitoring-editing-silences.adoc[leveloffset=+2,tags=**;DEV;!ADM]
+include::modules/monitoring-expiring-silences.adoc[leveloffset=+2,tags=**;DEV;!ADM]
+
+
+[id="managing-alerting-rules-for-user-defined-projects-uwm_{context}"]
+== Managing alerting rules for user-defined projects
+
+In {product-title}, you can create, view, edit, and remove alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-creating-alerting-rules-for-user-defined-projects_key-concepts[Creating alerting rules for user-defined projects]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#managing-alerting-rules-for-user-defined-projects_key-concepts[Managing alerting rules for user-defined projects]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#optimizing-alerting-for-user-defined-projects_key-concepts[Optimizing alerting for user-defined projects]
+
+include::modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc#monitoring-stack-architecture[Monitoring stack architecture]
+* link:https://prometheus.io/docs/practices/alerting/[Alerting] (Prometheus documentation)
+
+include::modules/monitoring-accessing-alerting-rules-for-your-project.adoc[leveloffset=+2]
+include::modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/alerting/alertmanager/[Alertmanager] (Prometheus documentation)
diff --git a/observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc b/observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc
new file mode 100644
index 000000000000..fc327fa32e32
--- /dev/null
+++ b/observability/monitoring/managing-alerts/managing-alerts-as-an-administrator.adoc
@@ -0,0 +1,113 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="managing-alerts-as-an-administrator"]
+= Managing alerts as an Administrator
+:context: managing-alerts-as-an-administrator
+
+toc::[]
+
+In {product-title}, the Alerting UI enables you to manage alerts, silences, and alerting rules.
+
+[NOTE]
+====
+The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to. For example, if you are logged in as a user with the `cluster-admin` role, you can access all alerts, silences, and alerting rules.
+====
+
+// Accessing the Alerting UI from the Administrator perspective
+include::modules/monitoring-accessing-the-alerting-ui.adoc[leveloffset=+1,tags=**;ADM;!DEV]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#searching-alerts-silences-and-alerting-rules_key-concepts[Searching and filtering alerts, silences, and alerting rules]
+
+// Getting information about alerts, silences and alerting rules from the Administrator perspective
+include::modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc[leveloffset=+1,tags=**;ADM;!DEV]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[{cmo-full} runbooks] ({cmo-full} GitHub repository)
+
+[id="managing-silences_{context}"]
+== Managing silences
+
+You can create a silence for an alert in the {product-title} web console in the *Administrator* perspective.
+After you create silences, you can view, edit, and expire them. You also do not receive notifications about a silenced alert when the alert fires.
+
+[NOTE]
+====
+When you create silences, they are replicated across Alertmanager pods. However, if you do not configure persistent storage for Alertmanager, silences might be lost. This can happen, for example, if all Alertmanager pods restart at the same time.
+====
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#managing-silences_key-concepts[Managing silences]
+* xref:../../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#configuring-persistent-storage_storing-and-recording-data[Configuring persistent storage]
+
+include::modules/monitoring-silencing-alerts.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+include::modules/monitoring-editing-silences.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+include::modules/monitoring-expiring-silences.adoc[leveloffset=+2,tags=**;ADM;!DEV]
+
+
+[id="managing-alerting-rules-for-core-platform-monitoring_{context}"]
+== Managing alerting rules for core platform monitoring
+
+The {product-title} monitoring includes a large set of default alerting rules for platform metrics.
+As a cluster administrator, you can customize this set of rules in two ways:
+
+* Modify the settings for existing platform alerting rules by adjusting thresholds or by adding and modifying labels.
+For example, you can change the `severity` label for an alert from `warning` to `critical` to help you route and triage issues flagged by an alert.
+
+* Define and add new custom alerting rules by constructing a query expression based on core platform metrics in the `openshift-monitoring` project.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#managing-core-platform-alerting-rules_key-concepts[Managing alerting rules for core platform monitoring]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#tips-for-optimizing-alerting-rules-for-core-platform-monitoring_key-concepts[Tips for optimizing alerting rules for core platform monitoring]
+
+include::modules/monitoring-creating-new-alerting-rules.adoc[leveloffset=+2]
+include::modules/monitoring-modifying-core-platform-alerting-rules.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc#monitoring-stack-architecture[Monitoring stack architecture]
+* link:https://prometheus.io/docs/alerting/alertmanager/[Alertmanager] (Prometheus documentation)
+* link:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config[relabel_config configuration] (Prometheus documentation)
+* link:https://prometheus.io/docs/practices/alerting/[Alerting] (Prometheus documentation)
+
+[id="managing-alerting-rules-for-user-defined-projects_{context}"]
+== Managing alerting rules for user-defined projects
+
+In {product-title}, you can create, view, edit, and remove alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics.
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-creating-alerting-rules-for-user-defined-projects_key-concepts[Creating alerting rules for user-defined projects]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#managing-alerting-rules-for-user-defined-projects_key-concepts[Managing alerting rules for user-defined projects]
+* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#optimizing-alerting-for-user-defined-projects_key-concepts[Optimizing alerting for user-defined projects]
+
+include::modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc#monitoring-stack-architecture[Monitoring stack architecture]
+* link:https://prometheus.io/docs/practices/alerting/[Alerting] (Prometheus documentation)
+
+include::modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc[leveloffset=+2]
+include::modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+include::modules/monitoring-disabling-cross-project-alerting-rules-for-user-defined-projects.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://prometheus.io/docs/alerting/alertmanager/[Alertmanager] (Prometheus documentation)
+
+
+
+
+
diff --git a/observability/monitoring/managing-alerts/modules b/observability/monitoring/managing-alerts/modules
new file mode 120000
index 000000000000..36719b9de743
--- /dev/null
+++ b/observability/monitoring/managing-alerts/modules
@@ -0,0 +1 @@
+../../modules/
\ No newline at end of file
diff --git a/observability/monitoring/managing-alerts/snippets b/observability/monitoring/managing-alerts/snippets
new file mode 120000
index 000000000000..5a3f5add140e
--- /dev/null
+++ b/observability/monitoring/managing-alerts/snippets
@@ -0,0 +1 @@
+../../snippets/
\ No newline at end of file
diff --git a/observability/monitoring/managing-metrics.adoc b/observability/monitoring/managing-metrics.adoc
index d258deedc0da..903da6f5ffe3 100644
--- a/observability/monitoring/managing-metrics.adoc
+++ b/observability/monitoring/managing-metrics.adoc
@@ -26,40 +26,35 @@ include::modules/monitoring-example-service-endpoint-authentication-settings.ado
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * link:https://access.redhat.com/articles/6675491[How to scrape metrics using TLS in a ServiceMonitor configuration in a user-defined project]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc[PodMonitor API]
 * xref:../../rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc[ServiceMonitor API]
-endif::openshift-dedicated,openshift-rosa[]
 
 // Viewing a list of available metrics for a cluster
-ifndef::openshift-dedicated,openshift-rosa[]
 include::modules/monitoring-viewing-a-list-of-available-metrics.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
-
-// Querying metrics
-include::modules/monitoring-about-querying-metrics.adoc[leveloffset=+1]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // include::modules/monitoring-contents-of-the-metrics-ui.adoc[leveloffset=+2]
 
-// Querying metrics for all projects as an administrator
-include::modules/monitoring-querying-metrics-for-all-projects-as-an-administrator.adoc[leveloffset=+2]
+// Querying metrics for all projects with the {product-title} web console [adm]
+include::modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* For more information about creating PromQL queries, see the link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Prometheus query documentation].
+* link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Prometheus query documentation]
 
-// Querying metrics for user-defined projects as a developer
-include::modules/monitoring-querying-metrics-for-user-defined-projects-as-a-developer.adoc[leveloffset=+2]
+// Querying metrics for user-defined projects with the {product-title} web console [dev]
+include::modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* For more information about creating PromQL queries, see the link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Prometheus query documentation].
+* link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Prometheus query documentation]
 
 // Getting detailed information about metrics targets
 include::modules/monitoring-getting-detailed-information-about-a-target.adoc[leveloffset=+1]
diff --git a/observability/monitoring/monitoring-overview.adoc b/observability/monitoring/monitoring-overview.adoc
index c386abed77be..a4f61c7c56a3 100644
--- a/observability/monitoring/monitoring-overview.adoc
+++ b/observability/monitoring/monitoring-overview.adoc
@@ -10,7 +10,7 @@ toc::[]
 == About {product-title} monitoring
 
 [role="_abstract"]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 {product-title} includes a preconfigured, preinstalled, and self-updating monitoring stack that provides monitoring for core platform components. You also have the option to xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[enable monitoring for user-defined projects].
 
 A cluster administrator can xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[configure the monitoring stack] with the supported configurations. {product-title} delivers monitoring best practices out of the box.
@@ -21,25 +21,39 @@ In the *Observe* section of {product-title} web console, you can access and mana
 
 After installing {product-title}, cluster administrators can optionally enable monitoring for user-defined projects. By using this feature, cluster administrators, developers, and other users can specify how services and pods are monitored in their own projects.
 As a cluster administrator, you can find answers to common problems such as user metrics unavailability and high consumption of disk space by Prometheus in xref:../../observability/monitoring/troubleshooting-monitoring-issues.adoc#troubleshooting-monitoring-issues[Troubleshooting monitoring issues].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 In {product-title}, you can monitor your own projects in isolation from Red Hat Site Reliability Engineering (SRE) platform metrics. You can monitor your own projects without the need for an additional monitoring solution.
-endif::openshift-dedicated,openshift-rosa[]
+
+The {product-title}
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
+(ROSA)
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem.
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Understanding the monitoring stack
 include::modules/monitoring-understanding-the-monitoring-stack.adoc[leveloffset=+1]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-default-monitoring-components.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-default-monitoring-targets.adoc[leveloffset=+2]
+
 [role="_additional-resources"]
 .Additional resources
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/monitoring/managing-metrics#getting-detailed-information-about-a-target_managing-metrics[Getting detailed information about a metrics target]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 * xref:../../observability/monitoring/managing-metrics.adoc#getting-detailed-information-about-a-target_managing-metrics[Getting detailed information about a metrics target]
+endif::openshift-rosa-hcp[]
 
 include::modules/monitoring-components-for-monitoring-user-defined-projects.adoc[leveloffset=+2]
 include::modules/monitoring-targets-for-user-defined-projects.adoc[leveloffset=+2]
-include::modules/monitoring-understanding-monitoring-stack-in-ha-clusters.adoc[leveloffset=+2]
+include::modules/monitoring-monitoring-stack-in-ha-clusters.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../operators/operator_sdk/osdk-ha-sno.adoc#osdk-ha-sno[High-availability or single-node cluster detection and support]
@@ -48,12 +62,12 @@ include::modules/monitoring-understanding-monitoring-stack-in-ha-clusters.adoc[l
 
 include::modules/monitoring-common-terms.adoc[leveloffset=+1]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
-[id="additional-resources_monitoring-overview"]
+[id="additional-resources_{context}"]
 == Additional resources
 
 * xref:../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring]
 * xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#granting-users-permission-to-monitor-user-defined-projects_enabling-monitoring-for-user-defined-projects[Granting users permission to monitor user-defined projects]
 * xref:../../security/tls-security-profiles.adoc#tls-security-profiles[Configuring TLS security profiles]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/observability/monitoring/reviewing-monitoring-dashboards.adoc b/observability/monitoring/reviewing-monitoring-dashboards.adoc
index 646873aa02ba..a9ac7b223808 100644
--- a/observability/monitoring/reviewing-monitoring-dashboards.adoc
+++ b/observability/monitoring/reviewing-monitoring-dashboards.adoc
@@ -6,30 +6,10 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
-{product-title} {product-version} provides a comprehensive set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-{product-title} provides monitoring dashboards that help you understand the state of user-defined projects.
-endif::openshift-dedicated,openshift-rosa[]
+{product-title} provides a set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads.
 
-Use the *Administrator* perspective to access dashboards for the core {product-title} components, including the following items:
-
-* API performance
-* etcd
-* Kubernetes compute resources
-* Kubernetes network resources
-* Prometheus
-* USE method dashboards relating to cluster and node performance
-* Node performance metrics
-
-.Example dashboard in the Administrator perspective
-image::monitoring-dashboard-administrator.png[]
-
-In the *Developer* perspective, you can access only the Kubernetes compute resources dashboards:
-
-.Example dashboard in the Developer perspective
-image::observe-dashboard-developer.png[]
+// About monitoring dashboards
+include::modules/monitoring-about-monitoring-dashboards.adoc[leveloffset=+1]
 
 // Reviewing monitoring dashboards as a cluster administrator
 include::modules/monitoring-reviewing-monitoring-dashboards-admin.adoc[leveloffset=+1]
@@ -37,11 +17,10 @@ include::modules/monitoring-reviewing-monitoring-dashboards-admin.adoc[leveloffs
 // Reviewing monitoring dashboards as a developer
 include::modules/monitoring-reviewing-monitoring-dashboards-developer.adoc[leveloffset=+1]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // This additional resource might be valid for ROSA/OSD when the Building applications content is ported.
 [role="_additional-resources"]
-[id="additional-resources-reviewing-monitoring-dashboards"]
-.Additional resources
-
+[id="additional-resources_{context}"]
+== Additional resources
 * xref:../../applications/odc-monitoring-project-and-application-metrics-using-developer-perspective.adoc#monitoring-project-and-application-metrics-using-developer-perspective[Monitoring project and application metrics using the Developer perspective]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/observability/monitoring/shiftstack-prometheus-configuration.adoc b/observability/monitoring/shiftstack-prometheus-configuration.adoc
new file mode 100644
index 000000000000..61c03872ea7d
--- /dev/null
+++ b/observability/monitoring/shiftstack-prometheus-configuration.adoc
@@ -0,0 +1,34 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="shiftstack-prometheus-configuration"]
+= Monitoring clusters that run on RHOSO
+include::_attributes/common-attributes.adoc[]                   
+:context: shiftstack-prometheus-configuration
+                                                                
+toc::[]
+
+You can correlate observability metrics for clusters that run on {rhoso-first}. By collecting metrics from both environments, you can monitor and troubleshoot issues across the infrastructure and application layers.
+
+There are two supported methods for metric correlation for clusters that run on {rhoso}:
+
+- https://prometheus.io/docs/practices/remote_write/#remote-write-tuning[Remote writing] to an external Prometheus instance.
+- Collecting data from the {product-title} federation endpoint to the {rhoso} observability stack.
+
+include::modules/monitoring-configuring-shiftstack-remotewrite.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#configuring-remote-write-storage_configuring-metrics-uwm[Configuring remote write storage]
+* xref:../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#adding-cluster-id-labels-to-metrics_key-concepts[Adding cluster ID labels to metrics]
+
+include::modules/monitoring-configuring-shiftstack-scraping.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_accessing-monitoring-apis-by-using-the-cli[Querying metrics by using the federation endpoint for Prometheus]
+
+include::modules/monitoring-shiftstack-metrics.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+* xref:../../observability/cluster_observability_operator/cluster-observability-operator-overview.adoc#understanding-the-cluster-observability-operator_cluster_observability_operator_overview[Cluster Observability Operator overview]
\ No newline at end of file
diff --git a/observability/monitoring/troubleshooting-monitoring-issues.adoc b/observability/monitoring/troubleshooting-monitoring-issues.adoc
index 096ec7d33a5e..efb0d2d0623f 100644
--- a/observability/monitoring/troubleshooting-monitoring-issues.adoc
+++ b/observability/monitoring/troubleshooting-monitoring-issues.adoc
@@ -6,38 +6,44 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Find troubleshooting steps for common issues with core platform and user-defined project monitoring.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Find troubleshooting steps for common issues with user-defined project monitoring.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Investigating why user-defined project metrics are unavailable (OCP)
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#creating-user-defined-workload-monitoring-configmap_configuring-the-monitoring-stack[Creating a user-defined workload monitoring config map]
-* See xref:../../observability/monitoring/managing-metrics.adoc#specifying-how-a-service-is-monitored_managing-metrics[Specifying how a service is monitored] for details on how to create a `ServiceMonitor` or `PodMonitor` resource
-* See xref:../../observability/monitoring/managing-metrics.adoc#getting-detailed-information-about-a-target_managing-metrics[Getting detailed information about metrics targets]
-endif::openshift-dedicated,openshift-rosa[]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#specifying-how-a-service-is-monitored_configuring-metrics-uwm[Specifying how a service is monitored]
+* xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#getting-detailed-information-about-a-target_accessing-metrics-as-an-administrator[Getting detailed information about a metrics target]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Investigating why user-defined project metrics are unavailable (OSD/ROSA)
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/sd-monitoring-troubleshooting-issues.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Determining why Prometheus is consuming a lot of disk space
 include::modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-
-* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#about-accessing-monitoring-web-service-apis_accessing-monitoring-apis-by-using-the-cli[Accessing monitoring APIs by using the CLI]
-* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_configuring-the-monitoring-stack[Setting scrape intervals, evaluation intervals, and scrape limits for user-defined projects]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#accessing-monitoring-apis-by-using-the-cli[Accessing monitoring APIs by using the CLI]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc#setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_configuring-performance-and-scalability-uwm[Setting scrape intervals, evaluation intervals, and enforced limits for user-defined projects]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/accessing-third-party-monitoring-apis.adoc#about-accessing-monitoring-web-service-apis_accessing-third-party-monitoring-apis[Accessing monitoring APIs by using the CLI]
+* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_configuring-the-monitoring-stack[Setting scrape intervals, evaluation intervals, and enforced limits for user-defined projects]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../support/getting-support.adoc#support-submitting-a-case_getting-support[Submitting a support case]
 
 // Resolving the KubePersistentVolumeFillingUp alert firing for Prometheus
diff --git a/observability/network_observability/configuring-operator.adoc b/observability/network_observability/configuring-operator.adoc
index cb6cee447e7a..258bab64cab8 100644
--- a/observability/network_observability/configuring-operator.adoc
+++ b/observability/network_observability/configuring-operator.adoc
@@ -31,4 +31,6 @@ include::modules/network-observability-total-resource-usage.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference].
\ No newline at end of file
+* xref:../network_observability/observing-network-traffic.adoc#network-observability-trafficflow_nw-observe-network-traffic[Observing the network traffic from the traffic flows view]
+* xref:../network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network Observability without Loki]
+* xref:../network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference]
diff --git a/observability/network_observability/installing-operators.adoc b/observability/network_observability/installing-operators.adoc
index 1260807ea099..7bb2978db752 100644
--- a/observability/network_observability/installing-operators.adoc
+++ b/observability/network_observability/installing-operators.adoc
@@ -9,11 +9,6 @@ Installing Loki is a recommended prerequisite for using the Network Observabilit
 
 The {loki-op} integrates a gateway that implements multi-tenancy and authentication with Loki for data flow storage. The `LokiStack` resource manages Loki, which is a scalable, highly-available, multi-tenant log aggregation system, and a web proxy with {product-title} authentication. The `LokiStack` proxy uses {product-title} authentication to enforce multi-tenancy and facilitate the saving and indexing of data in Loki log stores.
 
-[NOTE]
-====
-The {loki-op} can also be used for xref:../../observability/logging/log_storage/cluster-logging-loki.adoc#cluster-logging-loki[configuring the LokiStack log store]. The Network Observability Operator requires a dedicated LokiStack separate from the {logging}.
-====
-
 include::modules/network-observability-without-loki.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -24,9 +19,9 @@ include::modules/network-observability-loki-install.adoc[leveloffset=+1]
 include::modules/network-observability-loki-secret.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
-* xref:../../observability/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[Flow Collector API Reference] 
+* xref:../../observability/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[Flow Collector API Reference]
 * xref:../../observability/network_observability/configuring-operator.adoc#network-observability-flowcollector-view_network_observability[Flow Collector sample resource]
-* xref:../../observability/logging/log_storage/installing-log-storage.adoc#logging-loki-storage_installing-log-storage[Loki object storage]
+//* xref :../../observability/logging/log_storage/installing-log-storage.adoc#logging-loki-storage_installing-log-storage[Loki object storage]
 
 include::modules/network-observability-lokistack-create.adoc[leveloffset=+2]
 include::modules/logging-creating-new-group-cluster-admin-user-role.adoc[leveloffset=+2]
diff --git a/observability/network_observability/metrics-alerts-dashboards.adoc b/observability/network_observability/metrics-alerts-dashboards.adoc
index 3c8a13b37418..3a404f16cd8f 100644
--- a/observability/network_observability/metrics-alerts-dashboards.adoc
+++ b/observability/network_observability/metrics-alerts-dashboards.adoc
@@ -14,10 +14,11 @@ include::modules/network-observability-metrics-names.adoc[leveloffset=+1]
 include::modules/network-observability-includelist-example.adoc[leveloffset=+1]
 include::modules/network-observability-custom-metrics.adoc[leveloffset=+1]
 include::modules/network-observability-configuring-custom-metrics.adoc[leveloffset=+1]
+include::modules/network-observability-creating-metrics-network-events.adoc[leveloffset=+1]
 
 [IMPORTANT]
 ====
-High cardinality can affect the memory usage of Prometheus. You can check whether specific labels have high cardinality in the xref:../../observability/network_observability/json-flows-format-reference.adocl#network-observability-flows-format_json_reference[Network Flows format reference].
+High cardinality can affect the memory usage of Prometheus. You can check whether specific labels have high cardinality in the xref:../../observability/network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference].
 ====
 include::modules/network-observability-flowmetrics-charts.adoc[leveloffset=+1]
 include::modules/network-observability-tcp-flag-syn-flood.adoc[leveloffset=+1]
@@ -25,5 +26,5 @@ include::modules/network-observability-tcp-flag-syn-flood.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-filtering-ebpf-rule_nw-observe-network-traffic[Filtering eBPF flow data using a global rule]
-* xref:../../observability/monitoring/managing-alerts.adoc#creating-alerting-rules-for-user-defined-projects_managing-alerts[Creating alerting rules for user-defined projects].
+* xref:../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#creating-alerting-rules-for-user-defined-projects_managing-alerts-as-a-developer[Creating alerting rules for user-defined projects].
 * xref:../../support/troubleshooting/investigating-monitoring-issues.adoc#determining-why-prometheus-is-consuming-disk-space_investigating-monitoring-issues[Troubleshooting high cardinality metrics- Determining why Prometheus is consuming a lot of disk space]
diff --git a/observability/network_observability/netobserv_cli/netobserv-cli-using.adoc b/observability/network_observability/netobserv_cli/netobserv-cli-using.adoc
index aeb965e36d97..d9dff3717f35 100644
--- a/observability/network_observability/netobserv_cli/netobserv-cli-using.adoc
+++ b/observability/network_observability/netobserv_cli/netobserv-cli-using.adoc
@@ -10,6 +10,7 @@ You can visualize and filter the flows and packets data directly in the terminal
 
 include::modules/network-observability-cli-capturing-flows.adoc[leveloffset=+1]
 include::modules/network-observability-cli-capturing-packets.adoc[leveloffset=+1]
+include::modules/network-observability-cli-capturing-metrics.adoc[leveloffset=+1]
 include::modules/network-observability-netobserv-cli-cleaning.adoc[leveloffset=+1]
 
 [role=_additional_resources]
diff --git a/observability/network_observability/network-observability-operator-monitoring.adoc b/observability/network_observability/network-observability-operator-monitoring.adoc
index 9c9219106ace..1dafd36fe84c 100644
--- a/observability/network_observability/network-observability-operator-monitoring.adoc
+++ b/observability/network_observability/network-observability-operator-monitoring.adoc
@@ -17,4 +17,4 @@ include::modules/network-observability-ebpf-agent-alert.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-* For more information about creating alerts that you can see on the dashboard, see xref:../../observability/monitoring/managing-alerts.adoc#creating-alerting-rules-for-user-defined-projects_managing-alerts[Creating alerting rules for user-defined projects].
\ No newline at end of file
+* For more information about creating alerts that you can see on the dashboard, see xref:../../observability/monitoring/managing-alerts/managing-alerts-as-a-developer.adoc#creating-alerting-rules-for-user-defined-projects_managing-alerts-as-a-developer[Creating alerting rules for user-defined projects].
\ No newline at end of file
diff --git a/observability/network_observability/network-observability-operator-release-notes.adoc b/observability/network_observability/network-observability-operator-release-notes.adoc
index f7b7ef29df73..84b33c72c23d 100644
--- a/observability/network_observability/network-observability-operator-release-notes.adoc
+++ b/observability/network_observability/network-observability-operator-release-notes.adoc
@@ -12,6 +12,95 @@ The Network Observability Operator enables administrators to observe and analyze
 These release notes track the development of the Network Observability Operator in the {product-title}.
 
 For an overview of the Network Observability Operator, see xref:../../observability/network_observability/network-observability-overview.adoc#dependency-network-observability[About Network Observability Operator].
+
+[id="network-observability-operator-release-notes-1-8_{context}"]
+== Network Observability Operator 1.8.0
+The following advisory is available for the Network Observability Operator 1.8.0:
+
+* link:https://access.redhat.com/errata/RHEA-2025:1940[Network Observability Operator 1.8.0]
+
+[id="network-observability-operator-1.8.0-features-enhancements_{context}"]
+=== New features and enhancements
+
+[id="network-observability-operator-pkt-xlat-1-8_{context}"]
+==== Packet translation
+You can now enrich network flows with translated endpoint information, showing not only the service but also the specific backend pod, so you can see which pod served a request.
+
+For more information, see xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-packet-translation-overview_nw-observe-network-traffic[Endpoint translation (xlat)] and xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-packet-translation_nw-observe-network-traffic[Working with endpoint translation (xlat)].
+
+[id="network-observability-operator-OVN-observability-1-8_{context}"]
+==== OVN-Kubernetes networking events tracking
+
+:FeatureName: OVN-Kubernetes networking events tracking
+include::snippets/technology-preview.adoc[]
+
+You can now use network event tracking in Network Observability to gain insight into OVN-Kubernetes events, including network policies, admin network policies, and egress firewalls.
+
+For more information, see xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-viewing-network-events_nw-observe-network-traffic[Viewing network events].
+
+[id="network-observability-operator-ebpf-perf-improvements-1-8_{context}"]
+==== eBPF performance improvements in 1.8
+
+* Network Observability now uses hash maps instead of per-CPU maps. This means that network flows data is now tracked in the kernel space and new packets are also aggregated there. The de-duplication of network flows can now occur in the kernel, so the size of data transfer between the kernel and the user spaces yields better performance. With these eBPF performance improvements, there is potential to observe a CPU resource reduction between 40% and 57% in the eBPF Agent.
+
+[id="network-observability-cli-1-8_{context}"]
+==== Network Observability CLI
+
+The following new features, options, and filters are added to the Network Observability CLI for this release:
+
+* Capture metrics with filters enabled by running the `oc netobserv metrics` command.
+* Run the CLI in the background by using the `--background` option with flows and packets capture and running `oc netobserv follow` to see the progress of the background run and `oc netobserv copy` to download the generated logs.
+* Enrich flows and metrics capture with Machines, Pods, and Services subnets by using the `--get-subnets` option.
+* New filtering options available with packets, flows, and metrics capture:
+
+** eBPF filters on IPs, Ports, Protocol, Action, TCP Flags and more
+** Custom nodes using `--node-selector`
+** Drops only using `--drops`
+** Any field using `--regexes`
+
+For more information, see xref:../../observability/network_observability/netobserv_cli/netobserv-cli-reference.adoc#network-observability-netobserv-cli-reference_netobserv-cli-reference[Network Observability CLI reference].
+
+[id="network-observability-operator-1-8-bug-fixes_{context}"]
+=== Bug fixes
+* Previously, the Network Observability Operator came with a "kube-rbac-proxy" container to manage RBAC for its metrics server. Since this external component is deprecated, it was necessary to remove it. It is now replaced with direct TLS and RBAC management through Kubernetes controller-runtime, without the need for a side-car proxy. (link:https://issues.redhat.com/browse/NETOBSERV-1999[*NETOBSERV-1999*])
+
+* Previously in the {product-title} console plugin, filtering on a key that was not equal to multiple values would not filter anything. With this fix, the expected results are returned, which is all flows not having any of the filtered values. (link:https://issues.redhat.com/browse/NETOBSERV-1990[*NETOBSERV-1990*])
+
+* Previously in the {product-title} console plugin with disabled Loki, it was very likely to generate a "Can't build query" error due to selecting an incompatible set of filters and aggregations. Now this error is avoided avoid by automatically disabling incompatible filters while still making the user aware of the filter incompatibility. (link:https://issues.redhat.com/browse/NETOBSERV-1977[*NETOBSERV-1977*])
+
+* Previously, when viewing flow details from the console plugin, the ICMP info was always displayed in the side panel, showing "undefined" values for non-ICMP flows. With this fix, ICMP info is not displayed for non-ICMP flows. (link:https://issues.redhat.com/browse/NETOBSERV-1969[*NETOBSERV-1969*])
+
+* Previously, the "Export data" link from the *Traffic flows* view did not work as intended, generating empty CSV reports. Now, the export feature is restored, generating non-empty CSV data. (link:https://issues.redhat.com/browse/NETOBSERV-1958[*NETOBSERV-1958*])
+
+* Previously, it was possible to configure the `FlowCollector` with `processor.logTypes` `Conversations`, `EndedConversations` or `All` with `loki.enable` set to `false`, despite the conversation logs being only useful when Loki is enabled. This resulted in resource usage waste. Now, this configuration is invalid and is rejected by the validation webhook. (link:https://issues.redhat.com/browse/NETOBSERV-1957[*NETOBSERV-1957*])
+
+* Configuring the `FlowCollector` with `processor.logTypes` set to `All` consumes much more resources, such as CPU, memory and network bandwidth, than the other options. This was previously not documented. It is now documented, and triggers a warning from the validation webhook. (link:https://issues.redhat.com/browse/NETOBSERV-1956[*NETOBSERV-1956*])
+
+* Previously, under high stress, some flows generated by the eBPF agent were mistakenly dismissed, resulting in traffic bandwidth under-estimation. Now, those generated flows are not dismissed. (link:https://issues.redhat.com/browse/NETOBSERV-1954[*NETOBSERV-1954*])
+
+* Previously, when enabling the network policy in the `FlowCollector` configuration, the traffic to the Operator webhooks was blocked, breaking the `FlowMetrics` API validation. Now traffic to the webhooks is allowed. (link:https://issues.redhat.com/browse/NETOBSERV-1934[*NETOBSERV-1934*])
+
+* Previously, when deploying the default network policy, namespaces `openshift-console` and `openshift-monitoring` were set by default in the `additionalNamespaces` field, resulting in duplicated rules. Now there is no additional namespace set by default, which helps avoid getting duplicated rules.(link:https://issues.redhat.com/browse/NETOBSERV-1933[*NETOBSERV-1933*])
+
+* Previously from the {product-title} console plugin, filtering on TCP flags would match flows having only the exact desired flag. Now, any flow having at least the desired flag appears in filtered flows. (link:https://issues.redhat.com/browse/NETOBSERV-1890[*NETOBSERV-1890*])
+
+* When the eBPF agent runs in privileged mode and pods are continuously added or deleted, a file descriptor (FD) leak occurs. The fix ensures proper closure of the FD when a network namespace is deleted. (link:https://issues.redhat.com/browse/NETOBSERV-2063[*NETOBSERV-2063*])
+
+* Previously, the CLI agent `DaemonSet` did not deploy on master nodes. Now, a  toleration is added on the agent `DaemonSet` to schedule on every node when taints are set. Now, CLI agent `DaemonSet` pods run on all nodes. (link:https://issues.redhat.com/browse/NETOBSERV-2030[*NETOBSERV-2030*])
+
+* Previously, the *Source Resource* and *Source Destination* filters autocomplete were not working when using Prometheus storage only. Now this issue is fixed and suggestions displays as expected. (link:https://issues.redhat.com/browse/NETOBSERV-1885[*NETOBSERV-1885*])
+
+* Previously, a resource using multiple IPs was displayed separately in the *Topology* view. Now, the resource shows as a single topology node in the view. (link:https://issues.redhat.com/browse/NETOBSERV-1818[*NETOBSERV-1818*])
+
+* Previously, the console refreshed the *Network traffic* table view contents when the mouse pointer hovered over the columns. Now, the the display is fixed, so row height remains constant with a mouse hover. (link:https://issues.redhat.com/browse/NETOBSERV-2049[*NETOBSERV-2049*])
+
+[id="network-observability-operator-1-8-known-issues_{context}"]
+=== Known issues
+
+* If there is traffic that uses overlapping subnets in your cluster, there is a small risk that the eBPF Agent mixes up the flows from overlapped IPs. This can happen if different connections happen to have the exact same source and destination IPs and if ports and protocol are within a 5 seconds time frame and happening on the same node. This should not be possible unless you configured secondary networks or UDN. Even in that case, it is still very unlikely in usual traffic, as source ports are usually a good differentiator. (link:https://issues.redhat.com/browse/NETOBSERV-2115[*NETOBSERV-2115*])
+
+* After selecting a type of exporter to configure in the `FlowCollector` resource `spec.exporters` section from the {product-title} web console form view, the detailed configuration for that type does not show up in the form. The workaround is to configure directly the YAML. (link:https://issues.redhat.com/browse/NETOBSERV-1981[*NETOBSERV-1981*])
+
 [id="network-observability-operator-release-notes-1-7_{context}"]
 == Network Observability Operator 1.7.0
 The following advisory is available for the Network Observability Operator 1.7.0:
diff --git a/observability/network_observability/observing-network-traffic.adoc b/observability/network_observability/observing-network-traffic.adoc
index 1467a6ec9406..f6077154c997 100644
--- a/observability/network_observability/observing-network-traffic.adoc
+++ b/observability/network_observability/observing-network-traffic.adoc
@@ -41,6 +41,11 @@ include::modules/network-observability-flow-filter-parameters.adoc[leveloffset=+
 * xref:../../observability/network_observability/metrics-alerts-dashboards.adoc#network-observability-metrics_metrics-dashboards-alerts[Network Observability metrics]
 * xref:../../observability/network_observability/network-observability-operator-monitoring.adoc#network-observability-health-dashboard-overview_network_observability[Health dashboards]
 
+include::modules/network-observability-networking-events-overview.adoc[leveloffset=+2]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-viewing-network-events_nw-observe-network-traffic[Viewing network events]
+
 //Traffic flows
 include::modules/network-observability-trafficflow.adoc[leveloffset=+1]
 include::modules/network-observability-working-with-trafficflow.adoc[leveloffset=+2]
@@ -52,6 +57,14 @@ include::modules/network-observability-RTT.adoc[leveloffset=+2]
 include::modules/network-observability-histogram-trafficflow.adoc[leveloffset=+2]
 include::modules/network-observability-working-with-zones.adoc[leveloffset=+2]
 include::modules/network-observability-filtering-ebpf-rule.adoc[leveloffset=+2]
+include::modules/network-observability-packet-translation-overview.adoc[leveloffset=+2]
+include::modules/network-observability-packet-translation.adoc[leveloffset=+2]
+include::modules/network-observability-viewing-network-events.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling-features-cli_nodes-cluster-enabling[Enabling feature sets using the CLI]
+* xref:../../networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources.adoc#nw-ovn-kubernetes-observability_ovn-kubernetes-sources-of-troubleshooting-information[Checking OVN-Kubernetes network traffic with OVS sampling using the CLI]
 
 //Topology
 include::modules/network-observability-topology.adoc[leveloffset=+1]
diff --git a/observability/otel/otel-configuration-of-otel-collector.adoc b/observability/otel/otel-collector/otel-collector-configuration-intro.adoc
similarity index 100%
rename from observability/otel/otel-configuration-of-otel-collector.adoc
rename to observability/otel/otel-collector/otel-collector-configuration-intro.adoc
diff --git a/observability/otel/otel-collector/otel-collector-connectors.adoc b/observability/otel/otel-collector/otel-collector-connectors.adoc
index 713766c250a7..0a97550e81ea 100644
--- a/observability/otel/otel-collector/otel-collector-connectors.adoc
+++ b/observability/otel/otel-collector/otel-collector-connectors.adoc
@@ -8,6 +8,13 @@ toc::[]
 
 A connector connects two pipelines. It consumes data as an exporter at the end of one pipeline and emits data as a receiver at the start of another pipeline. It can consume and emit data of the same or different data type. It can generate and emit data to summarize the consumed data, or it can merely replicate or route data.
 
+Currently, the following General Availability and Technology Preview connectors are available for the {OTELShortName}:
+
+- xref:../../../observability/otel/otel-collector/otel-collector-connectors.adoc#count-connector_otel-collector-connectors[Count Connector]
+- xref:../../../observability/otel/otel-collector/otel-collector-connectors.adoc#routing-connector_otel-collector-connectors[Routing Connector]
+- xref:../../../observability/otel/otel-collector/otel-collector-connectors.adoc#forward-connector_otel-collector-connectors[Forward Connector]
+- xref:../../../observability/otel/otel-collector/otel-collector-connectors.adoc#spanmetrics-connector_otel-collector-connectors[Spanmetrics Connector]
+
 [id="count-connector_{context}"]
 == Count Connector
 
@@ -30,7 +37,7 @@ You can also expose custom metric names.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       otlp:
         protocols:
@@ -40,7 +47,7 @@ You can also expose custom metric names.
       prometheus:
         endpoint: 0.0.0.0:8889
     connectors:
-      count:
+      count: {}
     service:
       pipelines: # <1>
         traces/in:
@@ -66,7 +73,7 @@ The Count Connector can count telemetry data according to defined conditions and
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     connectors:
       count:
         spans: # <1>
@@ -91,7 +98,7 @@ The Count Connector can count telemetry data according to defined attributes whe
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     connectors:
       count:
         logs: # <1>
@@ -117,7 +124,8 @@ include::snippets/technology-preview.adoc[]
 .OpenTelemetry Collector custom resource with an enabled Routing Connector
 [source,yaml]
 ----
-  config: |
+# ...
+  config:
     connectors:
       routing:
         table: # <1>
@@ -139,6 +147,7 @@ include::snippets/technology-preview.adoc[]
         traces/prod:
           receivers: [routing]
           exporters: [otlp/prod]
+# ...
 ----
 <1> Connector routing table.
 <2> Routing conditions written as OTTL statements.
@@ -159,36 +168,37 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-receivers:
-  otlp:
-    protocols:
-      grpc:
-  jaeger:
-    protocols:
-      grpc:
-processors:
-  batch:
-exporters:
-  otlp:
-    endpoint: tempo-simplest-distributor:4317
-    tls:
-      insecure: true
-connectors:
-  forward:
-service:
-  pipelines:
-    traces/regiona:
-      receivers: [otlp]
-      processors: []
-      exporters: [forward]
-    traces/regionb:
-      receivers: [jaeger]
-      processors: []
-      exporters: [forward]
-    traces:
-      receivers: [forward]
-      processors: [batch]
-      exporters: [otlp]
+  config:
+    receivers:
+      otlp:
+        protocols:
+          grpc:
+      jaeger:
+        protocols:
+          grpc:
+    processors:
+      batch:
+    exporters:
+      otlp:
+        endpoint: tempo-simplest-distributor:4317
+        tls:
+          insecure: true
+    connectors:
+      forward: {}
+    service:
+      pipelines:
+        traces/regiona:
+          receivers: [otlp]
+          processors: []
+          exporters: [forward]
+        traces/regionb:
+          receivers: [jaeger]
+          processors: []
+          exporters: [forward]
+        traces:
+          receivers: [forward]
+          processors: [batch]
+          exporters: [otlp]
 # ...
 ----
 
@@ -201,7 +211,7 @@ The Spanmetrics Connector aggregates Request, Error, and Duration (R.E.D) OpenTe
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     connectors:
       spanmetrics:
         metrics_flush_interval: 15s # <1>
diff --git a/observability/otel/otel-collector/otel-collector-exporters.adoc b/observability/otel/otel-collector/otel-collector-exporters.adoc
index 9bfcfbc907c6..5fe546f00d09 100644
--- a/observability/otel/otel-collector/otel-collector-exporters.adoc
+++ b/observability/otel/otel-collector/otel-collector-exporters.adoc
@@ -8,16 +8,30 @@ toc::[]
 
 Exporters send data to one or more back ends or destinations. An exporter can be push or pull based. By default, no exporters are configured. One or more exporters must be configured. Exporters can support one or more data sources. Exporters might be used with their default settings, but many exporters require configuration to specify at least the destination and security settings.
 
+Currently, the following General Availability and Technology Preview exporters are available for the {OTELShortName}:
+
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#otlp-exporter_otel-collector-exporters[OTLP Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#otlp-http-exporter_otel-collector-exporters[OTLP HTTP Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#debug-exporter_otel-collector-exporters[Debug Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#load-balancing-exporter_otel-collector-exporters[Load Balancing Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#prometheus-exporter_otel-collector-exporters[Prometheus Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#prometheus-remote-write-exporter_otel-collector-exporters[Prometheus Remote Write Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#kafka-exporter_otel-collector-exporters[Kafka Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#aws-cloudwatch-exporter_otel-collector-exporters[AWS CloudWatch Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#aws-emf-exporter_otel-collector-exporters[AWS EMF Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#aws-xray-exporter_otel-collector-exporters[AWS X-Ray Exporter]
+- xref:../../../observability/otel/otel-collector/otel-collector-exporters.adoc#file-exporter_otel-collector-exporters[File Exporter]
+
 [id="otlp-exporter_{context}"]
 == OTLP Exporter
 
 The OTLP gRPC Exporter exports traces and metrics by using the OpenTelemetry protocol (OTLP).
 
-.OpenTelemetry Collector custom resource with an enabled OTLP Exporter
+.OpenTelemetry Collector custom resource with the enabled OTLP Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       otlp:
         endpoint: tempo-ingester:4317 # <1>
@@ -52,11 +66,11 @@ The OTLP gRPC Exporter exports traces and metrics by using the OpenTelemetry pro
 
 The OTLP HTTP Exporter exports traces and metrics by using the OpenTelemetry protocol (OTLP).
 
-.OpenTelemetry Collector custom resource with an enabled OTLP Exporter
+.OpenTelemetry Collector custom resource with the enabled OTLP Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       otlphttp:
         endpoint: http://tempo-ingester:4318 # <1>
@@ -83,11 +97,11 @@ The OTLP HTTP Exporter exports traces and metrics by using the OpenTelemetry pro
 
 The Debug Exporter prints traces and metrics to the standard output.
 
-.OpenTelemetry Collector custom resource with an enabled Debug Exporter
+.OpenTelemetry Collector custom resource with the enabled Debug Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       debug:
         verbosity: detailed # <1>
@@ -115,11 +129,11 @@ The Load Balancing Exporter consistently exports spans, metrics, and logs accord
 :FeatureName: The Load Balancing Exporter
 include::snippets/technology-preview.adoc[leveloffset=+1]
 
-.OpenTelemetry Collector custom resource with an enabled Load Balancing Exporter
+.OpenTelemetry Collector custom resource with the enabled Load Balancing Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       loadbalancing:
         routing_key: "service" # <1>
@@ -155,11 +169,11 @@ The Prometheus Exporter exports metrics in the Prometheus or OpenMetrics formats
 :FeatureName: The Prometheus Exporter
 include::snippets/technology-preview.adoc[]
 
-.OpenTelemetry Collector custom resource with an enabled Prometheus Exporter
+.OpenTelemetry Collector custom resource with the enabled Prometheus Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       prometheus:
         endpoint: 0.0.0.0:8889 # <1>
@@ -204,11 +218,11 @@ The Prometheus Remote Write Exporter exports metrics to compatible back ends.
 :FeatureName: The Prometheus Remote Write Exporter
 include::snippets/technology-preview.adoc[]
 
-.OpenTelemetry Collector custom resource with an enabled Prometheus Remote Write Exporter
+.OpenTelemetry Collector custom resource with the enabled Prometheus Remote Write Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       prometheusremotewrite:
         endpoint: "https://my-prometheus:7900/api/v1/push" # <1>
@@ -246,11 +260,11 @@ The Kafka Exporter exports logs, metrics, and traces to Kafka. This exporter use
 :FeatureName: The Kafka Exporter
 include::snippets/technology-preview.adoc[]
 
-.OpenTelemetry Collector custom resource with an enabled Kafka Exporter
+.OpenTelemetry Collector custom resource with the enabled Kafka Exporter
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     exporters:
       kafka:
         brokers: ["localhost:9092"] # <1>
@@ -280,7 +294,197 @@ include::snippets/technology-preview.adoc[]
 <6> Disables verifying the server's certificate chain and host name. The default is `+false+`.
 <7> ServerName indicates the name of the server requested by the client to support virtual hosting.
 
+[id="aws-cloudwatch-exporter_{context}"]
+== AWS CloudWatch Logs Exporter
+
+The AWS CloudWatch Logs Exporter sends logs data to the Amazon CloudWatch Logs service and signs requests by using the AWS SDK for Go and the default credential provider chain.
+
+:FeatureName: The AWS CloudWatch Logs Exporter
+include::snippets/technology-preview.adoc[]
+
+.OpenTelemetry Collector custom resource with the enabled AWS CloudWatch Logs Exporter
+[source,yaml]
+----
+# ...
+  config:
+    exporters:
+      awscloudwatchlogs:
+        log_group_name: "<group_name_of_amazon_cloudwatch_logs>" # <1>
+        log_stream_name: "<log_stream_of_amazon_cloudwatch_logs>" # <2>
+        region: <aws_region_of_log_stream> # <3>
+        endpoint: <service_endpoint_of_amazon_cloudwatch_logs> # <4>
+        log_retention: <supported_value_in_days> # <5>
+# ...
+----
+<1> Required. If the log group does not exist yet, it is automatically created.
+<2> Required. If the log stream does not exist yet, it is automatically created.
+<3> Optional. If the AWS region is not already set in the default credential chain, you must specify it.
+<4> Optional. You can override the default Amazon CloudWatch Logs service endpoint to which the requests are forwarded. For the list of service endpoints by region, see link:https://docs.aws.amazon.com/general/latest/gr/cwl_region.html[Amazon CloudWatch Logs endpoints and quotas] (AWS General Reference).
+<5> Optional. With this parameter, you can set the log retention policy for new Amazon CloudWatch log groups. If this parameter is omitted or set to `0`, the logs never expire by default. Supported values for retention in days are `1`, `3`, `5`, `7`, `14`, `30`, `60`, `90`, `120`, `150`, `180`, `365`, `400`, `545`, `731`, `1827`, `2192`, `2557`, `2922`, `3288`, or `3653`.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html[What is Amazon CloudWatch Logs?] (Amazon CloudWatch Logs User Guide)
+* link:https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials[Specifying Credentials] (AWS SDK for Go Developer Guide)
+// * link:https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/configure-auth.html[Configure Authentication] (AWS SDK for Go v2 Developer Guide)
+* link:https://docs.aws.amazon.com/general/latest/gr/cwl_region.html[Amazon CloudWatch Logs endpoints and quotas] (AWS General Reference)
+
+[id="aws-emf-exporter_{context}"]
+== AWS EMF Exporter
+
+The AWS EMF Exporter converts the following OpenTelemetry metrics datapoints to the AWS CloudWatch Embedded Metric Format (EMF):
+
+- `Int64DataPoints`
+- `DoubleDataPoints`
+- `SummaryDataPoints`
+
+The EMF metrics are then sent directly to the Amazon CloudWatch Logs service by using the `PutLogEvents` API.
+
+One of the benefits of using this exporter is the possibility to view logs and metrics in the Amazon CloudWatch console at link:https://console.aws.amazon.com/cloudwatch/[].
+
+:FeatureName: The AWS EMF Exporter
+include::snippets/technology-preview.adoc[]
+
+.OpenTelemetry Collector custom resource with the enabled AWS EMF Exporter
+[source,yaml]
+----
+# ...
+  config:
+    exporters:
+      awsemf:
+        log_group_name: "<group_name_of_amazon_cloudwatch_logs>" # <1>
+        log_stream_name: "<log_stream_of_amazon_cloudwatch_logs>" # <2>
+        resource_to_telemetry_conversion: # <3>
+          enabled: true
+        region: <region> # <4>
+        endpoint: <endpoint> # <5>
+        log_retention: <supported_value_in_days> # <6>
+        namespace: <custom_namespace> # <7>
+# ...
+----
+<1> Customized log group name.
+<2> Customized log stream name.
+<3> Optional. Converts resource attributes to telemetry attributes such as metric labels. Disabled by default.
+<4> The AWS region of the log stream. If a region is not already set in the default credential provider chain, you must specify the region.
+<5> Optional. You can override the default Amazon CloudWatch Logs service endpoint to which the requests are forwarded. For the list of service endpoints by region, see link:https://docs.aws.amazon.com/general/latest/gr/cwl_region.html[Amazon CloudWatch Logs endpoints and quotas] (AWS General Reference).
+<6> Optional. With this parameter, you can set the log retention policy for new Amazon CloudWatch log groups. If this parameter is omitted or set to `0`, the logs never expire by default. Supported values for retention in days are `1`, `3`, `5`, `7`, `14`, `30`, `60`, `90`, `120`, `150`, `180`, `365`, `400`, `545`, `731`, `1827`, `2192`, `2557`, `2922`, `3288`, or `3653`.
+<7> Optional. A custom namespace for the Amazon CloudWatch metrics.
+
+[discrete]
+[id="log-group-name_{context}"]
+=== Log group name
+
+The `log_group_name` parameter allows you to customize the log group name and supports the default `+/metrics/default+` value or the following placeholders:
+
+`+/aws/metrics/{ClusterName}+`:: This placeholder is used to search for the `ClusterName` or `+aws.ecs.cluster.name+` resource attribute in the metrics data and replace it with the actual cluster name.
+
+`+{NodeName}+`:: This placeholder is used to search for the `NodeName` or `+k8s.node.name+` resource attribute.
+
+`+{TaskId}+`:: This placeholder is used to search for the `TaskId` or `+aws.ecs.task.id+` resource attribute.
+
+If no resource attribute is found in the resource attribute map, the placeholder is replaced by the `undefined` value.
+
+[discrete]
+[id="log-stream-name_{context}"]
+=== Log stream name
+
+The `log_stream_name` parameter allows you to customize the log stream name and supports the default `+otel-stream+` value or the following placeholders:
+
+`+{ClusterName}+`:: This placeholder is used to search for the `+ClusterName+` or `+aws.ecs.cluster.name+` resource attribute.
+
+`+{ContainerInstanceId}+`:: This placeholder is used to search for the `+ContainerInstanceId+` or `+aws.ecs.container.instance.id+` resource attribute. This resource attribute is valid only for the AWS ECS EC2 launch type.
+
+`+{NodeName}+`:: This placeholder is used to search for the `+NodeName+` or `+k8s.node.name+` resource attribute.
+
+`+{TaskDefinitionFamily}+`:: This placeholder is used to search for the `+TaskDefinitionFamily+` or `+aws.ecs.task.family+` resource attribute.
+
+`+{TaskId}+`:: This placeholder is used to search for the `TaskId` or `+aws.ecs.task.id+` resource attribute in the metrics data and replace it with the actual task ID.
+
+If no resource attribute is found in the resource attribute map, the placeholder is replaced by the `undefined` value.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html[Specification: Embedded metric format] (Amazon CloudWatch User Guide)
+* link:https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html[PutLogEvents] (Amazon CloudWatch Logs API Reference)
+* link:https://docs.aws.amazon.com/general/latest/gr/cwl_region.html[Amazon CloudWatch Logs endpoints and quotas] (AWS General Reference)
+
+[id="aws-xray-exporter_{context}"]
+== AWS X-Ray Exporter
+
+The AWS X-Ray Exporter converts OpenTelemetry spans to AWS X-Ray Segment Documents and then sends them directly to the AWS X-Ray service. The AWS X-Ray Exporter uses the `PutTraceSegments` API and signs requests by using the AWS SDK for Go and the default credential provider chain.
+
+:FeatureName: The AWS X-Ray Exporter
+include::snippets/technology-preview.adoc[]
+
+.OpenTelemetry Collector custom resource with the enabled AWS X-Ray Exporter
+[source,yaml]
+----
+# ...
+  config:
+    exporters:
+      awsxray:
+        region: "<region>" # <1>
+        endpoint: <endpoint> # <2>
+        resource_arn: "<aws_resource_arn>" # <3>
+        role_arn: "<iam_role>" # <4>
+        indexed_attributes: [ "<indexed_attr_0>", "<indexed_attr_1>" ] # <5>
+        aws_log_groups: ["<group1>", "<group2>"] # <6>
+        request_timeout_seconds: 120 # <7>
+# ...
+----
+<1> The destination region for the X-Ray segments sent to the AWS X-Ray service. For example, `eu-west-1`.
+<2> Optional. You can override the default Amazon CloudWatch Logs service endpoint to which the requests are forwarded. For the list of service endpoints by region, see link:https://docs.aws.amazon.com/general/latest/gr/cwl_region.html[Amazon CloudWatch Logs endpoints and quotas] (AWS General Reference).
+<3> The Amazon Resource Name (ARN) of the AWS resource that is running the Collector.
+<4> The AWS Identity and Access Management (IAM) role for uploading the X-Ray segments to a different account.
+<5> The list of attribute names to be converted to X-Ray annotations.
+<6> The list of log group names for Amazon CloudWatch Logs.
+<7> Time duration in seconds before timing out a request. If omitted, the default value is `30`.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html[What is AWS X-Ray?] (AWS X-Ray Developer Guide)
+* link:https://docs.aws.amazon.com/sdk-for-go/api/index.html[AWS SDK for Go API Reference] (AWS Documentation)
+* link:https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials[Specifying Credentials] (AWS SDK for Go Developer Guide)
+// * link:https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/configure-auth.html[Configure Authentication] (AWS SDK for Go v2 Developer Guide)
+* link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html[IAM roles] (AWS Identity and Access Management User Guide)
+
+[id="file-exporter_{context}"]
+== File Exporter
+
+The File Exporter writes telemetry data to files in persistent storage and supports file operations such as rotation, compression, and writing to multiple files. With this exporter, you can also use a resource attribute to control file naming. The only required setting is `path`, which specifies the destination path for telemetry files in the persistent-volume file system.
+
+:FeatureName: The File Exporter
+include::snippets/technology-preview.adoc[]
+
+.OpenTelemetry Collector custom resource with the enabled File Exporter
+[source,yaml]
+----
+# ...
+  config: |
+    exporters:
+      file:
+        path: /data/metrics.json # <1>
+        rotation: # <2>
+          max_megabytes: 10 # <3>
+          max_days: 3 # <4>
+          max_backups: 3 # <5>
+          localtime: true # <6>
+        format: proto # <7>
+        compression: zstd # <8>
+        flush_interval: 5 # <9>
+# ...
+----
+<1> The file-system path where the data is to be written. There is no default.
+<2> File rotation is an optional feature of this exporter. By default, telemetry data is exported to a single file. Add the `rotation` setting to enable file rotation.
+<3> The `max_megabytes` setting is the maximum size a file is allowed to reach until it is rotated. The default is `100`.
+<4> The `max_days` setting is for how many days a file is to be retained, counting from the timestamp in the file name. There is no default.
+<5> The `max_backups` setting is for retaining several older files. The defalt is `100`.
+<6> The `localtime` setting specifies the local-time format for the timestamp, which is appended to the file name in front of any extension, when the file is rotated. The default is the Coordinated Universal Time (UTC).
+<7> The format for encoding the telemetry data before writing it to a file. The default format is `json`. The `proto` format is also supported.
+<8> File compression is optional and not set by default. This setting defines the compression algorithm for the data that is exported to a file. Currently, only the `zstd` compression algorithm is supported. There is no default.
+<9> The time interval between flushes. A value without a unit is set in nanoseconds. This setting is ignored when file rotation is enabled through the `rotation` settings.
+
 [role="_additional-resources"]
 [id="additional-resources_otel-collector-exporters_{context}"]
 == Additional resources
-* link:https://opentelemetry.io/docs/specs/otlp/[OpenTelemetry Protocol (OTLP) documentation]
\ No newline at end of file
+* link:https://opentelemetry.io/docs/specs/otlp/[OpenTelemetry Protocol (OTLP) documentation]
diff --git a/observability/otel/otel-collector/otel-collector-extensions.adoc b/observability/otel/otel-collector/otel-collector-extensions.adoc
index 07c71497d4d0..f079e5d31bdc 100644
--- a/observability/otel/otel-collector/otel-collector-extensions.adoc
+++ b/observability/otel/otel-collector/otel-collector-extensions.adoc
@@ -8,6 +8,17 @@ toc::[]
 
 Extensions add capabilities to the Collector. For example, authentication can be added to the receivers and exporters automatically.
 
+Currently, the following General Availability and Technology Preview extensions are available for the {OTELShortName}:
+
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#bearertokenauth-extension_otel-collector-extensions[BearerTokenAuth Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#oauth2client-extension_otel-collector-extensions[OAuth2Client Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#filestorage-extension_otel-collector-extensions[File Storage Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#oidcauth-extension_otel-collector-extensions[OIDC Auth Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#jaegerremotesampling-extension_otel-collector-extensions[Jaeger Remote Sampling Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#pprof-extension_otel-collector-extensions[Performance Profiler Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#healthcheck-extension_otel-collector-extensions[Health Check Extension]
+- xref:../../../observability/otel/otel-collector/otel-collector-extensions.adoc#zpages-extension_otel-collector-extensions[zPages Extension]
+
 [id="bearertokenauth-extension_{context}"]
 == BearerTokenAuth Extension
 
@@ -19,7 +30,7 @@ This extension supports traces, metrics, and logs.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       bearertokenauth:
         scheme: "Bearer" # <1>
@@ -65,7 +76,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       oauth2client:
         client_id: <client_id> # <1>
@@ -125,7 +136,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       file_storage/all_settings:
         directory: /var/lib/otelcol/mydir # <1>
@@ -171,7 +182,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       oidc:
         attribute: authorization # <1>
@@ -186,14 +197,13 @@ include::snippets/technology-preview.adoc[]
             auth:
               authenticator: oidc
     exporters:
-      otlp:
-        endpoint: <endpoint>
+      debug: {}
     service:
       extensions: [oidc]
       pipelines:
         traces:
           receivers: [otlp]
-          exporters: [otlp]
+          exporters: [debug]
 # ...
 ----
 <1> The name of the header that contains the ID token. The default name is `authorization`.
@@ -214,7 +224,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       jaegerremotesampling:
         source:
@@ -229,14 +239,14 @@ include::snippets/technology-preview.adoc[]
           http: {}
 
     exporters:
-      otlp:
+      debug: {}
 
     service:
       extensions: [jaegerremotesampling]
       pipelines:
         traces:
           receivers: [otlp]
-          exporters: [otlp]
+          exporters: [debug]
 # ...
 ----
 <1> The time interval at which the sampling configuration is updated.
@@ -302,7 +312,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       pprof:
         endpoint: localhost:1777 # <1>
@@ -316,14 +326,14 @@ include::snippets/technology-preview.adoc[]
           http: {}
 
     exporters:
-      otlp:
+      debug: {}
 
     service:
       extensions: [pprof]
       pipelines:
         traces:
           receivers: [otlp]
-          exporters: [otlp]
+          exporters: [debug]
 # ...
 ----
 <1> The endpoint at which this extension listens. Use `localhost:` to make it available only locally or `":"` to make it available on all network interfaces. The default value is `localhost:1777`.
@@ -343,7 +353,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       health_check:
         endpoint: "0.0.0.0:13133" # <1>
@@ -363,14 +373,14 @@ include::snippets/technology-preview.adoc[]
           http: {}
 
     exporters:
-      otlp:
+      debug: {}
 
     service:
       extensions: [health_check]
       pipelines:
         traces:
           receivers: [otlp]
-          exporters: [otlp]
+          exporters: [debug]
 # ...
 ----
 <1> The target IP address for publishing the health check status. The default is `0.0.0.0:13133`.
@@ -394,7 +404,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     extensions:
       zpages:
         endpoint: "localhost:55679" # <1>
@@ -404,7 +414,7 @@ include::snippets/technology-preview.adoc[]
         protocols:
           http: {}
     exporters:
-      debug:
+      debug: {}
 
     service:
       extensions: [zpages]
diff --git a/observability/otel/otel-collector/otel-collector-processors.adoc b/observability/otel/otel-collector/otel-collector-processors.adoc
index 29bb641b18bf..0cd15cef0e26 100644
--- a/observability/otel/otel-collector/otel-collector-processors.adoc
+++ b/observability/otel/otel-collector/otel-collector-processors.adoc
@@ -8,6 +8,21 @@ toc::[]
 
 Processors process the data between it is received and exported. Processors are optional. By default, no processors are enabled. Processors must be enabled for every data source. Not all processors support all data sources. Depending on the data source, multiple processors might be enabled. Note that the order of processors matters.
 
+Currently, the following General Availability and Technology Preview processors are available for the {OTELShortName}:
+
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#batch-processor_otel-collector-processors[Batch Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#memorylimiter-processor_otel-collector-processors[Memory Limiter Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#resource-detection-processor_otel-collector-processors[Resource Detection Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#attributes-processor_otel-collector-processors[Attributes Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#resource-processor_otel-collector-processors[Resource Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#span-processor_otel-collector-processors[Span Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#kubernetes-attributes-processor_otel-collector-processors[Kubernetes Attributes Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#filter-processor_otel-collector-processors[Filter Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#routing-processor_otel-collector-processors[Routing Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#cumulativetodelta-processor_otel-collector-processors[Cumulative-to-Delta Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#groupbyattrsprocessor-processor_otel-collector-processors[Group-by-Attributes Processor]
+- xref:../../../observability/otel/otel-collector/otel-collector-processors.adoc#transform-processor_otel-collector-processors[Transform Processor]
+
 [id="batch-processor_{context}"]
 == Batch Processor
 
@@ -17,7 +32,7 @@ The Batch Processor batches traces and metrics to reduce the number of outgoing
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       batch:
         timeout: 5s
@@ -67,7 +82,7 @@ The Memory Limiter Processor periodically checks the Collector's memory usage an
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       memory_limiter:
         check_interval: 1s
@@ -135,7 +150,7 @@ rules:
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       resourcedetection:
         detectors: [openshift]
@@ -153,7 +168,7 @@ rules:
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       resourcedetection/env:
         detectors: [env] # <1>
@@ -191,7 +206,7 @@ Convert:: Converts an existing attribute to a specified type.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       attributes/example:
         actions:
@@ -228,7 +243,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       attributes:
       - key: cloud.availability_zone
@@ -258,7 +273,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       span:
         name:
@@ -275,7 +290,7 @@ You can use this processor to extract attributes from the span name.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       span/to_attributes:
         name:
@@ -292,7 +307,7 @@ You can have the span status modified.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
       span/set_status:
         status:
@@ -325,7 +340,7 @@ rules:
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     processors:
          k8sattributes:
              filter:
@@ -345,12 +360,12 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-config: |
-  processors:
-    filter/ottl:
-      error_mode: ignore # <1>
-      traces:
-        span:
+  config:
+    processors:
+      filter/ottl:
+        error_mode: ignore # <1>
+        traces:
+          span:
           - 'attributes["container.name"] == "app_container_1"' # <2>
           - 'resource.attributes["host.name"] == "localhost"' # <3>
 # ...
@@ -371,20 +386,20 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-config: |
-  processors:
-    routing:
-      from_attribute: X-Tenant # <1>
-      default_exporters: # <2>
-      - jaeger
-      table: # <3>
-      - value: acme
-        exporters: [jaeger/acme]
-  exporters:
-    jaeger:
-      endpoint: localhost:14250
-    jaeger/acme:
-      endpoint: localhost:24250
+  config:
+    processors:
+      routing:
+        from_attribute: X-Tenant # <1>
+        default_exporters: # <2>
+        - jaeger
+        table: # <3>
+        - value: acme
+          exporters: [jaeger/acme]
+    exporters:
+      jaeger:
+        endpoint: localhost:14250
+      jaeger/acme:
+        endpoint: localhost:24250
 # ...
 ----
 <1> The HTTP header name for the lookup value when performing the route.
@@ -409,18 +424,18 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-config: |
-  processors:
-    cumulativetodelta:
-      include: # <1>
-        match_type: strict # <2>
-        metrics: # <3>
-        - <metric_1_name>
-        - <metric_2_name>
-      exclude: # <4>
-        match_type: regexp
-        metrics:
-        - "<regular_expression_for_metric_names>"
+  config:
+    processors:
+      cumulativetodelta:
+        include: # <1>
+          match_type: strict # <2>
+          metrics: # <3>
+          - <metric_1_name>
+          - <metric_2_name>
+        exclude: # <4>
+          match_type: regexp
+          metrics:
+          - "<regular_expression_for_metric_names>"
 # ...
 ----
 <1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
@@ -441,11 +456,12 @@ At minimum, configuring this processor involves specifying an array of attribute
 [source,yaml]
 ----
 # ...
-processors:
-  groupbyattrs:
-    keys: # <1>
-      - <key1> # <2>
-      - <key2>
+  config:
+    processors:
+      groupbyattrs:
+        keys: # <1>
+          - <key1> # <2>
+          - <key2>
 # ...
 ----
 <1> Specifies attribute keys to group by.
@@ -469,24 +485,24 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-config: |
-  processors:
-    transform:
-      error_mode: ignore # <1>
-      <trace|metric|log>_statements: # <2>
-        - context: <string> # <3>
-          conditions:  # <4>
-            - <string>
-            - <string>
-          statements: # <5>
-            - <string>
-            - <string>
-            - <string>
-        - context: <string>
-          statements:
-            - <string>
-            - <string>
-            - <string>
+config:
+    processors:
+      transform:
+        error_mode: ignore # <1>
+        <trace|metric|log>_statements: # <2>
+          - context: <string> # <3>
+            conditions:  # <4>
+              - <string>
+              - <string>
+            statements: # <5>
+              - <string>
+              - <string>
+              - <string>
+          - context: <string>
+            statements:
+              - <string>
+              - <string>
+              - <string>
 # ...
 ----
 <1> Optional: See the following table "Values for the optional `error_mode` field".
@@ -498,23 +514,23 @@ config: |
 [source,yaml]
 ----
 # ...
-config: |
-  transform:
-    error_mode: ignore
-    trace_statements: # <1>
-      - context: resource
-        statements:
-          - keep_keys(attributes, ["service.name", "service.namespace", "cloud.region", "process.command_line"]) # <2>
-          - replace_pattern(attributes["process.command_line"], "password\\=[^\\s]*(\\s?)", "password=***") # <3>
-          - limit(attributes, 100, [])
-          - truncate_all(attributes, 4096)
-      - context: span # <4>
-        statements:
-          - set(status.code, 1) where attributes["http.path"] == "/health"
-          - set(name, attributes["http.route"])
-          - replace_match(attributes["http.target"], "/user/*/list/*", "/user/{userId}/list/{listId}")
-          - limit(attributes, 100, [])
-          - truncate_all(attributes, 4096)
+  config:
+    transform:
+      error_mode: ignore
+      trace_statements: # <1>
+        - context: resource
+          statements:
+            - keep_keys(attributes, ["service.name", "service.namespace", "cloud.region", "process.command_line"]) # <2>
+            - replace_pattern(attributes["process.command_line"], "password\\=[^\\s]*(\\s?)", "password=***") # <3>
+            - limit(attributes, 100, [])
+            - truncate_all(attributes, 4096)
+        - context: span # <4>
+          statements:
+            - set(status.code, 1) where attributes["http.path"] == "/health"
+            - set(name, attributes["http.route"])
+            - replace_match(attributes["http.target"], "/user/*/list/*", "/user/{userId}/list/{listId}")
+            - limit(attributes, 100, [])
+            - truncate_all(attributes, 4096)
 # ...
 ----
 <1> Transforms a trace signal.
diff --git a/observability/otel/otel-collector/otel-collector-receivers.adoc b/observability/otel/otel-collector/otel-collector-receivers.adoc
index 26e78ecaa152..b3d04a9395a6 100644
--- a/observability/otel/otel-collector/otel-collector-receivers.adoc
+++ b/observability/otel/otel-collector/otel-collector-receivers.adoc
@@ -8,6 +8,23 @@ toc::[]
 
 Receivers get data into the Collector. A receiver can be push or pull based. Generally, a receiver accepts data in a specified format, translates it into the internal format, and passes it to processors and exporters defined in the applicable pipelines. By default, no receivers are configured. One or more receivers must be configured. Receivers may support one or more data sources.
 
+Currently, the following General Availability and Technology Preview receivers are available for the {OTELShortName}:
+
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#otlp-receiver_otel-collector-receivers[OTLP Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#jaeger-receiver_otel-collector-receivers[Jaeger Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#hostmetrics-receiver_otel-collector-receivers[Host Metrics Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#k8sobjectsreceiver-receiver_otel-collector-receivers[Kubernetes Objects Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#kubeletstats-receiver_otel-collector-receivers[Kubelet Stats Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#prometheus-receiver_otel-collector-receivers[Prometheus Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#otlpjsonfile-receiver_otel-collector-receivers[OTLP JSON File Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#zipkin-receiver_otel-collector-receivers[Zipkin Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#kafka-receiver_otel-collector-receivers[Kafka Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#k8scluster-receiver_otel-collector-receivers[Kubernetes Cluster Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#opencensus-receiver_otel-collector-receivers[OpenCensus Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#filelog-receiver_otel-collector-receivers[Filelog Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#journald-receiver_otel-collector-receivers[Journald Receiver]
+- xref:../../../observability/otel/otel-collector/otel-collector-receivers.adoc#kubernetesevents-receiver_otel-collector-receivers[Kubernetes Events Receiver]
+
 [id="otlp-receiver_{context}"]
 == OTLP Receiver
 
@@ -18,7 +35,7 @@ The OTLP Receiver ingests traces and metrics using the OpenTelemetry protocol (O
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       otlp:
         protocols:
@@ -32,7 +49,7 @@ The OTLP Receiver ingests traces and metrics using the OpenTelemetry protocol (O
               reload_interval: 1h # <4>
           http:
             endpoint: 0.0.0.0:4318 # <5>
-            tls: # <6>
+            tls: {} # <6>
 
     service:
       pipelines:
@@ -58,7 +75,7 @@ The Jaeger Receiver ingests traces in the Jaeger formats.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
@@ -70,7 +87,7 @@ The Jaeger Receiver ingests traces in the Jaeger formats.
             endpoint: 0.0.0.0:6831 # <3>
           thrift_binary:
             endpoint: 0.0.0.0:6832 # <4>
-          tls: # <5>
+          tls: {} # <5>
 
     service:
       pipelines:
@@ -89,9 +106,6 @@ The Jaeger Receiver ingests traces in the Jaeger formats.
 
 The Host Metrics Receiver ingests metrics in the OTLP format.
 
-:FeatureName: The Host Metrics Receiver
-include::snippets/technology-preview.adoc[]
-
 .OpenTelemetry Collector custom resource with an enabled Host Metrics Receiver
 [source,yaml]
 ----
@@ -135,7 +149,7 @@ volumes:
 - projected
 # ...
 ---
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -151,16 +165,16 @@ spec:
     - hostPath:
         path: /
       name: host
-  config: |
+  config:
     receivers:
       hostmetrics:
         collection_interval: 10s # <1>
         initial_delay: 1s # <2>
         root_path: / # <3>
         scrapers: # <4>
-          cpu:
-          memory:
-          disk:
+          cpu: {}
+          memory: {}
+          disk: {}
     service:
       pipelines:
         metrics:
@@ -230,16 +244,15 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 # ...
 ---
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel-k8s-obj
   namespace: <namespace>
 spec:
   serviceAccount: otel-k8sobj
-  image: ghcr.io/os-observability/redhat-opentelemetry-collector/redhat-opentelemetry-collector:main
   mode: deployment
-  config: |
+  config:
     receivers:
       k8sobjects:
         auth_type: serviceAccount
@@ -273,29 +286,26 @@ spec:
 
 The Kubelet Stats Receiver extracts metrics related to nodes, pods, containers, and volumes from the kubelet's API server. These metrics are then channeled through the metrics-processing pipeline for additional analysis.
 
-:FeatureName: The Kubelet Stats Receiver
-include::snippets/technology-preview.adoc[]
-
 .OpenTelemetry Collector custom resource with an enabled Kubelet Stats Receiver
 [source,yaml]
 ----
 # ...
-config: |
-  receivers:
-    kubeletstats:
-      collection_interval: 20s
-      auth_type: "serviceAccount"
-      endpoint: "https://${env:K8S_NODE_NAME}:10250"
-      insecure_skip_verify: true
-  service:
-    pipelines:
-      metrics:
-        receivers: [kubeletstats]
-env:
-  - name: K8S_NODE_NAME # <1>
-    valueFrom:
-      fieldRef:
-        fieldPath: spec.nodeName
+  config:
+    receivers:
+      kubeletstats:
+        collection_interval: 20s
+        auth_type: "serviceAccount"
+        endpoint: "https://${env:K8S_NODE_NAME}:10250"
+        insecure_skip_verify: true
+    service:
+      pipelines:
+        metrics:
+          receivers: [kubeletstats]
+  env:
+    - name: K8S_NODE_NAME # <1>
+      valueFrom:
+        fieldRef:
+          fieldPath: spec.nodeName
 # ...
 ----
 <1> Sets the `K8S_NODE_NAME` to authenticate to the API.
@@ -332,7 +342,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
         prometheus:
           config:
@@ -364,7 +374,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     otlpjsonfile:
       include:
         - "/var/log/*.log" # <1>
@@ -384,11 +394,11 @@ The Zipkin Receiver ingests traces in the Zipkin v1 and v2 formats.
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       zipkin:
         endpoint: 0.0.0.0:9411 # <1>
-        tls: # <2>
+        tls: {} # <2>
     service:
       pipelines:
         traces:
@@ -410,7 +420,7 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       kafka:
         brokers: ["localhost:9092"] # <1>
@@ -452,20 +462,21 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-  receivers:
-    k8s_cluster:
-      distribution: openshift
-      collection_interval: 10s
-  exporters:
-    debug:
-  service:
-    pipelines:
-      metrics:
-        receivers: [k8s_cluster]
-        exporters: [debug]
-      logs/entity_events:
-        receivers: [k8s_cluster]
-        exporters: [debug]
+  config:
+    receivers:
+      k8s_cluster:
+        distribution: openshift
+        collection_interval: 10s
+    exporters:
+      debug: {}
+    service:
+      pipelines:
+        metrics:
+          receivers: [k8s_cluster]
+          exporters: [debug]
+        logs/entity_events:
+          receivers: [k8s_cluster]
+          exporters: [debug]
 # ...
 ----
 
@@ -589,7 +600,7 @@ The OpenCensus Receiver provides backwards compatibility with the OpenCensus pro
 [source,yaml]
 ----
 # ...
-  config: |
+  config:
     receivers:
       opencensus:
         endpoint: 0.0.0.0:9411 # <1>
@@ -620,17 +631,18 @@ include::snippets/technology-preview.adoc[]
 [source,yaml]
 ----
 # ...
-receivers:
-  filelog:
-    include: [ /simple.log ] # <1>
-    operators: # <2>
-      - type: regex_parser
-        regex: '^(?P<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (?P<sev>[A-Z]*) (?P<msg>.*)$'
-        timestamp:
-          parse_from: attributes.time
-          layout: '%Y-%m-%d %H:%M:%S'
-        severity:
-          parse_from: attributes.sev
+  config:
+    receivers:
+      filelog:
+        include: [ /simple.log ] # <1>
+        operators: # <2>
+          - type: regex_parser
+            regex: '^(?P<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (?P<sev>[A-Z]*) (?P<msg>.*)$'
+            timestamp:
+              parse_from: attributes.time
+              layout: '%Y-%m-%d %H:%M:%S'
+            severity:
+              parse_from: attributes.sev
 # ...
 ----
 <1> A list of file glob patterns that match the file paths to be read.
@@ -679,7 +691,7 @@ subjects:
   namespace: otel-journald
 # ...
 ---
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel-journald-logs
@@ -705,7 +717,7 @@ spec:
       type: spc_t
     seccompProfile:
       type: RuntimeDefault
-  config: |
+  config:
     receivers:
       journald:
         files: /var/log/journal/*/*
@@ -723,8 +735,7 @@ spec:
           max_elapsed_time: 5m # <7>
     processors:
     exporters:
-      debug:
-        verbosity: detailed
+      debug: {}
     service:
       pipelines:
         logs:
@@ -834,7 +845,7 @@ rules:
 ----
 # ...
   serviceAccount: otel-collector # <1>
-  config: |
+  config:
     receivers:
       k8s_events:
         namespaces: [project1, project2] # <2>
diff --git a/observability/otel/otel-collector/otel-collector-target-allocator.adoc b/observability/otel/otel-collector/otel-collector-target-allocator.adoc
index 25bca34e2e19..ed4480922310 100644
--- a/observability/otel/otel-collector/otel-collector-target-allocator.adoc
+++ b/observability/otel/otel-collector/otel-collector-target-allocator.adoc
@@ -14,7 +14,7 @@ include::snippets/technology-preview.adoc[]
 .Example OpenTelemetryCollector CR with the enabled Target Allocator
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -31,7 +31,7 @@ spec:
         name: app1
       podMonitorSelector: # <6>
         name: app2
-  config: |
+  config:
     receivers:
       prometheus: # <7>
         config:
@@ -69,11 +69,14 @@ rules:
     resources:
       - services
       - pods
+      - namespaces
     verbs: ["get", "list", "watch"]
   - apiGroups: ["monitoring.coreos.com"]
     resources:
       - servicemonitors
       - podmonitors
+      - scrapeconfigs
+      - probes
     verbs: ["get", "list", "watch"]
   - apiGroups: ["discovery.k8s.io"]
     resources:
diff --git a/observability/otel/otel-config-multicluster.adoc b/observability/otel/otel-config-multicluster.adoc
index 735a1c34d5e2..7f56183aff45 100644
--- a/observability/otel/otel-config-multicluster.adoc
+++ b/observability/otel/otel-config-multicluster.adoc
@@ -42,7 +42,7 @@ spec:
   commonName: ca
   subject:
     organizations:
-      - Organization # <your_organization_name>
+      - <your_organization_name>
     organizationalUnits:
       - Widgets
   secretName: ca-secret
@@ -159,7 +159,7 @@ roleRef:
 .Example `OpenTelemetryCollector` custom resource for the edge clusters
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
@@ -167,7 +167,7 @@ metadata:
 spec:
   mode: daemonset
   serviceAccount: otel-collector-deployment
-  config: |
+  config:
     receivers:
       jaeger:
         protocols:
@@ -219,7 +219,7 @@ spec:
 .Example `OpenTelemetryCollector` custom resource for the central cluster
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otlp-receiver
@@ -230,7 +230,7 @@ spec:
     type: route
     route:
       termination: "passthrough"
-  config: |
+  config:
     receivers:
       otlp:
         protocols:
@@ -240,7 +240,6 @@ spec:
               key_file: /certs/server.key
               client_ca_file: /certs/ca.crt
     exporters:
-      logging: {}
       otlp:
         endpoint: "tempo-<simplest>-distributor:4317" # <2>
         tls:
diff --git a/observability/otel/otel-configuration-of-instrumentation.adoc b/observability/otel/otel-configuration-of-instrumentation.adoc
index 6109eb97fba6..a534d46cc578 100644
--- a/observability/otel/otel-configuration-of-instrumentation.adoc
+++ b/observability/otel/otel-configuration-of-instrumentation.adoc
@@ -7,6 +7,7 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 
-The {OTELName} Operator uses a custom resource definition (CRD) file that defines the configuration of the instrumentation.
+The {OTELName} Operator uses an `Instrumentation` custom resource that defines the configuration of the instrumentation.
 
+include::modules/otel-autoinstrumentation.adoc[leveloffset=+1]
 include::modules/otel-config-instrumentation.adoc[leveloffset=+1]
diff --git a/observability/otel/otel-configuring-metrics-for-monitoring-stack.adoc b/observability/otel/otel-configuring-metrics-for-monitoring-stack.adoc
index 7c36bb042a5f..a92af420e5b0 100644
--- a/observability/otel/otel-configuring-metrics-for-monitoring-stack.adoc
+++ b/observability/otel/otel-configuring-metrics-for-monitoring-stack.adoc
@@ -18,14 +18,4 @@ include::modules/otel-config-receive-metrics-monitoring-stack.adoc[leveloffset=+
 [id="additional-resources_otel-configuring-metrics-for-monitoring-stack"]
 == Additional resources
 
-// * xref:../monitoring/accessing-third-party-monitoring-apis.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus[Querying metrics by using the federation endpoint for Prometheus]
-
-//* xref:../monitoring/accessing-third-party-monitoring-apis.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_accessing-third-party-monitoring-apis[Querying metrics by using the federation endpoint for Prometheus]
-
-//* xref:../monitoring/accessing-third-party-monitoring-apis.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus[Querying metrics by using the federation endpoint for Prometheus]
-
-//* xref:../monitoring/accessing-third-party-monitoring-apis.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_accessing-monitoring-apis-by-using-the-cli[Querying metrics by using the federation endpoint for Prometheus]
-
-//* xref:../monitoring/accessing-third-party-monitoring-apis.adoc#accessing-third-party-monitoring-apis_monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus[Querying metrics by using the federation endpoint for Prometheus]
-
-* xref:../monitoring/accessing-third-party-monitoring-apis.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_accessing-monitoring-apis-by-using-the-cli[Querying metrics by using the federation endpoint for Prometheus]
+* xref:../../observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc#monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_accessing-monitoring-apis-by-using-the-cli[Querying metrics by using the federation endpoint for Prometheus]
diff --git a/observability/otel/otel-configuring-otelcol-metrics.adoc b/observability/otel/otel-configuring-otelcol-metrics.adoc
index c0fe04a53016..261aab7dc41a 100644
--- a/observability/otel/otel-configuring-otelcol-metrics.adoc
+++ b/observability/otel/otel-configuring-otelcol-metrics.adoc
@@ -31,7 +31,7 @@ When the `spec.observability.metrics.enableMetrics` field in the `OpenTelemetryC
 +
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: <name>
@@ -50,4 +50,4 @@ You can use the *Administrator* view of the web console to verify successful con
 . Check that the *ServiceMonitors* or *PodMonitors* in the `opentelemetry-collector-<instance_name>` format have the *Up* status.
 
 .Additional resources
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
\ No newline at end of file
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
\ No newline at end of file
diff --git a/observability/otel/otel-forwarding-telemetry-data.adoc b/observability/otel/otel-forwarding-telemetry-data.adoc
index b8312364ba47..7dfa6219fa13 100644
--- a/observability/otel/otel-forwarding-telemetry-data.adoc
+++ b/observability/otel/otel-forwarding-telemetry-data.adoc
@@ -11,7 +11,9 @@ You can use the OpenTelemetry Collector to forward your telemetry data.
 include::modules/otel-forwarding-traces.adoc[leveloffset=+1]
 include::modules/otel-forwarding-logs-to-tempostack.adoc[leveloffset=+1]
 
+////
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../logging/log_storage/installing-log-storage.adoc#installing-log-storage[Installing LokiStack log storage]
+////
diff --git a/observability/otel/otel-migrating.adoc b/observability/otel/otel-migrating.adoc
index 3a87acc4a389..542b62e4a364 100644
--- a/observability/otel/otel-migrating.adoc
+++ b/observability/otel/otel-migrating.adoc
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:FeatureName: The {JaegerName}
-include::modules/deprecated-feature.adoc[]
+include::snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc[]
 
 If you are already using the {JaegerName} for your applications, you can migrate to the {OTELName}, which is based on the link:https://opentelemetry.io/[OpenTelemetry] open-source project.
 
diff --git a/observability/otel/otel-rn.adoc b/observability/otel/otel-rn.adoc
index b370ecf08456..3fd7fb28a448 100644
--- a/observability/otel/otel-rn.adoc
+++ b/observability/otel/otel-rn.adoc
@@ -12,6 +12,76 @@ You can use the {OTELName} xref:../../observability/otel/otel-forwarding-telemet
 
 include::snippets/distr-tracing-and-otel-disclaimer-about-docs-for-supported-features-only.adoc[]
 
+[id="otel_3-5_{context}"]
+== Release notes for {OTELName} 3.5
+
+The {OTELName} 3.5 is provided through the link:https://catalog.redhat.com/software/containers/rhosdt/opentelemetry-operator-bundle/615618406feffc5384e84400/history[{OTELOperator} 0.119.0].
+
+[NOTE]
+====
+The {OTELName} 3.5 is based on the open source link:https://opentelemetry.io/docs/collector/[OpenTelemetry] release 0.119.0.
+====
+
+////
+[id="otel_3-5_technology-preview-features_{context}"]
+=== Technology Preview features
+
+This update introduces the following Technology Preview features:
+
+* AWS CloudWatch Exporter
+* AWS EMF Exporter
+* AWS X-Ray Exporter
+
+:FeatureName: Each of these features
+include::snippets/technology-preview.adoc[leveloffset=+1]
+////
+
+[id="otel_3-5_new-features-and-enhancements_{context}"]
+=== New features and enhancements
+
+This update introduces the following enhancements:
+
+* The following link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] features reach General Availability:
+** Host Metrics Receiver
+** Kubelet Stats Receiver
+* With this update, the OpenTelemetry Collector uses the OTLP HTTP Exporter to push logs to a LokiStack instance.
+* With this update, the Operator automatically creates RBAC rules for the Kubernetes Events Receiver (`k8sevents`), Kubernetes Cluster Receiver (`k8scluster`), and Kubernetes Objects Receiver (`k8sobjects`) if the Operator has sufficient permissions. For more information, see "Creating the required RBAC resources automatically" in _Configuring the Collector_.
+
+[id="otel_3-5_deprecated-functionality_{context}"]
+=== Deprecated functionality
+
+In the {OTELName} 3.5, the Loki Exporter, which is a temporary Technology Preview feature, is deprecated. The Loki Exporter is planned to be removed in the {OTELName} 3.6. If you currently use the Loki Exporter for the OpenShift Logging 6.1 or later, replace the Loki Exporter with the OTLP HTTP Exporter.
+
+:FeatureName: The Loki Exporter
+include::snippets/technology-preview.adoc[leveloffset=+1]
+
+////
+In the {OTELName} 3.5, ???. (link:https://issues.redhat.com/browse/TRACING-????/[TRACING-????])
+////
+
+////
+[id="otel_3-5_removal-notice_{context}"]
+=== Removal notice
+
+In the {OTELName} 3.5, the FEATURE has been removed. Bug fixes and support are provided only through the end of the 3.? lifecycle. As an alternative to the FEATURE for USE CASE, you can use the ALTERNATIVE instead.
+////
+
+[id="otel_3-5_bug-fixes_{context}"]
+=== Bug fixes
+
+This update introduces the following bug fix:
+
+* Before this update, manually created routes for the Collector services were unintentionally removed when the Operator pod was restarted. With this update, restarting the Operator pod does not result in the removal of the manually created routes.
+
+////
+[id="otel_3-5_known-issues_{context}"]
+=== Known issues
+
+There are currently known issues:
+
+* ???. (link:https://issues.redhat.com/browse/TRACING-????/[TRACING-????])
+////
+
 [id="otel_3-4_{context}"]
 == Release notes for {OTELName} 3.4
 
@@ -91,7 +161,7 @@ This update introduces the following enhancements:
 ////
 
 ////
-[id="otel_3-3-1_jaeger-release-notes_deprecated-functionality_{context}"]
+[id="otel_3-3-1_deprecated-functionality_{context}"]
 === Deprecated functionality
 
 In the {OTELName} 3.3.1, ???. (link:https://issues.redhat.com/browse/TRACING-????/[TRACING-????])
@@ -158,7 +228,7 @@ This update introduces the following enhancements:
 * Support for automatically reloading certificates in both the OpenTelemetry Collector and instrumentation. (link:https://issues.redhat.com/browse/TRACING-4186[TRACING-4186])
 
 ////
-[id="otel_3-3_jaeger-release-notes_deprecated-functionality_{context}"]
+[id="otel_3-3_deprecated-functionality_{context}"]
 === Deprecated functionality
 
 In the {OTELName} 3.3, ???. (link:https://issues.redhat.com/browse/TRACING-????/[TRACING-????])
@@ -223,7 +293,7 @@ This update introduces the following enhancement:
 ////
 
 ////
-[id="otel_3-2-2_jaeger-release-notes_deprecated-functionality_{context}"]
+[id="otel_3-2-2_deprecated-functionality_{context}"]
 === Deprecated functionality
 
 In the {OTELName} 3.2.2, ...
@@ -285,7 +355,7 @@ This update introduces the following enhancement:
 * {OTELName} 3.2.1 is based on the open source link:https://opentelemetry.io/[OpenTelemetry] release 0.102.1.
 
 ////
-[id="otel_3-2-1_jaeger-release-notes_deprecated-functionality_{context}"]
+[id="otel_3-2-1_deprecated-functionality_{context}"]
 === Deprecated functionality
 
 In the {OTELName} 3.2.1, ...
@@ -356,7 +426,7 @@ This update introduces the following enhancement:
 
 * {OTELName} 3.2 is based on the open source link:https://opentelemetry.io/[OpenTelemetry] release 0.100.0.
 
-[id="otel_3-2_jaeger-release-notes_deprecated-functionality_{context}"]
+[id="otel_3-2_deprecated-functionality_{context}"]
 === Deprecated functionality
 
 In {OTELName} 3.2, use of empty values and `null` keywords in the OpenTelemetry Collector custom resource is deprecated and planned to be unsupported in a future release. Red Hat will provide bug fixes and support for this syntax during the current release lifecycle, but this syntax will become unsupported. As an alternative to empty values and `null` keywords, you can update the OpenTelemetry Collector custom resource to contain empty JSON objects as open-closed braces `{}` instead.
diff --git a/observability/otel/otel-troubleshooting.adoc b/observability/otel/otel-troubleshooting.adoc
index c2ebb838a65f..c0998a5af474 100644
--- a/observability/otel/otel-troubleshooting.adoc
+++ b/observability/otel/otel-troubleshooting.adoc
@@ -11,7 +11,7 @@ The OpenTelemetry Collector offers multiple ways to measure its health as well a
 include::modules/otel-troubleshoot-collecting-diagnostic-data-from-command-line.adoc[leveloffset=+1]
 include::modules/otel-troubleshoot-collector-logs.adoc[leveloffset=+1]
 include::modules/otel-troubleshoot-metrics.adoc[leveloffset=+1]
-include::modules/otel-troubleshoot-logging-exporter-stdout.adoc[leveloffset=+1]
+include::modules/otel-troubleshoot-debug-exporter-stdout.adoc[leveloffset=+1]
 include::modules/otel-troubleshoot-network-traffic.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -20,3 +20,14 @@ include::modules/otel-troubleshoot-network-traffic.adoc[leveloffset=+1]
 * xref:../../observability/network_observability/installing-operators.adoc#installing-network-observability-operators[Installing the Network Observability Operator]
 
 * xref:../../observability/network_observability/observing-network-traffic.adoc#nw-observe-network-traffic[Observing the network traffic from the Topology view]
+
+[id="troubleshooting_instrumentation_{context}"]
+== Troubleshooting the instrumentation
+
+To troubleshoot the instrumentation, look for any of the following issues:
+
+* Issues with instrumentation injection into your workload
+* Issues with data generation by the instrumentation libraries
+
+include::modules/otel-troubleshooting-instrumentation-injection-into-your-workload.adoc[leveloffset=+2]
+include::modules/otel-troubleshooting-telemetry-data-generation-by-the-instrumentation-libraries.adoc[leveloffset=+2]
diff --git a/observability/overview/index.adoc b/observability/overview/index.adoc
index 120618a14c74..8ccc9d605128 100644
--- a/observability/overview/index.adoc
+++ b/observability/overview/index.adoc
@@ -6,22 +6,22 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 {ObservabilityLongName} provides real-time visibility, monitoring, and analysis of various system metrics, logs, traces, and events to help users quickly diagnose and troubleshoot issues before they impact systems or applications. To help ensure the reliability, performance, and security of your applications and infrastructure, {product-title} offers the following {ObservabilityShortName} components:
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 {ObservabilityLongName} provides real-time visibility, monitoring, and analysis of various system metrics, logs, and events to help users quickly diagnose and troubleshoot issues before they impact systems or applications. To help ensure the reliability, performance, and security of your applications and infrastructure, {product-title} offers the following {ObservabilityShortName} components:
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 * Monitoring
 * {logging-uc}
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Distributed tracing
 * {OTELName}
 * Network Observability
 * {PM-shortname-c}
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 {ObservabilityLongName} connects open-source observability tools and technologies to create a unified {ObservabilityShortName} solution. The components of {ObservabilityLongName} work together to help you collect, store, deliver, analyze, and visualize data.
 
@@ -36,14 +36,18 @@ Monitor the in-cluster health and performance of your applications running on {p
 
 Monitoring stack components are deployed by default in every {product-title} installation and are managed by the {cmo-first}. These components include Prometheus, Alertmanager, Thanos Querier, and others. The {cmo-short} also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
 
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+For more information, see xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring] and xref:../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information, see xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview] and xref:../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="cluster-logging-index_{context}"]
 == Logging
 Collect, visualize, forward, and store log data to troubleshoot issues, identify performance bottlenecks, and detect security threats. In logging 5.7 and later versions, users can configure the LokiStack deployment to produce customized alerts and recorded metrics.
 
-For more information, see xref:../../observability/logging/cluster-logging.adoc#cluster-logging[About Logging].
-
 ifdef::openshift-enterprise,openshift-origin[]
 [id="distr-tracing-architecture-index_{context}"]
 == Distributed tracing
diff --git a/observability/power_monitoring/power-monitoring-overview.adoc b/observability/power_monitoring/power-monitoring-overview.adoc
index 3b420362ee08..8e5f61c8bd4f 100644
--- a/observability/power_monitoring/power-monitoring-overview.adoc
+++ b/observability/power_monitoring/power-monitoring-overview.adoc
@@ -15,7 +15,11 @@ include::modules/power-monitoring-kepler-architecture.adoc[leveloffset=+1]
 
 include::modules/power-monitoring-hardware-virtualization-support.adoc[leveloffset=+1]
 
+include::modules/power-monitoring-fips-support.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 [id="additional-resources_power-monitoring-overview"]
 == Additional resources
-* xref:../power_monitoring/visualizing-power-monitoring-metrics.adoc#power-monitoring-dashboards-overview_visualizing-power-monitoring-metrics[{PM-shortname-c} dashboards overview]
\ No newline at end of file
+* xref:../power_monitoring/visualizing-power-monitoring-metrics.adoc#power-monitoring-dashboards-overview_visualizing-power-monitoring-metrics[{PM-shortname-c} dashboards overview]
+
+* xref:../../installing/overview/installing-preparing.adoc#installing-preparing-security[Do you need extra security for your cluster?]
\ No newline at end of file
diff --git a/observability/power_monitoring/power-monitoring-release-notes.adoc b/observability/power_monitoring/power-monitoring-release-notes.adoc
index 89ce46aeee5a..5cf4e640c3b9 100644
--- a/observability/power_monitoring/power-monitoring-release-notes.adoc
+++ b/observability/power_monitoring/power-monitoring-release-notes.adoc
@@ -15,6 +15,34 @@ These release notes track the development of {PM-title} in the {product-title}.
 
 For an overview of the {PM-operator}, see xref:../power_monitoring/power-monitoring-overview.adoc#power-monitoring-about-power-monitoring_power-monitoring-overview[About {PM-shortname}].
 
+[id="power-monitoring-release-notes-0-4_{context}"]
+== {PM-shortname-c} 0.4 (Technology Preview)
+
+This release includes the following version updates:
+
+* {PM-kepler} 0.7.12
+* {PM-operator} 0.15.0
+
+
+[id="power-monitoring-0-4-features_{context}"]
+=== Features
+
+* With this release, FIPS mode is now enabled for {PM-title}. When installed on an {product-title} cluster in FIPS mode, {PM-operator} ensures compatibility without affecting the FIPS support status of the cluster.
+
+[id="power-monitoring-bug-fix-0-4_{context}"]
+=== Bug fixes
+
+* Before this update, the *Install* screen in the OperatorHub page for {PM-title} displayed incorrect documentation links. With this update, the links now direct to the correct paths.
+
+[id="power-monitoring-release-notes-0-4-cves_{context}"]
+=== CVEs
+
+* link:https://access.redhat.com/security/cve/CVE-2024-24790[CVE-2024-24790]
+* link:https://access.redhat.com/security/cve/CVE-2024-24791[CVE-2024-24791]
+* link:https://access.redhat.com/security/cve/CVE-2024-34155[CVE-2024-34155]
+* link:https://access.redhat.com/security/cve/CVE-2024-34158[CVE-2024-34158]
+
+
 [id="power-monitoring-release-notes-0-3"]
 == {PM-shortname-c} 0.3 (Technology Preview)
 
diff --git a/observability/power_monitoring/visualizing-power-monitoring-metrics.adoc b/observability/power_monitoring/visualizing-power-monitoring-metrics.adoc
index d8c1a9d09f21..fa9d9a100205 100644
--- a/observability/power_monitoring/visualizing-power-monitoring-metrics.adoc
+++ b/observability/power_monitoring/visualizing-power-monitoring-metrics.adoc
@@ -19,4 +19,4 @@ include::modules/power-monitoring-metrics-overview.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_visualizing-power-monitoring-metrics"]
 == Additional resources
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects_enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
\ No newline at end of file
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
\ No newline at end of file
diff --git a/ocm/ocm-overview.adoc b/ocm/ocm-overview.adoc
index 8f3dd247374f..39630927d5dd 100644
--- a/ocm/ocm-overview.adoc
+++ b/ocm/ocm-overview.adoc
@@ -69,7 +69,7 @@ include::modules/ocm-settings-tab.adoc[leveloffset=+2]
 == Additional resources
 
 * For the complete documentation for {cluster-manager}, see link:https://access.redhat.com/documentation/en-us/openshift_cluster_manager/2022/html-single/managing_clusters/index[{cluster-manager} documentation].
-ifdef::openshift-rosa,openshift-rosa-hcp,openshift-rosa-classic[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 * For steps to add cluster notification contacts, see xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding cluster notification contacts]
 endif::[]
 ifdef::openshift-dedicated[]
diff --git a/openshift_images/image-configuration.adoc b/openshift_images/image-configuration.adoc
index 0580146935dc..49666969cd05 100644
--- a/openshift_images/image-configuration.adoc
+++ b/openshift_images/image-configuration.adoc
@@ -10,6 +10,15 @@ Use the following procedure to configure image registries.
 
 include::modules/images-configuration-parameters.adoc[leveloffset=+1]
 
+ifndef::openshift-rosa,openshift-dedicated[]
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../openshift_images/image-streams-manage.adoc#images-imagestream-import-import-mode_image-streams-managing[Working with manifest lists]
+
+* xref:../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling-features-about_nodes-cluster-enabling[Understanding feature gates]
+endif::openshift-rosa,openshift-dedicated[]
+
 include::modules/images-configuration-file.adoc[leveloffset=+1]
 
 include::modules/images-configuration-allowed.adoc[leveloffset=+2]
diff --git a/openshift_images/image-streams-manage.adoc b/openshift_images/image-streams-manage.adoc
index d8ae16ba18fd..da4288117602 100644
--- a/openshift_images/image-streams-manage.adoc
+++ b/openshift_images/image-streams-manage.adoc
@@ -39,7 +39,7 @@ include::modules/images-imagestream-import.adoc[leveloffset=+2]
 The following sections describe how to import, and work with, image streams.
 
 include::modules/images-imagestream-import-images-private-registry.adoc[leveloffset=+2]
-include::modules/images-allow-pods-to-reference-images-from-secure-registries.adoc[leveloffset=+3]
+//include::modules/images-allow-pods-to-reference-images-from-secure-registries.adoc[leveloffset=+3]
 
 
 include::modules/images-imagestream-import-import-mode.adoc[leveloffset=+2]
diff --git a/openshift_images/index.adoc b/openshift_images/index.adoc
index 29f72fa965e3..1666c5eb163c 100644
--- a/openshift_images/index.adoc
+++ b/openshift_images/index.adoc
@@ -58,12 +58,12 @@ endif::openshift-rosa,openshift-dedicated[]
 == About templates
 
 A template is a definition of an object to be replicated.
-You can use xref:../openshift_images/using-templates.adoc#using-templates[templates] to build and deploy configurations.
+You can use xref:../applications/creating_applications/using-templates.adoc#using-templates[templates] to build and deploy configurations.
 
 [id="how-you-can-use-ruby-on-rails"]
 == How you can use Ruby on Rails
 
-As a developer, you can use xref:../openshift_images/templates-using-ruby-on-rails.adoc#templates-using-ruby-on-rails[Ruby on Rails] to:
+As a developer, you can use xref:../applications/creating_applications/templates-using-ruby-on-rails.adoc#templates-using-ruby-on-rails[Ruby on Rails] to:
 
 ** Write your application:
 *** Set up a database.
diff --git a/openshift_images/managing_images/using-image-pull-secrets.adoc b/openshift_images/managing_images/using-image-pull-secrets.adoc
index 563b8aa941c3..5c7e21aa1706 100644
--- a/openshift_images/managing_images/using-image-pull-secrets.adoc
+++ b/openshift_images/managing_images/using-image-pull-secrets.adoc
@@ -17,6 +17,8 @@ You use this pull secret to authenticate with the services that are provided by
 include::modules/images-allow-pods-to-reference-images-across-projects.adoc[leveloffset=+1]
 
 include::modules/images-allow-pods-to-reference-images-from-secure-registries.adoc[leveloffset=+1]
+include::modules/creating-pull-secrets.adoc[leveloffset=+2]
+include::modules/using-pull-secret.adoc[leveloffset=+2]
 
 include::modules/images-pulling-from-private-registries.adoc[leveloffset=+2]
 
diff --git a/operators/admin/olm-adding-operators-to-cluster.adoc b/operators/admin/olm-adding-operators-to-cluster.adoc
index 65bc5d6a1bb5..9d472b67d2da 100644
--- a/operators/admin/olm-adding-operators-to-cluster.adoc
+++ b/operators/admin/olm-adding-operators-to-cluster.adoc
@@ -10,12 +10,12 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 Using Operator Lifecycle Manager (OLM),
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can install OLM-based Operators to an {product-title} cluster.
 
 [NOTE]
@@ -45,7 +45,7 @@ include::modules/olm-installing-from-operatorhub-using-web-console.adoc[leveloff
 
 * xref:../../operators/admin/olm-upgrading-operators.adoc#olm-approving-pending-upgrade_olm-upgrading-operators[Manually approving a pending Operator update]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -89,13 +89,13 @@ include::modules/olm-pod-placement.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Adding taints and tolerations xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations-adding_nodes-scheduler-taints-tolerations[manually to nodes] or xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations-adding-machineset_nodes-scheduler-taints-tolerations[with compute machine sets]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors-project_nodes-scheduler-node-selectors[Creating project-wide node selectors]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations-projects_nodes-scheduler-taints-tolerations[Creating a project with a node selector and toleration]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 endif::[]
 
 include::modules/olm-overriding-operator-pod-affinity.adoc[leveloffset=+1]
@@ -106,6 +106,6 @@ include::modules/olm-overriding-operator-pod-affinity.adoc[leveloffset=+1]
 * xref:../../nodes/scheduling/nodes-scheduler-pod-affinity.adoc#nodes-scheduler-pod-affinity-about_nodes-scheduler-pod-affinity[Understanding pod affinity]
 * xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-about_nodes-scheduler-node-affinity[Understanding node affinity]
 // This xref points to a topic not currently included in the OSD and ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/admin/olm-configuring-proxy-support.adoc b/operators/admin/olm-configuring-proxy-support.adoc
index 85e18486e04e..6a597c3c9b6b 100644
--- a/operators/admin/olm-configuring-proxy-support.adoc
+++ b/operators/admin/olm-configuring-proxy-support.adoc
@@ -12,20 +12,30 @@ If a global proxy is configured on the {product-title} cluster, Operator Lifecyc
 .Additional resources
 
 // Configuring the cluster-wide proxy is a different topic in OSD/ROSA.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[Configuring the cluster-wide proxy]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../networking/configuring-cluster-wide-proxy.adoc[Configuring a cluster-wide proxy]
 endif::openshift-dedicated,openshift-rosa[]
 
 // This xref points to a topic that is not currently included in the OSD and ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../networking/configuring-a-custom-pki.adoc#configuring-a-custom-pki[Configuring a custom PKI] (custom CA certificate)
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 * Developing Operators that support proxy settings for xref:../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-run-proxy_osdk-golang-tutorial[Go], xref:../../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-run-proxy_osdk-ansible-tutorial[Ansible], and xref:../../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-run-proxy_osdk-helm-tutorial[Helm]
 
 
 include::modules/olm-overriding-proxy-settings.adoc[leveloffset=+1]
 include::modules/olm-injecting-custom-ca.adoc[leveloffset=+1]
+
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../security/certificate_types_descriptions/proxy-certificates.adoc#cert-types-proxy-certificates[Proxy certificates]
+* xref:../../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Replacing the default ingress certificate]
+* xref:../../security/certificates/updating-ca-bundle.adoc#updating-ca-bundle[Updating the CA bundle]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/admin/olm-cs-podsched.adoc b/operators/admin/olm-cs-podsched.adoc
index faef82038a7e..0c192fa82216 100644
--- a/operators/admin/olm-cs-podsched.adoc
+++ b/operators/admin/olm-cs-podsched.adoc
@@ -33,9 +33,9 @@ include::modules/disabling-catalogsource-objects.adoc[leveloffset=+1]
 
 * xref:../../operators/understanding/olm-understanding-operatorhub.adoc#olm-operatorhub-arch-operatorhub_crd_olm-understanding-operatorhub[OperatorHub custom resource]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../disconnected/using-olm.adoc#olm-restricted-networks-operatorhub_olm-restricted-networks[Disabling the default OperatorHub catalog sources]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-node-selector.adoc[leveloffset=+1]
 
@@ -55,9 +55,9 @@ include::modules/olm-tolerations.adoc[leveloffset=+1]
 
 // The following xref points to a topic that is not included in the OSD or
 // ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations-about_nodes-scheduler-taints-tolerations[Understanding taints and tolerations]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/admin/olm-deleting-operators-from-cluster.adoc b/operators/admin/olm-deleting-operators-from-cluster.adoc
index cfb8c4a7923e..18b72926ee7f 100644
--- a/operators/admin/olm-deleting-operators-from-cluster.adoc
+++ b/operators/admin/olm-deleting-operators-from-cluster.adoc
@@ -12,9 +12,9 @@ The following describes how to delete, or uninstall, Operators that were previou
 ====
 You must successfully and completely uninstall an Operator prior to attempting to reinstall the same Operator. Failure to fully uninstall the Operator properly can leave resources, such as a project or namespace, stuck in a "Terminating" state and cause "error resolving resource" messages to be observed when trying to reinstall the Operator.
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information, see xref:../../operators/admin/olm-troubleshooting-operator-issues.adoc#olm-reinstall_olm-troubleshooting-operator-issues[Reinstalling Operators after failed uninstallation].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ====
 
 include::modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc[leveloffset=+1]
diff --git a/operators/admin/olm-managing-custom-catalogs.adoc b/operators/admin/olm-managing-custom-catalogs.adoc
index 76cf18b9b261..290cde3bb89e 100644
--- a/operators/admin/olm-managing-custom-catalogs.adoc
+++ b/operators/admin/olm-managing-custom-catalogs.adoc
@@ -6,12 +6,12 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 and Operator catalog maintainers can create and manage custom catalogs packaged using the xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[bundle format] on Operator Lifecycle Manager (OLM) in {product-title}.
 
 [IMPORTANT]
@@ -29,7 +29,10 @@ If your cluster is using custom catalogs, see xref:../../operators/operator_sdk/
 [id="olm-managing-custom-catalogs-bundle-format-prereqs"]
 == Prerequisites
 
+// TODO-HCP remove conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * You have installed the xref:../../cli_reference/opm/cli-opm-install.adoc#cli-opm-install[`opm` CLI].
+endif::openshift-rosa-hcp[]
 
 [id="olm-managing-custom-catalogs-fb"]
 == File-based catalogs
@@ -43,29 +46,32 @@ As of {product-title} 4.11, the default Red Hat-provided Operator catalog releas
 The `opm` subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.
 
 Many of the `opm` subcommands and flags for working with the SQLite database format, such as `opm index prune`, do not work with the file-based catalog format.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format] and xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ====
 
 include::modules/olm-creating-fb-catalog-image.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
+// TODO-HCP remove conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../cli_reference/opm/cli-opm-ref.adoc#cli-opm-ref[`opm` CLI reference]
+endif::openshift-rosa-hcp[]
 
 include::modules/olm-filtering-fbc.adoc[leveloffset=+2]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../operators/understanding/olm-packaging-format.adoc#olm-deprecations-schema_olm-packaging-format[Packaging format -> Schemas -> olm.deprecations schema]
 * xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#updating-mirror-registry-content[Mirroring images for a disconnected installation using the oc-mirror plugin -> Keeping your mirror registry content updated]
 * xref:../../disconnected/using-olm.adoc#olm-creating-catalog-from-index_olm-restricted-networks[Adding a catalog source to a cluster]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="olm-managing-custom-catalogs-sqlite"]
 == SQLite-based catalogs
@@ -82,7 +88,10 @@ include::modules/olm-catalog-source-and-psa.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
+// TODO-HCP remove conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
+endif::openshift-rosa-hcp[]
 
 include::modules/olm-migrating-sqlite-catalog-to-fbc.adoc[leveloffset=+2]
 
@@ -100,14 +109,14 @@ include::modules/olm-creating-catalog-from-index.adoc[leveloffset=+1]
 .Additional resources
 
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource_olm-understanding-olm[Operator Lifecycle Manager concepts and resources -> Catalog source]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries]
 // This xref may be relevant to OSD/ROSA, but the topic is not currently included in the OSD and ROSA docs.
 * xref:../../openshift_images/managing_images/image-pull-policy.adoc#image-pull-policy[Image pull policy]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Exclude from OSD/ROSA - dedicated-admins can't create the necessary secrets to do this procedure.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-accessing-images-private-registries.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -116,17 +125,17 @@ include::modules/olm-accessing-images-private-registries.adoc[leveloffset=+1]
 * See xref:../../cicd/builds/creating-build-inputs.adoc#builds-secrets-overview_creating-build-inputs[What is a secret?] for more information on the types of secrets, including those used for registry credentials.
 * See xref:../../openshift_images/managing_images/using-image-pull-secrets.adoc#images-update-global-pull-secret_using-image-pull-secrets[Updating the global cluster pull secret] for more details on the impact of changing this secret.
 * See xref:../../openshift_images/managing_images/using-image-pull-secrets.adoc#images-allow-pods-to-reference-images-from-secure-registries_using-image-pull-secrets[Allowing pods to reference images from other secured registries] for more details on linking pull secrets to service accounts per namespace.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Exclude from OSD/ROSA - dedicated-admins can't do this procedure.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-restricted-networks-configuring-operatorhub.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Removing custom catalogs can be done as a dedicated-admin, but the steps are different.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-removing-catalogs.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/sd-olm-removing-catalogs.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
\ No newline at end of file
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/operators/admin/olm-managing-operatorconditions.adoc b/operators/admin/olm-managing-operatorconditions.adoc
index 1079c2d2f6d4..b7052be0a864 100644
--- a/operators/admin/olm-managing-operatorconditions.adoc
+++ b/operators/admin/olm-managing-operatorconditions.adoc
@@ -6,12 +6,12 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As a cluster administrator, you can manage Operator conditions by using Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As an administrator with the `dedicated-admin` role, you can manage Operator conditions by using Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-overriding-operatorconditions.adoc[leveloffset=+1]
 include::modules/olm-updating-use-operatorconditions.adoc[leveloffset=+1]
diff --git a/operators/admin/olm-status.adoc b/operators/admin/olm-status.adoc
index ee437f105c29..4849030b05ed 100644
--- a/operators/admin/olm-status.adoc
+++ b/operators/admin/olm-status.adoc
@@ -23,6 +23,6 @@ include::modules/olm-cs-status-cli.adoc[leveloffset=+1]
 
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource_olm-understanding-olm[Operator Lifecycle Manager concepts and resources -> Catalog source]
 * gRPC documentation: link:https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html[States of Connectivity]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/admin/olm-troubleshooting-operator-issues.adoc b/operators/admin/olm-troubleshooting-operator-issues.adoc
index 3ae7b624e775..e46c13c53eda 100644
--- a/operators/admin/olm-troubleshooting-operator-issues.adoc
+++ b/operators/admin/olm-troubleshooting-operator-issues.adoc
@@ -26,13 +26,13 @@ include::modules/olm-cs-status-cli.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource_olm-understanding-olm[Operator Lifecycle Manager concepts and resources -> Catalog source]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * gRPC documentation: link:https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html[States of Connectivity]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Querying Operator Pod status
 include::modules/querying-operator-pod-status.adoc[leveloffset=+1]
@@ -41,29 +41,29 @@ include::modules/querying-operator-pod-status.adoc[leveloffset=+1]
 include::modules/gathering-operator-logs.adoc[leveloffset=+1]
 
 // cannot patch resource "machineconfigpools"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // Disabling Machine Config Operator from autorebooting
 include::modules/troubleshooting-disabling-autoreboot-mco.adoc[leveloffset=+1]
 include::modules/troubleshooting-disabling-autoreboot-mco-console.adoc[leveloffset=+2]
 include::modules/troubleshooting-disabling-autoreboot-mco-cli.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Refreshing failing subscriptions
 // OSD/ROSA cannot delete resource "clusterserviceversions", "jobs" in API group "operators.coreos.com" in the namespace "openshift-apiserver"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-refresh-subs.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Reinstalling Operators after failed uninstallation
 // OSD/ROSA gitcannot delete resource "customresourcedefinitions"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/olm-reinstall.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster]
 * xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding Operators to a cluster]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/admin/olm-upgrading-operators.adoc b/operators/admin/olm-upgrading-operators.adoc
index 802ee925c1d6..7110e45fb723 100644
--- a/operators/admin/olm-upgrading-operators.adoc
+++ b/operators/admin/olm-upgrading-operators.adoc
@@ -7,10 +7,10 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 As
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 a cluster administrator,
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 an administrator with the `dedicated-admin` role,
 endif::[]
 you can update Operators that have been previously installed using Operator Lifecycle Manager (OLM) on your {product-title} cluster.
@@ -24,10 +24,10 @@ include::modules/olm-preparing-upgrade.adoc[leveloffset=+1]
 include::modules/olm-changing-update-channel.adoc[leveloffset=+1]
 include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+1]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_olm-upgrading-operators"]
 == Additional resources
 
 * xref:../../disconnected/using-olm.adoc#olm-restricted-networks[Using Operator Lifecycle Manager in disconnected environments]
-endif::openshift-dedicated,openshift-rosa[]
\ No newline at end of file
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/operators/index.adoc b/operators/index.adoc
index 082e98c777d6..af8ff4565885 100644
--- a/operators/index.adoc
+++ b/operators/index.adoc
@@ -15,59 +15,58 @@ As an Operator author, you can perform the following development tasks for OLM-b
 
 ** xref:../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Install Operator SDK CLI].
 // The Operator quickstarts aren't published for OSD/ROSA, so for OSD/ROSA, these xrefs point to the tutorials instead.
-ifndef::openshift-dedicated,openshift-rosa[]
-** Create xref:../operators/operator_sdk/golang/osdk-golang-quickstart.adoc#osdk-golang-quickstart[Go-based Operators], xref:../operators/operator_sdk/ansible/osdk-ansible-quickstart.adoc#osdk-ansible-quickstart[Ansible-based Operators], xref:../operators/operator_sdk/java/osdk-java-quickstart.adoc#osdk-java-quickstart[Java-based Operators], and xref:../operators/operator_sdk/helm/osdk-helm-quickstart.adoc#osdk-helm-quickstart[Helm-based Operators].
-endif::openshift-dedicated,openshift-rosa[]
-// TODO: When the Java-based Operators is GA, it can be added to the list below for OSD/ROSA.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+** Create xref:../operators/operator_sdk/golang/osdk-golang-quickstart.adoc#osdk-golang-quickstart[Go-based Operators], xref:../operators/operator_sdk/ansible/osdk-ansible-quickstart.adoc#osdk-ansible-quickstart[Ansible-based Operators], and xref:../operators/operator_sdk/helm/osdk-helm-quickstart.adoc#osdk-helm-quickstart[Helm-based Operators].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** Create xref:../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-golang-tutorial[Go-based Operators], xref:../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-ansible-tutorial[Ansible-based Operators], and xref:../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-helm-tutorial[Helm-based Operators].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/operator_sdk/osdk-about.adoc#osdk-about[Use Operator SDK to build, test, and deploy an Operator].
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/user/olm-installing-operators-in-namespace.adoc#olm-installing-operators-in-namespace[Install and subscribe an Operator to your namespace].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/user/olm-creating-apps-from-installed-operators.adoc#olm-creating-apps-from-installed-operators[Create an application from an installed Operator through the web console].
 
 // This xref could be relevant for OSD/ROSA, but the target doesn't currently exist in the OSD/ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-uses_deleting-machine[Machine deletion lifecycle hook examples for Operator developers]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="operators-overview-administrator-tasks_{context}"]
 == For administrators
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As a cluster administrator, you can perform the following administrative tasks for OLM-based Operators:
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As an administrator with the `dedicated-admin` role, you can perform the following Operator tasks:
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 ** xref:../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Manage custom catalogs].
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/admin/olm-creating-policy.adoc#olm-creating-policy[Allow non-cluster administrators to install Operators].
-endif::openshift-dedicated,openshift-rosa[]
-ifndef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/user/olm-installing-operators-in-namespace.adoc#olm-installing-operators-in-namespace[Install an Operator from OperatorHub].
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-operators-from-operatorhub_olm-adding-operators-to-a-cluster[Install an Operator from OperatorHub].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../operators/admin/olm-status.adoc#olm-status[View Operator status].
 ** xref:../operators/admin/olm-managing-operatorconditions.adoc#olm-managing-operatorconditions[Manage Operator conditions].
 ** xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Upgrade installed Operators].
 ** xref:../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Delete installed Operators].
 ** xref:../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[Configure proxy support].
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ** xref:../disconnected/using-olm.adoc#olm-restricted-networks[Using Operator Lifecycle Manager in disconnected environments].
 
 // Not sure if the xref above should be changed in #82841 since this is the index page of the Operators section
 
 For information about the cluster Operators that Red Hat provides, see xref:../operators/operator-reference.adoc#cluster-operators-ref[Cluster Operators reference].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="operators-overview-next-steps"]
 == Next steps
diff --git a/operators/olm_v1/index.adoc b/operators/olm_v1/index.adoc
index cd071a4186a1..9c3dde984ed3 100644
--- a/operators/olm_v1/index.adoc
+++ b/operators/olm_v1/index.adoc
@@ -1,12 +1,12 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="olmv1-about"]
-= About Operator Lifecycle Manager v1 (Technology Preview)
+= About Operator Lifecycle Manager v1
 include::_attributes/common-attributes.adoc[]
 :context: olmv1-about
 
 toc::[]
 
-{olm-first} has been included with {product-title} 4 since its initial release. {product-title} 4.17 includes components for a next-generation iteration of {olm} as a Technology Preview feature, known during this phase as _{olmv1}_. This updated framework evolves many of the concepts that have been part of previous versions of {olm} and adds new capabilities.
+{olm-first} has been included with {product-title} 4 since its initial release. {product-title} 4.18 includes components for a next-generation iteration of {olm} as a Generally Available (GA) feature, known during this phase as _{olmv1}_. This updated framework evolves many of the concepts that have been part of previous versions of {olm} and adds new capabilities.
 
 Starting in {product-title} 4.17, documentation for {olmv1} has been moved to the following new guide:
 
diff --git a/operators/operator-reference.adoc b/operators/operator-reference.adoc
index 571ab31eb109..004a94293fe9 100644
--- a/operators/operator-reference.adoc
+++ b/operators/operator-reference.adoc
@@ -128,18 +128,18 @@ include::modules/node-tuning-operator.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="cluster-operators-ref-nto-addtl-resources"]
 === Additional resources
-* xref:../scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc#cnf-understanding-low-latency_cnf-understanding-low-latency[About low latency]
+* xref:../scalability_and_performance/cnf-understanding-low-latency.adoc#cnf-understanding-low-latency_cnf-understanding-low-latency[About low latency]
 
 include::modules/openshift-apiserver-operator.adoc[leveloffset=+1]
 
 include::modules/cluster-openshift-controller-manager-operators.adoc[leveloffset=+1]
 
 [id="cluster-operators-ref-olm"]
-== Operator Lifecycle Manager (OLM) Operators
+== {olmv0-first} Operators
 
 [NOTE]
 ====
-The following sections pertain to the {olmv0-first} that has been included with {product-title} 4 since its initial release. For {olmv1}, see xref:../operators/operator-reference.adoc#cluster-operators-ref-olmv1_cluster-operators-ref[{olmv1-first} Operators].
+The following sections pertain to {olmv0-first} that has been included with {product-title} 4 since its initial release. For {olmv1}, see xref:../operators/operator-reference.adoc#cluster-operators-ref-olmv1_cluster-operators-ref[{olmv1-first} Operators].
 ====
 
 [discrete]
@@ -176,7 +176,7 @@ include::modules/olmv1-clusteroperator.adoc[leveloffset=+1]
 [id="cluster-operators-ref-olmv1-addtl-resources"]
 === Additional resources
 * xref:../extensions/index.adoc#extensions-overview[Extensions overview]
-* xref:../extensions/ce/upgrade-edges.adoc#upgrade-edges[Compatibility with {product-title} versions]
+* xref:../extensions/ce/update-paths.adoc#olmv1-ocp-compat_update-paths[Compatibility with {product-title} versions]
 
 include::modules/openshift-service-ca-operator.adoc[leveloffset=+1]
 
diff --git a/operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc b/operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
index e30868ead3c0..700bdb3698c3 100644
--- a/operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
+++ b/operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
@@ -20,27 +20,30 @@ Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
 
 Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than xref:../../../operators/operator_sdk/ansible/osdk-ansible-quickstart.adoc#osdk-ansible-quickstart[Getting started with Operator SDK for Ansible-based Operators].
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-ansible-quickstart[Getting started with Operator SDK for Ansible-based Operators] in the OpenShift Container Platform documentation.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
+// TODO-HCP remove line 44 and 46 ifndef conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-create-project.adoc[leveloffset=+1]
 include::modules/osdk-project-file.adoc[leveloffset=+2]
@@ -52,18 +55,18 @@ include::modules/osdk-run-proxy.adoc[leveloffset=+1]
 
 include::modules/osdk-run-operator.adoc[leveloffset=+1]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-ansible-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-ansible-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/osdk-run-locally.adoc[leveloffset=+2]
 include::modules/osdk-run-deployment.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="osdk-bundle-deploy-olm_{context}"]
 === Bundling an Operator and deploying with Operator Lifecycle Manager
@@ -78,9 +81,13 @@ include::modules/osdk-create-cr.adoc[leveloffset=+1]
 == Additional resources
 
 * See xref:../../../operators/operator_sdk/ansible/osdk-ansible-project-layout.adoc#osdk-ansible-project-layout[Project layout for Ansible-based Operators] to learn about the directory structures created by the Operator SDK.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured], administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+// TODO-HCP remove line 88 and 91 ifndef conditions for HCP after networking book is migrated
+ifndef::openshift-rosa-hcp[]
+* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured]
+endif::openshift-rosa-hcp[]
+, administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc b/operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
index ddb935b12d00..f0e5f17a51e3 100644
--- a/operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
+++ b/operators/operator_sdk/ansible/osdk-ansible-updating-projects.adoc
@@ -12,15 +12,11 @@ include::snippets/osdk-deprecation.adoc[]
 
 However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
 
-include::modules/osdk-updating-131-to-1361.adoc[leveloffset=+1]
+include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
 
 [id="additional-resources_osdk-ansible-upgrading-projects"]
 [role="_additional-resources"]
 == Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/operators/index#osdk-upgrading-projects_osdk-ansible-updating-projects[Upgrading projects for Operator SDK v1.25.4]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.11/html-single/operators/index#osdk-upgrading-projects_osdk-ansible-updating-projects[Upgrading projects for Operator SDK v1.22.0]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/operators/index#osdk-upgrading-v1101-to-v1160_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.16.0]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html/operators/developing-operators#osdk-upgrading-v180-to-v1101_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.10.1]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.8/html/operators/developing-operators#osdk-upgrading-v130-to-v180_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.8.0]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-ansible-updating-projects[Updating Ansible-based Operator projects for Operator SDK 1.36.1] ({product-title} 4.17)
 * xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
diff --git a/operators/operator_sdk/golang/osdk-golang-tutorial.adoc b/operators/operator_sdk/golang/osdk-golang-tutorial.adoc
index c2928008367f..51cb7b75d67b 100644
--- a/operators/operator_sdk/golang/osdk-golang-tutorial.adoc
+++ b/operators/operator_sdk/golang/osdk-golang-tutorial.adoc
@@ -16,27 +16,30 @@ Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
 
 Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than xref:../../../operators/operator_sdk/golang/osdk-golang-quickstart.adoc#osdk-golang-quickstart[Getting started with Operator SDK for Go-based Operators].
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-golang-quickstart[Getting started with Operator SDK for Go-based Operators] in the OpenShift Container Platform documentation.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
+// TODO-HCP remove conditions ifndef line 40 & 42 for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-create-project.adoc[leveloffset=+1]
 include::modules/osdk-project-file.adoc[leveloffset=+2]
@@ -60,18 +63,18 @@ include::modules/osdk-golang-controller-rbac-markers.adoc[leveloffset=+2]
 include::modules/osdk-run-proxy.adoc[leveloffset=+1]
 
 include::modules/osdk-run-operator.adoc[leveloffset=+1]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-golang-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-golang-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/osdk-run-locally.adoc[leveloffset=+2]
 include::modules/osdk-run-deployment.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="osdk-bundle-deploy-olm_{context}"]
 === Bundling an Operator and deploying with Operator Lifecycle Manager
@@ -86,9 +89,15 @@ include::modules/osdk-create-cr.adoc[leveloffset=+1]
 == Additional resources
 
 * See xref:../../../operators/operator_sdk/golang/osdk-golang-project-layout.adoc#osdk-golang-project-layout[Project layout for Go-based Operators] to learn about the directory structures created by the Operator SDK.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated,openshift-rosa[]
-* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured], administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
+// TODO-HCP remove line 97 and 99 conditions and add the HCP condition to line 92 and 98 for HCP after networking book is migrated
+ifndef::openshift-rosa-hcp[]
+* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured],
+endif::openshift-rosa-hcp[]
+administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
 endif::openshift-dedicated,openshift-rosa[]
+
+
diff --git a/operators/operator_sdk/golang/osdk-golang-updating-projects.adoc b/operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
index 80b6643145de..3f0b2e7d10bf 100644
--- a/operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
+++ b/operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
@@ -12,11 +12,11 @@ include::snippets/osdk-deprecation.adoc[]
 
 However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
 
-include::modules/osdk-updating-131-to-1361.adoc[leveloffset=+1]
+include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
 
 [id="additional-resources_osdk-upgrading-projects-golang"]
 [role="_additional-resources"]
 == Additional resources
 
-* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/operators/index#osdk-upgrading-projects_osdk-golang-updating-projects[Upgrading projects for Operator SDK 1.31.0] ({product-title} 4.16)
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-golang-updating-projects[Updating Go-based projects for Operator SDK 1.36.1] ({product-title} 4.17)
 * xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
\ No newline at end of file
diff --git a/operators/operator_sdk/helm/osdk-helm-tutorial.adoc b/operators/operator_sdk/helm/osdk-helm-tutorial.adoc
index 71c14c118794..ec6d25f9b455 100644
--- a/operators/operator_sdk/helm/osdk-helm-tutorial.adoc
+++ b/operators/operator_sdk/helm/osdk-helm-tutorial.adoc
@@ -20,27 +20,30 @@ Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
 
 Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than xref:../../../operators/operator_sdk/helm/osdk-helm-quickstart.adoc#osdk-helm-quickstart[Getting started with Operator SDK for Helm-based Operators].
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-helm-quickstart[Getting started with Operator SDK for Helm-based Operators] in the OpenShift Container Platform documentation.
 ====
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
+// TODO-HCP remove line 44 and 46 ifndef conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-create-project.adoc[leveloffset=+1]
 include::modules/osdk-helm-existing-chart.adoc[leveloffset=+2]
@@ -55,18 +58,18 @@ include::modules/osdk-run-proxy.adoc[leveloffset=+1]
 
 include::modules/osdk-run-operator.adoc[leveloffset=+1]
 
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-helm-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-helm-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/osdk-run-locally.adoc[leveloffset=+2]
 include::modules/osdk-run-deployment.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="osdk-bundle-deploy-olm_{context}"]
 === Bundling an Operator and deploying with Operator Lifecycle Manager
@@ -81,9 +84,13 @@ include::modules/osdk-create-cr.adoc[leveloffset=+1]
 == Additional resources
 
 * See xref:../../../operators/operator_sdk/helm/osdk-helm-project-layout.adoc#osdk-helm-project-layout[Project layout for Helm-based Operators] to learn about the directory structures created by the Operator SDK.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-dedicated,openshift-rosa[]
+// TODO-HCP remove line 92 and 94 ifndef conditions for HCP after networking book is migrated ad put the hcp condition back on line 90 and 95
+ifndef::openshift-rosa-hcp[]
 * If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured], administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
+endif::openshift-rosa-hcp[]
 endif::openshift-dedicated,openshift-rosa[]
+
diff --git a/operators/operator_sdk/helm/osdk-helm-updating-projects.adoc b/operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
index 0b441a0293c2..ebe3067e472c 100644
--- a/operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
+++ b/operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
@@ -12,13 +12,11 @@ include::snippets/osdk-deprecation.adoc[]
 
 However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
 
-include::modules/osdk-updating-131-to-1361.adoc[leveloffset=+1]
+include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
 
 [id="additional-resources_osdk-helm-upgrading-projects"]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/operators/index#osdk-upgrading-v1101-to-v1160_osdk-upgrading-projects[Upgrading projects for Operator SDK 1.16.0]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html/operators/developing-operators#osdk-upgrading-v180-to-v1101_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.10.1]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.8/html/operators/developing-operators#osdk-upgrading-v130-to-v180_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.8.0]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-helm-updating-projects[Updating Helm-based Operator projects for Operator SDK 1.36.1] ({product-title} 4.17)
+* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
\ No newline at end of file
diff --git a/operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc b/operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
deleted file mode 100644
index 27d6dd6fdcea..000000000000
--- a/operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-hybrid-helm-updating-projects"]
-= Updating Hybrid Helm-based projects for newer Operator SDK versions
-include::_attributes/common-attributes.adoc[]
-:context: osdk-hybrid-helm-updating-projects
-
-toc::[]
-
-{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
-
-include::snippets/osdk-deprecation.adoc[]
-
-However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
-
-include::modules/osdk-updating-131-to-1361.adoc[leveloffset=+1]
-
-[id="additional-resources_osdk-hybrid-helm-upgrading-projects"]
-[role="_additional-resources"]
-== Additional resources
-
-* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/operators/index#osdk-upgrading-v1101-to-v1160_osdk-upgrading-projects[Upgrading projects for Operator SDK 1.16.0]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html/operators/developing-operators#osdk-upgrading-v180-to-v1101_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.10.1]
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.8/html/operators/developing-operators#osdk-upgrading-v130-to-v180_osdk-upgrading-projects[Upgrading projects for Operator SDK v1.8.0]
diff --git a/operators/operator_sdk/helm/osdk-hybrid-helm.adoc b/operators/operator_sdk/helm/osdk-hybrid-helm.adoc
deleted file mode 100644
index 8335c5637581..000000000000
--- a/operators/operator_sdk/helm/osdk-hybrid-helm.adoc
+++ /dev/null
@@ -1,72 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-hybrid-helm"]
-= Operator SDK tutorial for Hybrid Helm Operators
-include::_attributes/common-attributes.adoc[]
-:context: osdk-hybrid-helm
-
-toc::[]
-
-The standard Helm-based Operator support in the Operator SDK has limited functionality compared to the Go-based and Ansible-based Operator support that has reached the Auto Pilot capability (level V) in the xref:../../../operators/understanding/olm-what-operators-are.adoc#olm-maturity-model_olm-what-operators-are[Operator maturity model].
-
-include::snippets/osdk-deprecation.adoc[]
-
-The Hybrid Helm Operator enhances the existing Helm-based support's abilities through Go APIs. With this hybrid approach of Helm and Go, the Operator SDK enables Operator authors to use the following process:
-
-* Generate a default structure for, or _scaffold_, a Go API in the same project as Helm.
-* Configure the Helm reconciler in the `main.go` file of the project, through the libraries provided by the Hybrid Helm Operator.
-
-:FeatureName: The Hybrid Helm Operator
-include::snippets/technology-preview.adoc[]
-
-This tutorial walks through the following process using the Hybrid Helm Operator:
-
-* Create a `Memcached` deployment through a Helm chart if it does not exist
-* Ensure that the deployment size is the same as specified by `Memcached` custom resource (CR) spec
-* Create a `MemcachedBackup` deployment by using the Go API
-
-include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
-* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
-
-include::modules/osdk-hh-create-project.adoc[leveloffset=+1]
-.Additional resources
-
-* This procedure creates a project structure that is compatible with both Helm and Go APIs. To learn more about the project directory structure, see xref:../../../operators/operator_sdk/helm/osdk-hybrid-helm.adoc#osdk-hh-project-layout_osdk-hybrid-helm[Project layout].
-
-include::modules/osdk-hh-create-helm-api.adoc[leveloffset=+1]
-.Additional resources
-
-* xref:../../../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-helm-existing-chart_osdk-helm-tutorial[Existing Helm charts]
-
-include::modules/osdk-hh-helm-api-logic.adoc[leveloffset=+2]
-.Additional resources
-
-* For detailed documentation on customizing the Helm Operator logic through the chart, see xref:../../../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-helm-logic_osdk-helm-tutorial[Understanding the Operator logic].
-
-include::modules/osdk-hh-helm-reconciler.adoc[leveloffset=+2]
-
-include::modules/osdk-hh-create-go-api.adoc[leveloffset=+1]
-
-include::modules/osdk-hh-defining-go-api.adoc[leveloffset=+2]
-
-include::modules/osdk-hh-implement-controller.adoc[leveloffset=+2]
-
-For a detailed explanation on how to configure the controller to perform the above mentioned actions, see xref:../../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-golang-implement-controller_osdk-golang-tutorial[Implementing the controller] in the Operator SDK tutorial for standard Go-based Operators.
-
-include::modules/osdk-hh-main-go.adoc[leveloffset=+2]
-
-include::modules/osdk-hh-rbac.adoc[leveloffset=+2]
-.Additional resources
-
-* xref:../../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-golang-controller-rbac-markers_osdk-golang-tutorial[RBAC markers for Go-based Operators]
-
-include::modules/osdk-run-locally.adoc[leveloffset=+1]
-
-include::modules/osdk-run-deployment.adoc[leveloffset=+1]
-
-include::modules/osdk-hh-create-cr.adoc[leveloffset=+1]
-
-include::modules/osdk-hh-project-layout.adoc[leveloffset=+1]
diff --git a/operators/operator_sdk/java/osdk-java-project-layout.adoc b/operators/operator_sdk/java/osdk-java-project-layout.adoc
deleted file mode 100644
index 433c6f07c81e..000000000000
--- a/operators/operator_sdk/java/osdk-java-project-layout.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-java-project-layout"]
-= Project layout for Java-based Operators
-include::_attributes/common-attributes.adoc[]
-:context: osdk-java-project-layout
-:FeatureName: Java-based Operator SDK
-include::snippets/technology-preview.adoc[]
-
-toc::[]
-
-The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
-
-include::snippets/osdk-deprecation.adoc[]
-
-include::modules/osdk-java-project-layout.adoc[leveloffset=+1]
diff --git a/operators/operator_sdk/java/osdk-java-quickstart.adoc b/operators/operator_sdk/java/osdk-java-quickstart.adoc
deleted file mode 100644
index 177e97b05dd2..000000000000
--- a/operators/operator_sdk/java/osdk-java-quickstart.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-java-quickstart"]
-= Getting started with Operator SDK for Java-based Operators
-include::_attributes/common-attributes.adoc[]
-:context: osdk-java-quickstart
-:FeatureName: Java-based Operator SDK
-include::snippets/technology-preview.adoc[]
-
-// This assembly is not included in the OSD and ROSA docs, because it is Tech Preview. However, once Java-based Operator SDK is GA, this assembly will still need to be excluded from OSD and ROSA if it continues to require cluster-admin permissions.
-
-toc::[]
-
-To demonstrate the basics of setting up and running a Java-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Java-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
-
-include::snippets/osdk-deprecation.adoc[]
-
-include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
-* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
-
-include::modules/osdk-quickstart.adoc[leveloffset=+1]
-
-[id="next-steps_osdk-java-quickstart"]
-== Next steps
-
-* See xref:../../../operators/operator_sdk/java/osdk-java-tutorial.adoc#osdk-java-tutorial[Operator SDK tutorial for Java-based Operators] for a more in-depth walkthrough on building a Java-based Operator.
diff --git a/operators/operator_sdk/java/osdk-java-tutorial.adoc b/operators/operator_sdk/java/osdk-java-tutorial.adoc
deleted file mode 100644
index 12eecea2a4fb..000000000000
--- a/operators/operator_sdk/java/osdk-java-tutorial.adoc
+++ /dev/null
@@ -1,87 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-java-tutorial"]
-= Operator SDK tutorial for Java-based Operators
-include::_attributes/common-attributes.adoc[]
-:context: osdk-java-tutorial
-:FeatureName: Java-based Operator SDK
-include::snippets/technology-preview.adoc[]
-
-// This assembly is not currrently included in the OSD and ROSA distros, because it is Tech Preview. However, some conditionalization has been added for OSD and ROSA so that the content will be applicable to those distros once this feature is GA and included in the OSD and ROSA docs.
-
-toc::[]
-
-Operator developers can take advantage of Java programming language support in the Operator SDK to build an example Java-based Operator for Memcached, a distributed key-value store, and manage its lifecycle.
-
-include::snippets/osdk-deprecation.adoc[]
-
-This process is accomplished using two centerpieces of the Operator Framework:
-
-Operator SDK:: The `operator-sdk` CLI tool and `java-operator-sdk` library API
-
-Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
-
-ifndef::openshift-dedicated,openshift-rosa[]
-[NOTE]
-====
-This tutorial goes into greater detail than xref:../../../operators/operator_sdk/java/osdk-java-quickstart.adoc#osdk-java-quickstart[Getting started with Operator SDK for Java-based Operators].
-====
-endif::openshift-dedicated,openshift-rosa[]
-
-// The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
-ifdef::openshift-dedicated,openshift-rosa[]
-[NOTE]
-====
-This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-java-quickstart[Getting started with Operator SDK for Java-based Operators] in the OpenShift Container Platform documentation.
-====
-endif::openshift-dedicated,openshift-rosa[]
-
-include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
-* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
-
-include::modules/osdk-create-project.adoc[leveloffset=+1]
-include::modules/osdk-project-file.adoc[leveloffset=+2]
-
-include::modules/osdk-java-create-api-controller.adoc[leveloffset=+1]
-include::modules/osdk-java-define-api.adoc[leveloffset=+2]
-include::modules/osdk-java-generate-crd.adoc[leveloffset=+2]
-include::modules/osdk-java-create-cr.adoc[leveloffset=+2]
-
-include::modules/osdk-java-implement-controller.adoc[leveloffset=+1]
-
-The next subsections explain how the controller in the example implementation watches resources and how the reconcile loop is triggered. You can skip these subsections to go directly to xref:../../../operators/operator_sdk/java/osdk-java-tutorial.adoc#osdk-run-operator_osdk-java-tutorial[Running the Operator].
-
-include::modules/osdk-java-controller-reconcile-loop.adoc[leveloffset=+2]
-include::modules/osdk-java-controller-labels-memcached.adoc[leveloffset=+2]
-include::modules/osdk-java-controller-memcached-deployment.adoc[leveloffset=+2]
-
-include::modules/osdk-run-operator.adoc[leveloffset=+1]
-
-ifdef::openshift-dedicated,openshift-rosa[]
-[role="_additional-resources"]
-.Additional resources
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-java-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-java-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
-endif::openshift-dedicated,openshift-rosa[]
-
-// In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
-ifndef::openshift-dedicated,openshift-rosa[]
-include::modules/osdk-run-locally.adoc[leveloffset=+2]
-include::modules/osdk-run-deployment.adoc[leveloffset=+2]
-endif::openshift-dedicated,openshift-rosa[]
-
-[id="osdk-bundle-deploy-olm_{context}"]
-=== Bundling an Operator and deploying with Operator Lifecycle Manager
-
-include::modules/osdk-bundle-operator.adoc[leveloffset=+3]
-include::modules/osdk-deploy-olm.adoc[leveloffset=+3]
-
-[role="_additional-resources"]
-[id="additional-resources_osdk-java-tutorial"]
-== Additional resources
-
-* See xref:../../../operators/operator_sdk/java/osdk-java-project-layout.adoc#osdk-java-project-layout[Project layout for Java-based Operators] to learn about the directory structures created by the Operator SDK.
-* If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
diff --git a/operators/operator_sdk/java/osdk-java-updating-projects.adoc b/operators/operator_sdk/java/osdk-java-updating-projects.adoc
deleted file mode 100644
index 82ed3dbbbaf7..000000000000
--- a/operators/operator_sdk/java/osdk-java-updating-projects.adoc
+++ /dev/null
@@ -1,21 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="osdk-java-updating-projects"]
-= Updating projects for newer Operator SDK versions
-include::_attributes/common-attributes.adoc[]
-:context: osdk-java-updating-projects
-
-toc::[]
-
-{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
-
-include::snippets/osdk-deprecation.adoc[]
-
-However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
-
-include::modules/osdk-updating-131-to-1361.adoc[leveloffset=+1]
-
-[id="additional-resources_osdk-java-upgrading-projects"]
-[role="_additional-resources"]
-== Additional resources
-
-* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
diff --git a/operators/operator_sdk/osdk-about.adoc b/operators/operator_sdk/osdk-about.adoc
index 239054f93a7c..65e45c58496b 100644
--- a/operators/operator_sdk/osdk-about.adoc
+++ b/operators/operator_sdk/osdk-about.adoc
@@ -26,12 +26,12 @@ The Operator SDK is a framework that uses the link:https://github.com/kubernetes
 - Extensions to cover common Operator use cases
 - Metrics set up automatically in any generated Go-based Operator for use on clusters where the Prometheus Operator is deployed
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Operator authors with cluster administrator access to a Kubernetes-based cluster (such as {product-title})
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Operator authors with dedicated-admin access to {product-title}
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
 
 [NOTE]
diff --git a/operators/operator_sdk/osdk-bundle-validate.adoc b/operators/operator_sdk/osdk-bundle-validate.adoc
index 7d4a67bd11ca..16773a53b389 100644
--- a/operators/operator_sdk/osdk-bundle-validate.adoc
+++ b/operators/operator_sdk/osdk-bundle-validate.adoc
@@ -20,7 +20,7 @@ include::modules/osdk-bundle-validate-tests.adoc[leveloffset=+1]
 
 include::modules/osdk-bundle-validate-run.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 include::modules/osdk-multi-arch-validate.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
diff --git a/operators/operator_sdk/osdk-cli-ref.adoc b/operators/operator_sdk/osdk-cli-ref.adoc
index b6c1ecac088e..33db59edcabb 100644
--- a/operators/operator_sdk/osdk-cli-ref.adoc
+++ b/operators/operator_sdk/osdk-cli-ref.adoc
@@ -41,7 +41,10 @@ include::modules/osdk-cli-ref-run-bundle.adoc[leveloffset=+2]
 
 * See xref:../../operators/understanding/olm/olm-understanding-operatorgroups.adoc#olm-operatorgroups-membership_olm-understanding-operatorgroups[Operator group membership] for details on possible install modes.
 * xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
+// TODO-HCP remove line 45 and 47 ifndef conditions for HCP after Authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-cli-ref-run-bundle-upgrade.adoc[leveloffset=+2]
 
@@ -49,7 +52,10 @@ include::modules/osdk-cli-ref-run-bundle-upgrade.adoc[leveloffset=+2]
 .Additional resources
 
 * xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
+// TODO-HCP remove line 55 and 57 ifndef conditions for HCP after Authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-cli-ref-scorecard.adoc[leveloffset=+1]
 
@@ -58,4 +64,7 @@ include::modules/osdk-cli-ref-scorecard.adoc[leveloffset=+1]
 
 * See xref:../../operators/operator_sdk/osdk-scorecard.adoc#osdk-scorecard[Validating Operators using the scorecard tool] for details about running the scorecard tool.
 * xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
+// TODO-HCP remove line 67 and 69 ifndef conditions for HCP after Authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/operators/operator_sdk/osdk-complying-with-psa.adoc b/operators/operator_sdk/osdk-complying-with-psa.adoc
index 9e80f34132b3..cc448d4ab560 100644
--- a/operators/operator_sdk/osdk-complying-with-psa.adoc
+++ b/operators/operator_sdk/osdk-complying-with-psa.adoc
@@ -13,8 +13,10 @@ If your Operator project does not require escalated permissions to run, you can
 
 * The allowed pod security admission level for the Operator's namespace
 * The allowed security context constraints (SCC) for the workload's service account
-
+// TODO-HCP remove line 17 and 19 ifndef conditions for HCP after authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 For more information, see xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission].
+endif::openshift-rosa-hcp[]
 
 include::snippets/osdk-deprecation.adoc[]
 
@@ -30,13 +32,17 @@ include::modules/osdk-ensuring-operator-workloads-run-restricted-psa.adoc[levelo
 
 [role="_additional-resources"]
 .Additional resources
-
+// TODO-HCP remove line 36 and 38 ifndef conditions for HCP after authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/managing-security-context-constraints.adoc#managing-security-context-constraints[Managing security context constraints]
+endif::openshift-rosa-hcp[]
 
 include::modules/osdk-managing-psa-for-operators-with-escalated-permissions.adoc[leveloffset=+1]
 
 [id="osdk-complying-with-psa-additional-resources"]
 [role="_additional-resources"]
 == Additional resources
-
+// TODO-HCP remove line 46 and 48 ifndef conditions for HCP after authentication book is migrated
+ifndef::openshift-rosa-hcp[]
 * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/operators/operator_sdk/osdk-generating-csvs.adoc b/operators/operator_sdk/osdk-generating-csvs.adoc
index a46a0e7f39cf..a4020e9de8ab 100644
--- a/operators/operator_sdk/osdk-generating-csvs.adoc
+++ b/operators/operator_sdk/osdk-generating-csvs.adoc
@@ -37,9 +37,9 @@ include::modules/osdk-csv-annotations-infra.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-enabling-operator-for-restricted-network_osdk-generating-csvs[Enabling your Operator for restricted network environments] (disconnected mode)
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../installing/overview/installing-fips.adoc#installing-fips[Support for FIPS cryptography]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/osdk-csv-annotations-dep.adoc[leveloffset=+2]
 include::modules/osdk-csv-annotations-other.adoc[leveloffset=+2]
@@ -76,9 +76,9 @@ include::modules/olm-defining-csv-webhooks.adoc[leveloffset=+1]
 .Additional resources
 
 // This xref points to a topic that is not currently included in the OSD and ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../architecture/admission-plug-ins.adoc#admission-webhook-types_admission-plug-ins[Types of webhook admission plugins]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Kubernetes documentation:
 ** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook[Validating admission webhooks]
 ** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook[Mutating admission webhooks]
diff --git a/operators/operator_sdk/osdk-ha-sno.adoc b/operators/operator_sdk/osdk-ha-sno.adoc
index 68ac8ed76148..325cae8cabe5 100644
--- a/operators/operator_sdk/osdk-ha-sno.adoc
+++ b/operators/operator_sdk/osdk-ha-sno.adoc
@@ -7,9 +7,9 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 // OSD/ROSA don't support single-node clusters, but these Operator authors still need to know how to handle this configuration for their Operators to work correctly in OCP.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 To ensure that your Operator runs well on both high-availability (HA) and non-HA modes in OpenShift Container Platform clusters, you can use the Operator SDK to detect the cluster's infrastructure topology and set the resource requirements to fit the cluster's topology.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // Not using {product-title} here, because HA mode and non-HA mode are specific to OCP and should be spelled out this way in other distros.
 An OpenShift Container Platform cluster can be configured in high-availability (HA) mode, which uses multiple nodes, or in non-HA mode, which uses a single node. A single-node cluster, also known as {sno}, is likely to have more conservative resource constraints. Therefore, it is important that Operators installed on a single-node cluster can adjust accordingly and still run well.
diff --git a/operators/operator_sdk/osdk-installing-cli.adoc b/operators/operator_sdk/osdk-installing-cli.adoc
index d0bfb4742cb1..857d24cdc471 100644
--- a/operators/operator_sdk/osdk-installing-cli.adoc
+++ b/operators/operator_sdk/osdk-installing-cli.adoc
@@ -10,12 +10,12 @@ The Operator SDK provides a command-line interface (CLI) tool that Operator deve
 
 include::snippets/osdk-deprecation.adoc[]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Operator authors with cluster administrator access to a Kubernetes-based cluster, such as {product-title},
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Operator authors with dedicated-admin access to {product-title}
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
 
 [NOTE]
diff --git a/operators/operator_sdk/osdk-leader-election.adoc b/operators/operator_sdk/osdk-leader-election.adoc
index e34681b25a39..9cd2d5c0e4e7 100644
--- a/operators/operator_sdk/osdk-leader-election.adoc
+++ b/operators/operator_sdk/osdk-leader-election.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 During the lifecycle of an Operator, it is possible that there may be more than one instance running at any given time, for example when rolling out an upgrade for the Operator. In such a scenario, it is necessary to avoid contention between multiple Operator instances using leader election. This ensures only one leader instance handles the reconciliation while the other instances are inactive but ready to take over when the leader steps down.
 
-There are two different leader election implementations to choose from, each with its own trade-off:
+There are two different leader election implementations to choose from, each with its own tradeoff:
 
 Leader-for-life:: The leader pod only gives up leadership, using garbage collection, when it is deleted. This implementation precludes the possibility of two instances mistakenly running as leaders, a state also known as split brain. However, this method can be subject to a delay in electing a new leader. For example, when the leader pod is on an unresponsive or partitioned node, you can specify `node.kubernetes.io/unreachable` and `node.kubernetes.io/not-ready` tolerations on the leader pod and use the `tolerationSeconds` value to dictate how long it takes for the leader pod to be deleted from the node and step down. These tolerations are added to the pod by default on admission with a `tolerationSeconds` value of 5 minutes. See the link:https://godoc.org/github.com/operator-framework/operator-sdk/pkg/leader[Leader-for-life] Go documentation for more.
 
diff --git a/operators/operator_sdk/osdk-monitoring-prometheus.adoc b/operators/operator_sdk/osdk-monitoring-prometheus.adoc
index 83f6efb33cc5..b1b292ca6193 100644
--- a/operators/operator_sdk/osdk-monitoring-prometheus.adoc
+++ b/operators/operator_sdk/osdk-monitoring-prometheus.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 // Dedicated-admins in OSD and ROSA don't have the permissions to complete the procedures in this assembly. Also, the procedures use the default Prometheus Operator in the openshift-monitoring project, which OSD/ROSA customers should not use.
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 This guide describes the built-in monitoring support provided by the Operator SDK using the Prometheus Operator and details usage for authors of Go-based and Ansible-based Operators.
 
 include::snippets/osdk-deprecation.adoc[]
@@ -16,7 +16,7 @@ include::snippets/osdk-deprecation.adoc[]
 include::modules/osdk-monitoring-prometheus-operator-support.adoc[leveloffset=+1]
 include::modules/osdk-monitoring-custom-metrics.adoc[leveloffset=+1]
 include::modules/osdk-ansible-metrics.adoc[leveloffset=+1]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-dedicated,openshift-rosa[]
 // Since OSD/ROSA dedicated-admins can't do the procedures in this assembly, point to the OCP docs.
@@ -35,5 +35,9 @@ Do not use the Prometheus Operator in the `openshift-monitoring` project. Red Ha
 .Additional resources
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-monitoring-custom-metrics_osdk-monitoring-prometheus[Exposing custom metrics for Go-based Operators] (OpenShift Container Platform documentation)
 * link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-ansible-metrics_osdk-monitoring-prometheus[Exposing custom metrics for Ansible-based Operators] (OpenShift Container Platform documentation)
+// TODO-HCP remove line 39 and 41 ifndef conditions for HCP after Observability book is migrated and add back HCP condition to line 41 and 21
+ifndef::openshift-rosa-hcp[]
 * xref:../../observability/monitoring/monitoring-overview.adoc#understanding-the-monitoring-stack_monitoring-overview[Understanding the monitoring stack] in {product-title}
+endif::openshift-rosa-hcp[]
 endif::openshift-dedicated,openshift-rosa[]
+
diff --git a/operators/understanding/olm-common-terms.adoc b/operators/understanding/olm-common-terms.adoc
index 7b2b1a479eac..3fbf8724d803 100644
--- a/operators/understanding/olm-common-terms.adoc
+++ b/operators/understanding/olm-common-terms.adoc
@@ -8,4 +8,4 @@ toc::[]
 
 This topic provides a glossary of common terms related to the Operator Framework, including Operator Lifecycle Manager (OLM) and the Operator SDK.
 
-include::modules/olm-terms.adoc[leveloffset=+1]
+include::snippets/of-terms-snippet.adoc[leveloffset=+0]
diff --git a/operators/understanding/olm-multitenancy.adoc b/operators/understanding/olm-multitenancy.adoc
index b81b915a3039..0d9ed89db150 100644
--- a/operators/understanding/olm-multitenancy.adoc
+++ b/operators/understanding/olm-multitenancy.adoc
@@ -26,10 +26,10 @@ include::modules/olm-multitenancy-solution.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-preparing-operators-multitenant_olm-adding-operators-to-a-cluster[Preparing for multiple instances of an Operator for multitenant clusters]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../operators/admin/olm-creating-policy.adoc#olm-creating-policy[Allowing non-cluster administrators to install Operators]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-restricted-networks-operatorhub_olm-managing-custom-catalogs[Disabling the default OperatorHub catalog sources]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 [id="olm-colocation_{context}"]
 == Operator colocation and Operator groups
diff --git a/operators/understanding/olm-packaging-format.adoc b/operators/understanding/olm-packaging-format.adoc
index bbd541a97bce..7e6543cd0afa 100644
--- a/operators/understanding/olm-packaging-format.adoc
+++ b/operators/understanding/olm-packaging-format.adoc
@@ -17,8 +17,10 @@ include::modules/olm-dependencies.adoc[leveloffset=+2]
 * xref:../../operators/understanding/olm/olm-understanding-dependency-resolution.adoc#olm-understanding-dependency-resolution[Operator Lifecycle Manager dependency resolution]
 
 include::modules/olm-about-opm.adoc[leveloffset=+2]
-
+// TODO-HCP remove conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 * See xref:../../cli_reference/opm/cli-opm-install.adoc#cli-opm-install[CLI tools] for steps on installing the `opm` CLI.
+endif::openshift-rosa-hcp[]
 
 ifdef::openshift-origin[]
 [id="olm-packaging-format-addtl-resources"]
@@ -40,12 +42,12 @@ As of {product-title} 4.11, the default Red Hat-provided Operator catalog releas
 The `opm` subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.
 
 Many of the `opm` subcommands and flags for working with the SQLite database format, such as `opm index prune`, do not work with the file-based catalog format.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[Managing custom catalogs] and xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[Managing custom catalogs].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ====
 
 include::modules/olm-fb-catalogs-structure.adoc[leveloffset=+2]
@@ -68,7 +70,9 @@ include::modules/olm-fb-catalogs-guidelines.adoc[leveloffset=+2]
 === CLI usage
 
 For instructions about creating file-based catalogs by using the `opm` CLI, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-creating-fb-catalog-image_olm-managing-custom-catalogs[Managing custom catalogs].
-
+// TODO-HCP remove conditions for HCP after cli_tools book is migrated
+ifndef::openshift-rosa-hcp[]
 For reference documentation about the `opm` CLI commands related to managing file-based catalogs, see xref:../../cli_reference/opm/cli-opm-ref.adoc#cli-opm-ref[CLI tools].
+endif::openshift-rosa-hcp[]
 
 include::modules/olm-fb-catalogs-automation.adoc[leveloffset=+2]
diff --git a/operators/understanding/olm-rh-catalogs.adoc b/operators/understanding/olm-rh-catalogs.adoc
index 6365baec0ed7..443ee9bcbbf5 100644
--- a/operators/understanding/olm-rh-catalogs.adoc
+++ b/operators/understanding/olm-rh-catalogs.adoc
@@ -15,14 +15,14 @@ As of {product-title} 4.11, the default Red Hat-provided Operator catalog releas
 The `opm` subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.
 
 Many of the `opm` subcommands and flags for working with the SQLite database format, such as `opm index prune`, do not work with the file-based catalog format.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs],
 xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format], and xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin].
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 For more information about working with file-based catalogs, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs], and
 xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format].
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 ====
 
 include::modules/olm-about-catalogs.adoc[leveloffset=+1]
@@ -32,8 +32,8 @@ include::modules/olm-about-catalogs.adoc[leveloffset=+1]
 
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs]
 * xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Packaging format]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../disconnected/using-olm.adoc#olm-restricted-networks[Using Operator Lifecycle Manager in disconnected environments]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-rh-catalogs.adoc[leveloffset=+1]
diff --git a/operators/understanding/olm/olm-operatorconditions.adoc b/operators/understanding/olm/olm-operatorconditions.adoc
index 0d592ce73726..5a148915c43f 100644
--- a/operators/understanding/olm/olm-operatorconditions.adoc
+++ b/operators/understanding/olm/olm-operatorconditions.adoc
@@ -18,7 +18,7 @@ include::modules/olm-supported-operatorconditions.adoc[leveloffset=+1]
 * xref:../../../operators/admin/olm-managing-operatorconditions.adoc#olm-operatorconditions[Managing Operator conditions]
 * xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-operatorconditions_osdk-generating-csvs[Enabling Operator conditions]
 // The following xrefs point to topics that are not currently included in the OSD/ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../nodes/pods/nodes-pods-configuring.adoc#nodes-pods-configuring-pod-distruption-about_nodes-pods-configuring[Using pod disruption budgets to specify the number of pods that must be up]
 * xref:../../../applications/deployments/route-based-deployment-strategies.adoc#deployments-graceful-termination_route-based-deployment-strategies[Graceful termination]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/operators/understanding/olm/olm-understanding-olm.adoc b/operators/understanding/olm/olm-understanding-olm.adoc
index 11390a63c4e9..5f5384725662 100644
--- a/operators/understanding/olm/olm-understanding-olm.adoc
+++ b/operators/understanding/olm/olm-understanding-olm.adoc
@@ -21,40 +21,40 @@ include::modules/olm-catalogsource.adoc[leveloffset=+2]
 * xref:../../../operators/understanding/olm/olm-understanding-dependency-resolution.adoc#olm-dependency-catalog-priority_olm-understanding-dependency-resolution[Catalog priority]
 * xref:../../../operators/admin/olm-status.adoc#olm-cs-status-cli_olm-status[Viewing Operator catalog source status by using the CLI]
 // This xref points to a topic that is not currently included in the OSD/ROSA docs.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/admin/olm-cs-podsched.adoc#olm-cs-podsched[Catalog source pod scheduling]
 
 include::modules/olm-catalogsource-image-template.adoc[leveloffset=+3]
 include::modules/olm-cs-health.adoc[leveloffset=+3]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../../operators/admin/olm-managing-custom-catalogs.adoc#olm-removing-catalogs_olm-managing-custom-catalogs[Removing custom catalogs]
 * xref:../../../operators/admin/olm-managing-custom-catalogs.adoc#olm-restricted-networks-operatorhub_olm-managing-custom-catalogs[Disabling the default OperatorHub catalog sources]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-subscription.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Multitenancy and Operator colocation]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/admin/olm-status.adoc#olm-status-viewing-cli_olm-status[Viewing Operator subscription status by using the CLI]
 
 include::modules/olm-installplan.adoc[leveloffset=+2]
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Multitenancy and Operator colocation]
 * xref:../../../operators/admin/olm-creating-policy.adoc#olm-creating-policy[Allowing non-cluster administrators to install Operators]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-operatorgroups-about.adoc[leveloffset=+2]
 .Additional resources
diff --git a/operators/understanding/olm/olm-understanding-operatorgroups.adoc b/operators/understanding/olm/olm-understanding-operatorgroups.adoc
index be19ef7c7b3c..e7fdc406ee2e 100644
--- a/operators/understanding/olm/olm-understanding-operatorgroups.adoc
+++ b/operators/understanding/olm/olm-understanding-operatorgroups.adoc
@@ -20,12 +20,12 @@ include::modules/olm-operatorgroups-intersections.adoc[leveloffset=+1]
 include::modules/olm-operatorgroups-limitations.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Operator Lifecycle Manager (OLM) -> Multitenancy and Operator colocation]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/understanding/olm-multitenancy.adoc#olm-multitenancy[Operators in multitenant clusters]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../operators/admin/olm-creating-policy.adoc#olm-creating-policy[Allowing non-cluster administrators to install Operators]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/olm-operatorgroups-troubleshooting.adoc[leveloffset=+1]
diff --git a/operators/understanding/olm/olm-webhooks.adoc b/operators/understanding/olm/olm-webhooks.adoc
index cdaf8779a43e..4c0490b8dcfc 100644
--- a/operators/understanding/olm/olm-webhooks.adoc
+++ b/operators/understanding/olm/olm-webhooks.adoc
@@ -14,9 +14,9 @@ See xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-defining-
 [role="_additional-resources"]
 == Additional resources
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../architecture/admission-plug-ins.adoc#admission-webhook-types_admission-plug-ins[Types of webhook admission plugins]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Kubernetes documentation:
 ** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook[Validating admission webhooks]
 ** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook[Mutating admission webhooks]
diff --git a/operators/understanding/olm/olm-workflow.adoc b/operators/understanding/olm/olm-workflow.adoc
index 091ce7fd13c1..3e3ba7c48d87 100644
--- a/operators/understanding/olm/olm-workflow.adoc
+++ b/operators/understanding/olm/olm-workflow.adoc
@@ -8,4 +8,5 @@ toc::[]
 
 This guide outlines the workflow of Operator Lifecycle Manager (OLM) in {product-title}.
 
+// Operator installation and upgrade workflow in OLM
 include::modules/olm-upgrades.adoc[leveloffset=+1]
diff --git a/osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc b/osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc
index f3bc9d091072..ead5e1253c0a 100644
--- a/osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc
+++ b/osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc
@@ -27,11 +27,63 @@ By default, a cluster is created with one machine pool. You can add additional m
 Multiple machine pools can exist on a single cluster, and they can each have different types or different size nodes.
 
 == Machine pools in multiple zone clusters
-When you create a machine pool in a multiple availability zone (Multi-AZ) cluster, that one machine pool has 3 zones. The machine pool, in turn, creates a total of 3 compute machine sets - one for each zone in the cluster. Each of those compute machine sets manages one or more machines in its respective availability zone.
+By default, when you create a machine pool in a multiple availability zone (Multi-AZ) cluster, that one machine pool has 3 zones. The machine pool, in turn, creates a total of 3 compute machine sets - one for each zone in the cluster. Each of those compute machine sets manages one or more machines in its respective availability zone.
 
 If you create a new Multi-AZ cluster, the machine pools are replicated to those zones automatically. If you add a machine pool to an existing Multi-AZ, the new pool is automatically created in those zones. Similarly, deleting a machine pool will delete it from all zones.
 Due to this multiplicative effect, using machine pools in Multi-AZ cluster can consume more of your project's quota for a specific region when creating machine pools.
 
+=== Deploying a machine pool in a single availability zone within a Multi-AZ cluster
+{product-title} on {GCP} users can deploy a single machine pool in a specific availability zone that is part of a Multi-AZ cluster using the {cluster-manager} CLI (`ocm`). This option is especially useful in situations where a desired instance type is not available in all availability zones of a specific region as well as when your cluster does not need more than one of the desired instance types.
+
+[IMPORTANT]
+====
+You cannot assign the default machine pool to a single availability zone during the provisioning of a Multi-AZ cluster.
+====
+
+.Prerequisites
+*  You installed the link:https://console.redhat.com/openshift/downloads[OpenShift Cluster Manager API command-line interface (`ocm`)].
+
+[IMPORTANT]
+====
+[subs="attributes+"]
+OpenShift Cluster Manager API command-line interface (`ocm`) is a Developer Preview feature only.
+For more information about the support scope of Red Hat Developer Preview features, see link:https://access.redhat.com/support/offerings/devpreview/[Developer Preview Support Scope].
+====
+
+.Procedure
+
+** Deploy a machine pool to a specific availability zone by running the following command:
+
+[source,terminal]
+----
+ocm create machine-pool \
+  --cluster <cluster_name|cluster_id> \ <1>
+  --instance-type <instance_type> \ <2>
+  --replicas <number_of_replicas> \ <3>
+  --availability-zone <availability_zone> \ <4>
+    [flags] \ <5>
+   <machine_pool_id> <6>
+
+----
+<1> Replace `<cluster_name|cluster_id>` with the name or ID of the cluster that you want to add the machine pool to.
+<2> Replace `<instance_type>` with the instance type you want to deploy to the single availability zone.
+<3> Replace `<replicas>` with the number of replicas of the selected instance type you want to include in the machine pool.
+<4> Replace `<availability_zone>` with the availability zone you want to add the machine pool to.
+<5> Optional: Replace [flags] with any additional flags available for machine pool creation.
+<6> Replace `<machine_pool_id>` with an ID for your machine pool.
+
+[NOTE]
+====
+To view the additional flags available for machine pool creation, run the `ocm create machine-pool --help` command.
+====
+
+
+For more information about {GCP} instance types and availability zones, see the _Additional resources_ section.
+
 [role="_additional-resources"]
 == Additional resources
 * xref:../../osd_cluster_admin/osd_nodes/osd-nodes-about-autoscaling-nodes.adoc#osd-nodes-about-autoscaling-nodes[About autoscaling]
+
+* xref:../../osd_architecture/osd_policy/osd-service-definition.adoc#gcp-compute-types_osd-service-definition[Google Cloud instance types]
+
+* xref:../../osd_architecture/osd_policy/osd-service-definition.adoc#gcp-regions-availability-zones_osd-service-definition[Google Cloud regions and availability zones]
\ No newline at end of file
diff --git a/osd_planning/gcp-ccs.adoc b/osd_planning/gcp-ccs.adoc
index 968be0ed5dd4..195baa506bff 100644
--- a/osd_planning/gcp-ccs.adoc
+++ b/osd_planning/gcp-ccs.adoc
@@ -26,4 +26,4 @@ include::modules/osd-gcp-psc-firewall-prerequisites.adoc[leveloffset=+1]
 
 * For more information about creating an {product-title} cluster with the Workload Identity Federation (WIF) authentication type, see xref:../osd_gcp_clusters/creating-a-gcp-cluster-with-workload-identity-federation.adoc#create-wif-cluster-cli_osd-creating-a-cluster-on-gcp-with-workload-identity-federation[Creating a WIF configuration].
 
-* For more information about the specific roles and permissions that are specific to clusters created when using the Workload Identity Federation (WIF) authentication type, see link:https://github.com/openshift/managed-cluster-config/blob/master/resources/wif/4.17/vanilla.yaml[managed-cluster-config].
+* For more information about the specific roles and permissions that are specific to clusters created when using the Workload Identity Federation (WIF) authentication type, see link:https://github.com/openshift/managed-cluster-config/blob/master/resources/wif/4.18/vanilla.yaml[managed-cluster-config].
diff --git a/osd_whats_new/osd-whats-new.adoc b/osd_whats_new/osd-whats-new.adoc
index 71cea1849655..edd47082bd0d 100644
--- a/osd_whats_new/osd-whats-new.adoc
+++ b/osd_whats_new/osd-whats-new.adoc
@@ -10,11 +10,32 @@ With its foundation in Kubernetes, {product-title} is a complete {OCP} cluster p
 
 {product-title} is professionally managed by Red Hat and hosted on {GCP} or {AWS}. Each {product-title} cluster includes a fully managed link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/architecture/control-plane[control plane] (Control and Infrastructure nodes), application nodes, installation and management by Red Hat Site Reliability Engineers (SRE), premium Red Hat Support, and cluster services such as logging, metrics, monitoring, notifications portal, and a cluster portal.
 
-{product-title} clusters are available on the link:https://console.redhat.com/openshift[Hybrid Cloud Console]. With the Red Hat {cluster-manager} application, you can deploy {product-title} clusters to either on-premises or cloud environments.
+{product-title} clusters are available on the link:https://console.redhat.com/openshift[Hybrid Cloud Console]. With the Red Hat {cluster-manager} application, you can deploy {product-title} clusters to either on-premise or cloud environments.
 
 [id="osd-new-changes-and-updates_{context}"]
 == New changes and updates
 
+[id="osd-q1-2025_{context}"]
+=== Q1 2025
+
+* **New version of {product-title} available.** {product-title} on {gcp} and {product-title} on {aws} versions 4.18 are now available. For more information about upgrading to this latest version, see xref:../upgrading/osd-upgrades.adoc#osd-upgrades[Red Hat OpenShift Dedicated cluster upgrades].
+* **Support for assigning newly created machine pools to specific availability zones within a Multi-AZ cluster.**
+{product-title} on {GCP} users can now assign machine pools to specific availability zones using the {cluster-manager} CLI (`ocm`). For more information, see xref:../osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc#deploying-a-machine-pool-in-a-single-availability-zone-within-a-multi-az-cluster[Deploying a machine pool in a single availability zone within a Multi-AZ cluster].
+* ** Support for specifying {product-title} versions when creating or updating a Workload Identity Federation (WIF) configuration.**
+{product-title} on {GCP} users can now specify minor versions when creating or updating a WIF configuration. For more information, see xref:../osd_gcp_clusters/creating-a-gcp-cluster-with-workload-identity-federation.adoc#create-wif-cluster-cli_osd-creating-a-cluster-on-gcp-with-workload-identity-federation[Creating a Workload Identity Federation cluster using the OCM CLI].
+
+* **Cluster node limit update.** {product-title} clusters versions 4.14.14 and greater can now scale to 249 worker nodes. This is an increase from the previous limit of 180 nodes. For more information, see xref:../osd_planning/osd-limits-scalability.adoc#osd-limits-scalability[limits and scalability].
+// * **{product-title} SDN network plugin blocks future major upgrades**
+* **Initiate live migration from OpenShift SDN to OVN-Kubernetes.**
+As part of the {product-title} move to OVN-Kubernetes as the only supported network plugin starting with {product-title} version 4.17, users can now initiate live migration from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin.
++
+If your cluster uses the OpenShift SDN network plugin, you cannot upgrade to future major versions of {product-title} without migrating to OVN-Kubernetes.
++
+For more information about migrating to OVN-Kubernetes, see xref:../networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn-osd.adoc#migrate-from-openshift-sdn[Migrating from OpenShift SDN network plugin to OVN-Kubernetes network plugin].
+
+
+* **Red{nbsp}Hat SRE log-based alerting endpoints have been updated.** {product-title} customers who are using a firewall to control egress traffic can now remove all references to `*.osdsecuritylogs.splunkcloud.com:9997` from your firewall allowlist. {product-title} clusters still require the `http-inputs-osdsecuritylogs.splunkcloud.com:443` log-based alerting endpoint to be accessible from the cluster.
+
 [id="osd-q4-2024_{context}"]
 === Q4 2024
 
@@ -30,6 +51,9 @@ PSC is a capability of Google Cloud networking that enables private communicatio
 +
 For more information, see  xref:../osd_gcp_clusters/creating-a-gcp-psc-enabled-private-cluster.adoc#creating-a-gcp-psc-enabled-private-cluster[Private Service Connect overview].
 
+* ** Support for GCP A3 instances with NVIDIA H100 80GB GPUs.** {product-title} on {GCP} now supports A3 instance types with NVIDIA H100 80GB GPUs. The GCP A3 instance type is available in all three zones of a GCP region, which is a prerequisite for multi-AZ deployment. For more information, see xref:../osd_architecture/osd_policy/osd-service-definition.adoc#gcp-compute-types_osd-service-definition[Google Cloud compute types].
+
+
 [id="osd-q3-2024_{context}"]
 === Q3 2024
 
diff --git a/post_installation_configuration/changing-cloud-credentials-configuration.adoc b/post_installation_configuration/changing-cloud-credentials-configuration.adoc
index 7e1b0f47e08a..e63e622f8c20 100644
--- a/post_installation_configuration/changing-cloud-credentials-configuration.adoc
+++ b/post_installation_configuration/changing-cloud-credentials-configuration.adoc
@@ -10,21 +10,41 @@ For supported configurations, you can change how {product-title} authenticates w
 
 To determine which cloud credentials strategy your cluster uses, see xref:../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#cco-determine-mode_about-cloud-credential-operator[Determining the Cloud Credential Operator mode].
 
-[id="post-install-rotate-remove-cloud-creds_{context}"]
-== Rotating or removing cloud provider credentials
-
-After installing {product-title}, some organizations require the rotation or removal of the cloud provider credentials that were used during the initial installation.
-
-To allow the cluster to use the new credentials, you must update the secrets that the xref:../operators/operator-reference.adoc#cloud-credential-operator_cluster-operators-ref[Cloud Credential Operator (CCO)] uses to manage cloud provider credentials.
+[id="ccoctl-rotate-cloud-creds_{context}"]
+== Rotating cloud provider service keys with the Cloud Credential Operator utility
+
+Some organizations require the rotation of the service keys that authenticate the cluster.
+You can use the Cloud Credential Operator (CCO) utility (`ccoctl`) to update keys for clusters installed on the following cloud providers:
+
+* xref:../post_installation_configuration/changing-cloud-credentials-configuration.adoc#rotating-bound-service-keys_key-rotation-aws[{aws-first} with {sts-first}]
+* xref:../post_installation_configuration/changing-cloud-credentials-configuration.adoc#rotating-bound-service-keys_key-rotation-gcp[{gcp-first} with {gcp-wid-short}]
+* xref:../post_installation_configuration/changing-cloud-credentials-configuration.adoc#rotating-bound-service-keys_key-rotation-azure[{azure-first} with {entra-short}]
+* xref:../post_installation_configuration/changing-cloud-credentials-configuration.adoc#refreshing-service-ids-ibm-cloud_changing-cloud-credentials-configuration[{ibm-cloud-title}]
+
+:context: key-rotation-aws
+//Rotating OIDC bound service account signer keys
+include::modules/rotating-bound-service-keys.adoc[leveloffset=+2]
+:!context: key-rotation-aws
+
+:context: key-rotation-gcp
+//Rotating OIDC bound service account signer keys
+include::modules/rotating-bound-service-keys.adoc[leveloffset=+2]
+:!context: key-rotation-gcp
+
+:context: key-rotation-azure
+//Rotating OIDC bound service account signer keys
+include::modules/rotating-bound-service-keys.adoc[leveloffset=+2]
+:!context: key-rotation-azure
+:context: changing-cloud-credentials-configuration
 
-[id="ccoctl-rotate-remove-cloud-creds_{context}"]
-=== Rotating cloud provider credentials with the Cloud Credential Operator utility
+//Rotating {ibm-cloud-title} credentials
+include::modules/refreshing-service-ids-ibm-cloud.adoc[leveloffset=+2]
 
-// Right now only IBM can do this, but it makes sense to set this up so that other clouds can be added.
-The Cloud Credential Operator (CCO) utility `ccoctl` supports updating secrets for clusters installed on {ibm-cloud-name}.
+[id="post-install-rotate-cloud-creds_{context}"]
+== Rotating cloud provider credentials
 
-//Rotating {ibm-cloud-title} credentials with ccoctl
-include::modules/refreshing-service-ids-ibm-cloud.adoc[leveloffset=+3]
+Some organizations require the rotation of the cloud provider credentials.
+To allow the cluster to use the new credentials, you must update the secrets that the xref:../operators/operator-reference.adoc#cloud-credential-operator_cluster-operators-ref[Cloud Credential Operator (CCO)] uses to manage cloud provider credentials.
 
 //Rotating cloud provider credentials manually
 include::modules/manually-rotating-cloud-creds.adoc[leveloffset=+2]
@@ -35,6 +55,13 @@ include::modules/manually-rotating-cloud-creds.adoc[leveloffset=+2]
 * xref:../authentication/managing_cloud_provider_credentials/cco-mode-passthrough.html#cco-mode-passthrough[The Cloud Credential Operator in passthrough mode]
 * xref:../storage/container_storage_interface/persistent-storage-csi-vsphere.adoc#persistent-storage-csi-vsphere[vSphere CSI Driver Operator]
 
+[id="post-install-remove-cloud-creds_{context}"]
+== Removing cloud provider credentials
+//TODO: split out rotate, maintain, and remove and bumpe everything up one level
+
+After installing {product-title}, some organizations require the removal of the cloud provider credentials that were used during the initial installation.
+To allow the cluster to use the new credentials, you must update the secrets that the xref:../operators/operator-reference.adoc#cloud-credential-operator_cluster-operators-ref[Cloud Credential Operator (CCO)] uses to manage cloud provider credentials.
+
 //Removing cloud provider credentials manually
 include::modules/manually-removing-cloud-creds.adoc[leveloffset=+2]
 
diff --git a/post_installation_configuration/cluster-tasks.adoc b/post_installation_configuration/cluster-tasks.adoc
index 1f98e29828dc..fd7b89e410c3 100644
--- a/post_installation_configuration/cluster-tasks.adoc
+++ b/post_installation_configuration/cluster-tasks.adoc
@@ -119,7 +119,7 @@ documentation for details on how and when you can create additional resource ins
 |`alertmanager.monitoring.coreos.com`
 |`main`
 |`openshift-monitoring`
-|Controls the xref:../observability/monitoring/managing-alerts.adoc#managing-alerts[Alertmanager] deployment parameters.
+|Controls the xref:../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alerts-and-notifications[Alertmanager] deployment parameters.
 
 |`ingresscontroller.operator.openshift.io`
 |`default`
@@ -296,13 +296,11 @@ include::modules/infrastructure-moving-registry.adoc[leveloffset=+2]
 
 include::modules/infrastructure-moving-monitoring.adoc[leveloffset=+2]
 
-[id="custer-tasks-moving-logging-resources"]
-=== Moving {logging} resources
-
-For information about moving {logging} resources, see:
-
-* xref:../observability/logging/scheduling_resources/logging-node-selectors.adoc#logging-node-selectors[Using node selectors to move logging resources]
-* xref:../observability/logging/scheduling_resources/logging-taints-tolerations.adoc#cluster-logging-logstore-tolerations_logging-taints-tolerations[Using taints and tolerations to control logging pod placement]
+include::modules/cluster-autoscaler-about.adoc[leveloffset=+1]
+include::modules/cluster-autoscaler-cr.adoc[leveloffset=+2]
+:FeatureName: cluster autoscaler
+:FeatureResourceName: ClusterAutoscaler
+include::modules/deploying-resource.adoc[leveloffset=+2]
 
 [id="custer-tasks-applying-autoscaling"]
 == Applying autoscaling to your cluster
diff --git a/post_installation_configuration/configuring-alert-notifications.adoc b/post_installation_configuration/configuring-alert-notifications.adoc
index 8fde499c73f0..d253eeaf1aa7 100644
--- a/post_installation_configuration/configuring-alert-notifications.adoc
+++ b/post_installation_configuration/configuring-alert-notifications.adoc
@@ -14,5 +14,5 @@ include::modules/monitoring-sending-notifications-to-external-systems.adoc[level
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
-* xref:../observability/monitoring/managing-alerts.adoc#configuring-alert-receivers_managing-alerts[Configuring alert receivers]
+* xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+* xref:../observability/monitoring/configuring-user-workload-monitoring/configuring-alerts-and-notifications-uwm.adoc#configuring-alert-notifications_configuring-alerts-and-notifications-uwm[Configuring alert notifications]
diff --git a/post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc b/post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc
index ffdc7d69dc7d..63d0d5234731 100644
--- a/post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc
+++ b/post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc
@@ -12,13 +12,29 @@ These release notes track the development of the Multiarch Tuning Operator.
 
 For more information, see xref:../../post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator].
 
+[id="multi-arch-tuning-operator-release-notes-1-1-0_{context}"]
+== Release notes for the Multiarch Tuning Operator 1.1.0
 
-[id="multi-arch-tuning-operator-release-notes-1.0.0_{context}"]
+Issued: 18 March 2024
+
+[id="multi-arch-tuning-operator-1-1-0-new-features-and-enhancements_{context}"]
+=== New features and enhancements
+
+* The Multiarch Tuning Operator is now supported on managed offerings, including ROSA with Hosted Control Planes (HCP) and other HCP environments.
+
+* With this release, you can configure architecture-aware workload scheduling by using the new `plugins` field in the `ClusterPodPlacementConfig` object. You can use the `plugins.nodeAffinityScoring` field to set architecture preferences for pod placement. If you enable the `nodeAffinityScoring` plugin, the scheduler first filters out nodes that do not meet the pod requirements. Then, the scheduler prioritizes the remaining nodes based on the architecture scores defined in the `nodeAffinityScoring.platforms` field.
+
+[id="multi-arch-tuning-operator-1-1-0-bug-fixes_{context}"]
+==== Bug fixes
+
+* With this release, the Multiarch Tuning Operator does not update the `nodeAffinity` field for pods that are managed by a daemon set. (link:https://issues.redhat.com/browse/OCPBUGS-45885[*OCPBUGS-45885*])
+
+[id="multi-arch-tuning-operator-release-notes-1-0-0_{context}"]
 == Release notes for the Multiarch Tuning Operator 1.0.0
 
 Issued: 31 October 2024
 
-[id="multi-arch-tuning-operator-1.0.0-new-features-and-enhancements_{context}"]
+[id="multi-arch-tuning-operator-1-0-0-new-features-and-enhancements_{context}"]
 === New features and enhancements
 
 * With this release, the Multiarch Tuning Operator supports custom network scenarios and cluster-wide custom registries configurations.
diff --git a/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc b/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc
index 60b97a6e518d..53fec285dead 100644
--- a/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc
+++ b/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc
@@ -12,7 +12,7 @@ Architecture-aware workload scheduling allows the scheduler to place pods onto n
 
 By default, the scheduler does not consider the architecture of a pod's container images when determining the placement of new pods onto nodes.
 
-To enable architecture-aware workload scheduling, you must create the `ClusterPodPlacementConfig` object. When you create the `ClusterPodPlacementConfig` object, the Multiarch Tuning Operator deploys the necessary operands to support architecture-aware workload scheduling.
+To enable architecture-aware workload scheduling, you must create the `ClusterPodPlacementConfig` object. When you create the `ClusterPodPlacementConfig` object, the Multiarch Tuning Operator deploys the necessary operands to support architecture-aware workload scheduling. You can also use the `nodeAffinityScoring` plugin in the `ClusterPodPlacementConfig` object to set cluster-wide scores for node architectures. If you enable the `nodeAffinityScoring` plugin, the scheduler first filters nodes with compatible architectures and then places the pod on the node with the highest score.
 
 When a pod is created, the operands perform the following actions: 
 
@@ -30,6 +30,14 @@ Note the following operand behaviors:
 * If the `nodeSelector` field is not configured with the `kubernetes.io/arch` label for a workload, the operand updates the `nodeAffinity` field for that workload. However, in that `nodeAffinity` field, the operand updates only the node selector terms that are not configured with the `kubernetes.io/arch` label.
 
 * If the `nodeName` field is already set, the Multiarch Tuning Operator does not process the pod.
+
+* If the pod is owned by a DaemonSet, the operand does not update the the `nodeAffinity` field.
+
+* If both `nodeSelector` or `nodeAffinity` and `preferredAffinity` fields are set for the `kubernetes.io/arch` label, the operand does not update the `nodeAffinity` field.
+
+* If only `nodeSelector` or `nodeAffinity` field is set for the `kubernetes.io/arch` label and the `nodeAffinityScoring` plugin is disabled, the operand does not update the `nodeAffinity` field.
+
+* If the `nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution` field already contains terms that score nodes based on the `kubernetes.io/arch` label, the operand ignores the configuration in the `nodeAffinityScoring` plugin.
 ====
 
 //Installing Multiarch Tuning Operator
diff --git a/registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc b/registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc
index 0089961465d0..4744b2118eeb 100644
--- a/registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc
+++ b/registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc
@@ -29,4 +29,4 @@ include::modules/registry-configuring-registry-storage-rhodf-cephfs.adoc[levelof
 == Additional resources
 
 * xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
-* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
+* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
diff --git a/registry/configuring_registry_storage/configuring-registry-storage-nutanix.adoc b/registry/configuring_registry_storage/configuring-registry-storage-nutanix.adoc
index 489ff773b86d..d1cd042c676f 100644
--- a/registry/configuring_registry_storage/configuring-registry-storage-nutanix.adoc
+++ b/registry/configuring_registry_storage/configuring-registry-storage-nutanix.adoc
@@ -30,4 +30,4 @@ include::modules/registry-configuring-registry-storage-rhodf-cephfs.adoc[levelof
 == Additional resources
 
 * xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
-* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
+* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
diff --git a/registry/configuring_registry_storage/configuring-registry-storage-rhodf.adoc b/registry/configuring_registry_storage/configuring-registry-storage-rhodf.adoc
index 2c41bc9b66da..29f2c9b0b3ce 100644
--- a/registry/configuring_registry_storage/configuring-registry-storage-rhodf.adoc
+++ b/registry/configuring_registry_storage/configuring-registry-storage-rhodf.adoc
@@ -18,5 +18,5 @@ include::modules/registry-configuring-registry-storage-rhodf-cephfs.adoc[levelof
 [role="_additional-resources"]
 == Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
+* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
 * link:https://access.redhat.com/solutions/6719951[Performance tuning guide for Multicloud Object Gateway (NooBaa)]
diff --git a/registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc b/registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc
index 57c33fa3086a..0b483f85ae0d 100644
--- a/registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc
+++ b/registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc
@@ -31,4 +31,4 @@ include::modules/registry-configuring-registry-storage-rhodf-cephfs.adoc[levelof
 == Additional resources
 
 * xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#optimizing-storage[Recommended configurable storage technology]
-* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
+* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/managing_and_allocating_storage_resources/index#configuring-image-registry-to-use-openshift-data-foundation_rhodf[Configuring Image Registry to use OpenShift Data Foundation]
diff --git a/release_notes/ocp-4-19-release-notes.adoc b/release_notes/ocp-4-19-release-notes.adoc
new file mode 100644
index 000000000000..152d0ab12ad5
--- /dev/null
+++ b/release_notes/ocp-4-19-release-notes.adoc
@@ -0,0 +1,11 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="ocp-4-19-release-notes"]
+= {product-title} {product-version} release notes
+include::_attributes/common-attributes.adoc[]
+:context: release-notes
+
+Do not add or edit release notes here. Edit release notes directly in the branch that they are relevant for.
+
+Release note changes should be added or edited in their own PR.
+
+This file is here to allow builds to work.
\ No newline at end of file
diff --git a/rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc b/rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc
index 4499d75fbf4d..70e34bc974ef 100644
--- a/rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc
+++ b/rest_api/monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc
@@ -356,7 +356,7 @@ Cannot be set at the same time as `authorization`, or `basicAuth`.
 
 | `params{}`
 | `array (string)`
-| 
+|
 
 | `path`
 | `string`
@@ -382,7 +382,7 @@ metadata labels.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields.
 
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 
@@ -780,7 +780,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -1316,7 +1316,7 @@ metadata labels.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields.
 
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 --
@@ -1866,7 +1866,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc#podmonitor-monitoring-coreos-com-v1[`PodMonitor`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -1999,7 +1999,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/podmonitor-monitoring-coreos-com-v1.adoc#podmonitor-monitoring-coreos-com-v1[`PodMonitor`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rest_api/monitoring_apis/probe-monitoring-coreos-com-v1.adoc b/rest_api/monitoring_apis/probe-monitoring-coreos-com-v1.adoc
index bd213298c117..db3c6a967fa4 100644
--- a/rest_api/monitoring_apis/probe-monitoring-coreos-com-v1.adoc
+++ b/rest_api/monitoring_apis/probe-monitoring-coreos-com-v1.adoc
@@ -530,7 +530,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -1143,9 +1143,9 @@ Type::
 | RelabelConfigs to apply to the label set of the target before it gets
 scraped.
 The original ingress address is available via the
-`__tmp_prometheus_ingress_address` label. It can be used to customize the
+`\__tmp_prometheus_ingress_address` label. It can be used to customize the
 probed URL.
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 
 | `relabelingConfigs[]`
@@ -1194,9 +1194,9 @@ Description::
 RelabelConfigs to apply to the label set of the target before it gets
 scraped.
 The original ingress address is available via the
-`__tmp_prometheus_ingress_address` label. It can be used to customize the
+`\__tmp_prometheus_ingress_address` label. It can be used to customize the
 probed URL.
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 --
 
@@ -1868,7 +1868,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/probe-monitoring-coreos-com-v1.adoc#probe-monitoring-coreos-com-v1[`Probe`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -2001,7 +2001,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/probe-monitoring-coreos-com-v1.adoc#probe-monitoring-coreos-com-v1[`Probe`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc b/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc
index 25ab2c3b8ef8..42fbb3934b97 100644
--- a/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc
+++ b/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc
@@ -823,7 +823,7 @@ in a breaking way.
 
 | `scrapeClasses[]`
 | `object`
-| 
+|
 
 | `scrapeConfigNamespaceSelector`
 | `object`
@@ -968,7 +968,7 @@ the triple <key,value,effect> using the matching operator <operator>.
 
 | `topologySpreadConstraints[]`
 | `object`
-| 
+|
 
 | `tracingConfig`
 | `object`
@@ -4368,7 +4368,7 @@ Type::
 
 | `deny`
 | `boolean`
-| 
+|
 
 |===
 === .spec.containers
@@ -10201,7 +10201,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -10475,7 +10475,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -11484,7 +11484,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -11982,7 +11982,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -13541,7 +13541,7 @@ More info: https://prometheus.io/docs/prometheus/latest/configuration/configurat
 | Relabelings configures the relabeling rules to apply to all scrape targets.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields
-like `__meta_kubernetes_namespace` and `__meta_kubernetes_service_name`.
+like `\__meta_kubernetes_namespace` and `\__meta_kubernetes_service_name`.
 Then the Operator adds the scrape class relabelings defined here.
 Then the Operator adds the target-specific relabelings defined in the scrape object.
 
@@ -13683,7 +13683,7 @@ Description::
 Relabelings configures the relabeling rules to apply to all scrape targets.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields
-like `__meta_kubernetes_namespace` and `__meta_kubernetes_service_name`.
+like `\__meta_kubernetes_namespace` and `\__meta_kubernetes_service_name`.
 Then the Operator adds the scrape class relabelings defined here.
 Then the Operator adds the target-specific relabelings defined in the scrape object.
 
@@ -15850,7 +15850,7 @@ persistent volume is being resized.
 
 | `status`
 | `string`
-| 
+|
 
 | `type`
 | `string`
@@ -20992,7 +20992,7 @@ being performed. Only delete actions will be performed.
 
 | `shardStatuses[]`
 | `object`
-| 
+|
 
 | `shards`
 | `integer`
@@ -21246,7 +21246,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#prometheus-monitoring-coreos-com-v1[`Prometheus`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -21379,7 +21379,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#prometheus-monitoring-coreos-com-v1[`Prometheus`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -21481,7 +21481,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -21583,7 +21583,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc#prometheus-monitoring-coreos-com-v1[`Prometheus`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc b/rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc
index 8056cde2491c..238ebd332ad5 100644
--- a/rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc
+++ b/rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc
@@ -346,7 +346,7 @@ Cannot be set at the same time as `authorization`, or `basicAuth`.
 
 | `params{}`
 | `array (string)`
-| 
+|
 
 | `path`
 | `string`
@@ -372,7 +372,7 @@ metadata labels.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields.
 
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 
@@ -768,7 +768,7 @@ It requires Prometheus >= v2.43.0 or Alertmanager >= 0.25.0.
 
 | `proxyConnectHeader{}`
 | `array`
-| 
+|
 
 | `proxyConnectHeader{}[]`
 | `object`
@@ -1304,7 +1304,7 @@ metadata labels.
 
 The Operator automatically adds relabelings for a few standard Kubernetes fields.
 
-The original scrape job's name is available via the `__tmp_prometheus_job_name` label.
+The original scrape job's name is available via the `\__tmp_prometheus_job_name` label.
 
 More info: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
 --
@@ -1894,7 +1894,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc#servicemonitor-monitoring-coreos-com-v1[`ServiceMonitor`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -2027,7 +2027,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../monitoring_apis/servicemonitor-monitoring-coreos-com-v1.adoc#servicemonitor-monitoring-coreos-com-v1[`ServiceMonitor`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rest_api/network_apis/egressfirewall-k8s-ovn-org-v1.adoc b/rest_api/network_apis/egressfirewall-k8s-ovn-org-v1.adoc
index 19e3b60b4eb6..951a9cd3e267 100644
--- a/rest_api/network_apis/egressfirewall-k8s-ovn-org-v1.adoc
+++ b/rest_api/network_apis/egressfirewall-k8s-ovn-org-v1.adoc
@@ -11,7 +11,11 @@ toc::[]
 Description::
 +
 --
-EgressFirewall describes the current egress firewall for a Namespace. Traffic from a pod to an IP address outside the cluster will be checked against each EgressFirewallRule in the pod's namespace's EgressFirewall, in order. If no rule matches (or no EgressFirewall is present) then the traffic will be allowed by default.
+EgressFirewall describes the current egress firewall for a Namespace.
+Traffic from a pod to an IP address outside the cluster will be checked against
+each EgressFirewallRule in the pod's namespace's EgressFirewall, in
+order. If no rule matches (or no EgressFirewall is present) then the traffic
+will be allowed by default.
 --
 
 Type::
@@ -191,18 +195,23 @@ Type::
 
 | `dnsName`
 | `string`
-| dnsName is the domain name to allow/deny traffic to. If this is set, cidrSelector and nodeSelector must be unset. For a wildcard DNS name, the '*' will match only one label. Additionally, only a single '*' can be used at the beginning of the wildcard DNS name. For example, '*.example.com' will match 'sub1.example.com' but won't match 'sub2.sub1.example.com'
+| dnsName is the domain name to allow/deny traffic to. If this is set, cidrSelector and nodeSelector must be unset.
+For a wildcard DNS name, the '*' will match only one label. Additionally, only a single '*' can be
+used at the beginning of the wildcard DNS name. For example, '*.example.com' will match 'sub1.example.com'
+but won't match 'sub2.sub1.example.com'.
 
 | `nodeSelector`
 | `object`
-| nodeSelector will allow/deny traffic to the Kubernetes node IP of selected nodes. If this is set, cidrSelector and DNSName must be unset.
+| nodeSelector will allow/deny traffic to the Kubernetes node IP of selected nodes. If this is set,
+cidrSelector and DNSName must be unset.
 
 |===
 === .spec.egress[].to.nodeSelector
 Description::
 +
 --
-nodeSelector will allow/deny traffic to the Kubernetes node IP of selected nodes. If this is set, cidrSelector and DNSName must be unset.
+nodeSelector will allow/deny traffic to the Kubernetes node IP of selected nodes. If this is set,
+cidrSelector and DNSName must be unset.
 --
 
 Type::
@@ -221,11 +230,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.egress[].to.nodeSelector.matchExpressions
@@ -245,7 +257,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -267,11 +280,15 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .status
diff --git a/rest_api/network_apis/network-apis-index.adoc b/rest_api/network_apis/network-apis-index.adoc
index 690ca6bf0b58..5561b64ab166 100644
--- a/rest_api/network_apis/network-apis-index.adoc
+++ b/rest_api/network_apis/network-apis-index.adoc
@@ -69,7 +69,11 @@ Type::
 Description::
 +
 --
-EgressFirewall describes the current egress firewall for a Namespace. Traffic from a pod to an IP address outside the cluster will be checked against each EgressFirewallRule in the pod's namespace's EgressFirewall, in order. If no rule matches (or no EgressFirewall is present) then the traffic will be allowed by default.
+EgressFirewall describes the current egress firewall for a Namespace.
+Traffic from a pod to an IP address outside the cluster will be checked against
+each EgressFirewallRule in the pod's namespace's EgressFirewall, in
+order. If no rule matches (or no EgressFirewall is present) then the traffic
+will be allowed by default.
 --
 
 Type::
diff --git a/rest_api/objects/index.adoc b/rest_api/objects/index.adoc
index b12a3e9d7b33..abba6dbb087b 100644
--- a/rest_api/objects/index.adoc
+++ b/rest_api/objects/index.adoc
@@ -1339,7 +1339,7 @@ Required::
 
 | `items`
 | xref:../oauth_apis/useroauthaccesstoken-oauth-openshift-io-v1.adoc#useroauthaccesstoken-oauth-openshift-io-v1[`array (UserOAuthAccessToken)`]
-| 
+|
 
 | `kind`
 | `string`
@@ -1818,12 +1818,12 @@ Type::
 | Property | Type | Description
 
 | `owned`
-| xref:../objects/index.adoc#com-github-operator-framework-api-pkg-operators-v1alpha1-APIServiceDescription[`array (APIServiceDescription)`]
-| 
+| `array (APIServiceDescription)`
+|
 
 | `required`
-| xref:../objects/index.adoc#com-github-operator-framework-api-pkg-operators-v1alpha1-APIServiceDescription[`array (APIServiceDescription)`]
-| 
+| `array (APIServiceDescription)`
+|
 
 |===
 
@@ -1851,12 +1851,12 @@ Type::
 | Property | Type | Description
 
 | `owned`
-| xref:../objects/index.adoc#com-github-operator-framework-api-pkg-operators-v1alpha1-CRDDescription[`array (CRDDescription)`]
-| 
+| `array (CRDDescription)`
+|
 
 | `required`
-| xref:../objects/index.adoc#com-github-operator-framework-api-pkg-operators-v1alpha1-CRDDescription[`array (CRDDescription)`]
-| 
+| `array (CRDDescription)`
+|
 
 |===
 
@@ -1886,11 +1886,11 @@ Required::
 
 | `supported`
 | `boolean`
-| 
+|
 
 | `type`
 | `string`
-| 
+|
 
 |===
 
@@ -1923,7 +1923,7 @@ Required::
 
 | `items`
 | xref:../operatorhub_apis/packagemanifest-packages-operators-coreos-com-v1.adoc#packagemanifest-packages-operators-coreos-com-v1[`array (PackageManifest)`]
-| 
+|
 
 | `kind`
 | `string`
@@ -1931,7 +1931,7 @@ Required::
 
 | `metadata`
 | xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-ListMeta[`ListMeta`]
-| 
+|
 
 |===
 
@@ -2628,7 +2628,7 @@ Required::
 
 | `metadata`
 | xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-ListMeta[`ListMeta`]
-| 
+|
 
 |===
 
@@ -2783,7 +2783,7 @@ Type::
 | defaultMode is optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
 
 | `items`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-KeyToPath[`array (KeyToPath)`]
+| `array (KeyToPath)`
 | items if unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'.
 
 | `name`
@@ -2828,7 +2828,7 @@ Required::
 | fsType to mount. Ex. "ext4", "xfs", "ntfs". If not provided, the empty value is passed to the associated CSI driver which will determine the default filesystem to apply.
 
 | `nodePublishSecretRef`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-LocalObjectReference[`LocalObjectReference`]
+| `LocalObjectReference`
 | nodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and  may be empty if no secret is required. If the secret object contains more than one secret, all secret references are passed.
 
 | `readOnly`
@@ -2914,7 +2914,7 @@ Required::
 | Variable references $(VAR_NAME) are expanded using the previously defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "".
 
 | `valueFrom`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-EnvVarSource[`EnvVarSource`]
+| `EnvVarSource`
 | Source for the environment variable's value. Cannot be used if value is not empty.
 
 |===
@@ -3085,15 +3085,15 @@ Required::
 
 | `lastTransitionTime`
 | xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-Time[`Time`]
-| 
+|
 
 | `message`
 | `string`
-| 
+|
 
 | `reason`
 | `string`
-| 
+|
 
 | `status`
 | `string`
@@ -3589,11 +3589,11 @@ Required::
 
 | `status`
 | `string`
-| 
+|
 
 | `type`
 | `string`
-| 
+|
 
 |===
 ..status.modifyVolumeStatus
@@ -3746,15 +3746,15 @@ Type::
 | accessModes contains all ways the volume can be mounted. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes
 
 | `awsElasticBlockStore`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-AWSElasticBlockStoreVolumeSource[`AWSElasticBlockStoreVolumeSource`]
+| `AWSElasticBlockStoreVolumeSource`
 | awsElasticBlockStore represents an AWS Disk resource that is attached to a kubelet's host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore
 
 | `azureDisk`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-AzureDiskVolumeSource[`AzureDiskVolumeSource`]
+| `AzureDiskVolumeSource`
 | azureDisk represents an Azure Data Disk mount on the host and bind mount to the pod.
 
 | `azureFile`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-AzureFilePersistentVolumeSource[`AzureFilePersistentVolumeSource`]
+| `AzureFilePersistentVolumeSource`
 | azureFile represents an Azure File Service mount on the host and bind mount to the pod.
 
 | `capacity`
@@ -3762,11 +3762,11 @@ Type::
 | capacity is the description of the persistent volume's resources and capacity. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity
 
 | `cephfs`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-CephFSPersistentVolumeSource[`CephFSPersistentVolumeSource`]
+| `CephFSPersistentVolumeSource`
 | cephFS represents a Ceph FS mount on the host that shares a pod's lifetime
 
 | `cinder`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-CinderPersistentVolumeSource[`CinderPersistentVolumeSource`]
+| `CinderPersistentVolumeSource`
 | cinder represents a cinder volume attached and mounted on kubelets host machine. More info: https://examples.k8s.io/mysql-cinder-pd/README.md
 
 | `claimRef`
@@ -3774,39 +3774,39 @@ Type::
 | claimRef is part of a bi-directional binding between PersistentVolume and PersistentVolumeClaim. Expected to be non-nil when bound. claim.VolumeName is the authoritative bind between PV and PVC. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#binding
 
 | `csi`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-CSIPersistentVolumeSource[`CSIPersistentVolumeSource`]
+| `CSIPersistentVolumeSource`
 | csi represents storage that is handled by an external CSI driver (Beta feature).
 
 | `fc`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-FCVolumeSource[`FCVolumeSource`]
+| `FCVolumeSource`
 | fc represents a Fibre Channel resource that is attached to a kubelet's host machine and then exposed to the pod.
 
 | `flexVolume`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-FlexPersistentVolumeSource[`FlexPersistentVolumeSource`]
+| `FlexPersistentVolumeSource`
 | flexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin.
 
 | `flocker`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-FlockerVolumeSource[`FlockerVolumeSource`]
+| `FlockerVolumeSource`
 | flocker represents a Flocker volume attached to a kubelet's host machine and exposed to the pod for its usage. This depends on the Flocker control service being running
 
 | `gcePersistentDisk`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-GCEPersistentDiskVolumeSource[`GCEPersistentDiskVolumeSource`]
+| `GCEPersistentDiskVolumeSource`
 | gcePersistentDisk represents a GCE Disk resource that is attached to a kubelet's host machine and then exposed to the pod. Provisioned by an admin. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk
 
 | `glusterfs`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-GlusterfsPersistentVolumeSource[`GlusterfsPersistentVolumeSource`]
+| `GlusterfsPersistentVolumeSource`
 | glusterfs represents a Glusterfs volume that is attached to a host and exposed to the pod. Provisioned by an admin. More info: https://examples.k8s.io/volumes/glusterfs/README.md
 
 | `hostPath`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-HostPathVolumeSource[`HostPathVolumeSource`]
+| `HostPathVolumeSource`
 | hostPath represents a directory on the host. Provisioned by a developer or tester. This is useful for single-node development and testing only! On-host storage is not supported in any way and WILL NOT WORK in a multi-node cluster. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath
 
 | `iscsi`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-ISCSIPersistentVolumeSource[`ISCSIPersistentVolumeSource`]
+| `ISCSIPersistentVolumeSource`
 | iscsi represents an ISCSI Disk resource that is attached to a kubelet's host machine and then exposed to the pod. Provisioned by an admin.
 
 | `local`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-LocalVolumeSource[`LocalVolumeSource`]
+| `LocalVolumeSource`
 | local represents directly-attached storage with node affinity
 
 | `mountOptions`
@@ -3814,11 +3814,11 @@ Type::
 | mountOptions is the list of mount options, e.g. ["ro", "soft"]. Not validated - mount will simply fail if one is invalid. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options
 
 | `nfs`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-NFSVolumeSource[`NFSVolumeSource`]
+| `NFSVolumeSource`
 | nfs represents an NFS mount on the host. Provisioned by an admin. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs
 
 | `nodeAffinity`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-VolumeNodeAffinity[`VolumeNodeAffinity`]
+| `VolumeNodeAffinity`
 | nodeAffinity defines constraints that limit what nodes this volume can be accessed from. This field influences the scheduling of pods that use this volume.
 
 | `persistentVolumeReclaimPolicy`
@@ -3831,23 +3831,23 @@ Possible enum values:
  - `"Retain"` means the volume will be left in its current phase (Released) for manual reclamation by the administrator. The default policy is Retain.
 
 | `photonPersistentDisk`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-PhotonPersistentDiskVolumeSource[`PhotonPersistentDiskVolumeSource`]
+| `PhotonPersistentDiskVolumeSource`
 | photonPersistentDisk represents a PhotonController persistent disk attached and mounted on kubelets host machine
 
 | `portworxVolume`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-PortworxVolumeSource[`PortworxVolumeSource`]
+| `PortworxVolumeSource`
 | portworxVolume represents a portworx volume attached and mounted on kubelets host machine
 
 | `quobyte`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-QuobyteVolumeSource[`QuobyteVolumeSource`]
+| `QuobyteVolumeSource`
 | quobyte represents a Quobyte mount on the host that shares a pod's lifetime
 
 | `rbd`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-RBDPersistentVolumeSource[`RBDPersistentVolumeSource`]
+| `RBDPersistentVolumeSource`
 | rbd represents a Rados Block Device mount on the host that shares a pod's lifetime. More info: https://examples.k8s.io/volumes/rbd/README.md
 
 | `scaleIO`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-ScaleIOPersistentVolumeSource[`ScaleIOPersistentVolumeSource`]
+| `ScaleIOPersistentVolumeSource`
 | scaleIO represents a ScaleIO persistent volume attached and mounted on Kubernetes nodes.
 
 | `storageClassName`
@@ -3855,7 +3855,7 @@ Possible enum values:
 | storageClassName is the name of StorageClass to which this persistent volume belongs. Empty value means that this volume does not belong to any StorageClass.
 
 | `storageos`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-StorageOSPersistentVolumeSource[`StorageOSPersistentVolumeSource`]
+| `StorageOSPersistentVolumeSource`
 | storageOS represents a StorageOS volume that is attached to the kubelet's host machine and mounted into the pod More info: https://examples.k8s.io/volumes/storageos/README.md
 
 | `volumeAttributesClassName`
@@ -3871,7 +3871,7 @@ Possible enum values:
  - `"Filesystem"` means the volume will be or is formatted with a filesystem.
 
 | `vsphereVolume`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-VsphereVirtualDiskVolumeSource[`VsphereVirtualDiskVolumeSource`]
+| `VsphereVirtualDiskVolumeSource`
 | vsphereVolume represents a vSphere volume attached and mounted on kubelets host machine
 
 |===
@@ -3984,7 +3984,7 @@ Type::
 | Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
 
 | `spec`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-PodSpec[`PodSpec`]
+| `PodSpec`
 | Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
 
 |===
@@ -4097,7 +4097,7 @@ Type::
 | hard is the set of desired hard limits for each named resource. More info: https://kubernetes.io/docs/concepts/policy/resource-quotas/
 
 | `scopeSelector`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-ScopeSelector_v2[`ScopeSelector_v2`]
+| `ScopeSelector_v2`
 | scopeSelector is also a collection of filters like scopes that must match each object tracked by a quota but expressed using ScopeSelectorOperator in combination with possible values. For a resource to match, both scopes AND scopeSelector (if specified in spec), must be matched.
 
 | `scopes`
@@ -4159,7 +4159,7 @@ Type::
 | Property | Type | Description
 
 | `claims`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-ResourceClaim[`array (ResourceClaim)`]
+| `array (ResourceClaim)`
 | Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container.
 
 This is an alpha field and requires enabling the DynamicResourceAllocation feature gate.
@@ -4296,7 +4296,7 @@ Type::
 | defaultMode is Optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
 
 | `items`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-KeyToPath[`array (KeyToPath)`]
+| `array (KeyToPath)`
 | items If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'.
 
 | `optional`
@@ -4465,7 +4465,7 @@ Type::
 | Property | Type | Description
 
 | `matchLabelExpressions`
-| xref:../objects/index.adoc#io-k8s-api-core-v1-TopologySelectorLabelRequirement[`array (TopologySelectorLabelRequirement)`]
+| `array (TopologySelectorLabelRequirement)`
 | A list of topology selector requirements by labels.
 
 |===
@@ -4899,7 +4899,7 @@ Type::
 | Property | Type | Description
 
 | `clusterRoleSelectors`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-LabelSelector_v3[`array (LabelSelector_v3)`]
+| `array (LabelSelector_v3)`
 | ClusterRoleSelectors holds a list of selectors which will be used to find ClusterRoles and create the rules. If any of the selectors match, then the ClusterRole's permissions will be added
 
 |===
@@ -5378,63 +5378,63 @@ Type::
 
 | `$ref`
 | `string`
-| 
+|
 
 | `$schema`
 | `string`
-| 
+|
 
 | `additionalItems`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaPropsOrBool[``]
-| 
+| ``
+|
 
 | `additionalProperties`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaPropsOrBool[``]
-| 
+| ``
+|
 
 | `allOf`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`array (undefined)`]
-| 
+|
 
 | `anyOf`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`array (undefined)`]
-| 
+|
 
 | `default`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSON[`JSON`]
+| `JSON`
 | default is a default value for undefined object fields. Defaulting is a beta feature under the CustomResourceDefaulting feature gate. Defaulting requires spec.preserveUnknownFields to be false.
 
 | `definitions`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`object (undefined)`]
-| 
+|
 
 | `dependencies`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaPropsOrStringArray[`object (undefined)`]
-| 
+| `object (undefined)`
+|
 
 | `description`
 | `string`
-| 
+|
 
 | `enum`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSON[`array (JSON)`]
-| 
+| `array (JSON)`
+|
 
 | `example`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSON[`JSON`]
-| 
+| `JSON`
+|
 
 | `exclusiveMaximum`
 | `boolean`
-| 
+|
 
 | `exclusiveMinimum`
 | `boolean`
-| 
+|
 
 | `externalDocs`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-ExternalDocumentation[`ExternalDocumentation`]
-| 
+| `ExternalDocumentation`
+|
 
 | `format`
 | `string`
@@ -5444,87 +5444,87 @@ Type::
 
 | `id`
 | `string`
-| 
+|
 
 | `items`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaPropsOrArray[``]
-| 
+| ``
+|
 
 | `maxItems`
 | `integer`
-| 
+|
 
 | `maxLength`
 | `integer`
-| 
+|
 
 | `maxProperties`
 | `integer`
-| 
+|
 
 | `maximum`
 | `number`
-| 
+|
 
 | `minItems`
 | `integer`
-| 
+|
 
 | `minLength`
 | `integer`
-| 
+|
 
 | `minProperties`
 | `integer`
-| 
+|
 
 | `minimum`
 | `number`
-| 
+|
 
 | `multipleOf`
 | `number`
-| 
+|
 
 | `not`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[``]
-| 
+|
 
 | `nullable`
 | `boolean`
-| 
+|
 
 | `oneOf`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`array (undefined)`]
-| 
+|
 
 | `pattern`
 | `string`
-| 
+|
 
 | `patternProperties`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`object (undefined)`]
-| 
+|
 
 | `properties`
 | xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-JSONSchemaProps[`object (undefined)`]
-| 
+|
 
 | `required`
 | `array (string)`
-| 
+|
 
 | `title`
 | `string`
-| 
+|
 
 | `type`
 | `string`
-| 
+|
 
 | `uniqueItems`
 | `boolean`
-| 
+|
 
 | `x-kubernetes-embedded-resource`
 | `boolean`
@@ -5584,7 +5584,7 @@ Defaults to atomic for arrays.
 | x-kubernetes-preserve-unknown-fields stops the API server decoding step from pruning fields which are not specified in the validation schema. This affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden.
 
 | `x-kubernetes-validations`
-| xref:../objects/index.adoc#io-k8s-apiextensions-apiserver-pkg-apis-apiextensions-v1-ValidationRule[`array (ValidationRule)`]
+| `array (ValidationRule)`
 | x-kubernetes-validations describes a list of validation rules written in the CEL expression language.
 
 |===
@@ -5612,7 +5612,7 @@ The serialization format is:
 
 	(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
 
-<decimalExponent> ::= "e" <signedNumber> \| "E" <signedNumber> 
+<decimalExponent> ::= "e" <signedNumber> \| "E" <signedNumber>
 
 No matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.
 
@@ -5735,7 +5735,7 @@ Type::
 | Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.
 
 | `preconditions`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-Preconditions[`Preconditions`]
+| `Preconditions`
 | Must be fulfilled before a deletion is carried out. If not possible, a 409 Conflict status will be returned.
 
 | `propagationPolicy`
@@ -5824,15 +5824,15 @@ Required::
 
 | `group`
 | `string`
-| 
+|
 
 | `kind`
 | `string`
-| 
+|
 
 | `version`
 | `string`
-| 
+|
 
 |===
 
@@ -5889,7 +5889,7 @@ Type::
 | Property | Type | Description
 
 | `matchExpressions`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-LabelSelectorRequirement_v2[`array (LabelSelectorRequirement_v2)`]
+| `array (LabelSelectorRequirement_v2)`
 | matchExpressions is a list of label selector requirements. The requirements are ANDed.
 
 | `matchLabels`
@@ -6052,7 +6052,7 @@ Applied only if Name is not specified. More info: https://git.k8s.io/community/c
 | Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
 
 | `managedFields`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-ManagedFieldsEntry[`array (ManagedFieldsEntry)`]
+| `array (ManagedFieldsEntry)`
 | ManagedFields maps workflow-id and version to the set of fields that are managed by that workflow. This is mostly for internal housekeeping, and users typically shouldn't need to set or understand this field. A workflow can be the user's name, a controller's name, or the name of a specific apply path like "ci-cd". The set of fields is always in the version that the workflow used when modifying the object.
 
 | `name`
@@ -6066,7 +6066,7 @@ Applied only if Name is not specified. More info: https://git.k8s.io/community/c
 Must be a DNS_LABEL. Cannot be updated. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces
 
 | `ownerReferences`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-OwnerReference[`array (OwnerReference)`]
+| `array (OwnerReference)`
 | List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller.
 
 | `resourceVersion`
@@ -6149,7 +6149,7 @@ Applied only if Name is not specified. More info: https://git.k8s.io/community/c
 | Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
 
 | `managedFields`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-ManagedFieldsEntry[`array (ManagedFieldsEntry)`]
+| `array (ManagedFieldsEntry)`
 | ManagedFields maps workflow-id and version to the set of fields that are managed by that workflow. This is mostly for internal housekeeping, and users typically shouldn't need to set or understand this field. A workflow can be the user's name, a controller's name, or the name of a specific apply path like "ci-cd". The set of fields is always in the version that the workflow used when modifying the object.
 
 | `name`
@@ -6163,7 +6163,7 @@ Applied only if Name is not specified. More info: https://git.k8s.io/community/c
 Must be a DNS_LABEL. Cannot be updated. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces
 
 | `ownerReferences`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-OwnerReference[`array (OwnerReference)`]
+| `array (OwnerReference)`
 | List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller.
 
 | `resourceVersion`
@@ -6214,7 +6214,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails[`StatusDetails`]
+| `StatusDetails`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6269,7 +6269,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6324,7 +6324,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6379,7 +6379,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6434,7 +6434,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6489,7 +6489,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6544,7 +6544,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6599,7 +6599,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6654,7 +6654,7 @@ Type::
 | Suggested HTTP return code for this status, 0 if not set.
 
 | `details`
-| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-StatusDetails_v2[`StatusDetails_v2`]
+| `StatusDetails_v2`
 | Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
 
 | `kind`
@@ -6728,7 +6728,7 @@ Required::
 
 | `type`
 | `string`
-| 
+|
 
 |===
 
diff --git a/rest_api/operator_apis/config-imageregistry-operator-openshift-io-v1.adoc b/rest_api/operator_apis/config-imageregistry-operator-openshift-io-v1.adoc
index edb2cdcf1f51..dce17e0f99fb 100644
--- a/rest_api/operator_apis/config-imageregistry-operator-openshift-io-v1.adoc
+++ b/rest_api/operator_apis/config-imageregistry-operator-openshift-io-v1.adoc
@@ -11,8 +11,10 @@ toc::[]
 Description::
 +
 --
-Config is the configuration object for a registry instance managed by the registry operator 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+Config is the configuration object for a registry instance managed by
+the registry operator
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
@@ -75,11 +77,13 @@ Required::
 
 | `defaultRoute`
 | `boolean`
-| defaultRoute indicates whether an external facing route for the registry should be created using the default generated hostname.
+| defaultRoute indicates whether an external facing route for the registry
+should be created using the default generated hostname.
 
 | `disableRedirect`
 | `boolean`
-| disableRedirect controls whether to route all data through the Registry, rather than redirecting to the backend.
+| disableRedirect controls whether to route all data through the Registry,
+rather than redirecting to the backend.
 
 | `httpSecret`
 | `string`
@@ -87,8 +91,11 @@ Required::
 
 | `logLevel`
 | `string`
-| logLevel is an intent based logging for an overall component.  It does not give fine grained control, but it is a simple way to manage coarse grained logging choices that operators have to interpret for their operands. 
- Valid values are: "Normal", "Debug", "Trace", "TraceAll". Defaults to "Normal".
+| logLevel is an intent based logging for an overall component.  It does not give fine grained control, but it is a
+simple way to manage coarse grained logging choices that operators have to interpret for their operands.
+
+Valid values are: "Normal", "Debug", "Trace", "TraceAll".
+Defaults to "Normal".
 
 | `logging`
 | `integer`
@@ -100,24 +107,31 @@ Required::
 
 | `nodeSelector`
 | `object (string)`
-| nodeSelector defines the node selection constraints for the registry pod.
+| nodeSelector defines the node selection constraints for the registry
+pod.
 
 | `observedConfig`
 | ``
-| observedConfig holds a sparse config that controller has observed from the cluster state.  It exists in spec because it is an input to the level for the operator
+| observedConfig holds a sparse config that controller has observed from the cluster state.  It exists in spec because
+it is an input to the level for the operator
 
 | `operatorLogLevel`
 | `string`
-| operatorLogLevel is an intent based logging for the operator itself.  It does not give fine grained control, but it is a simple way to manage coarse grained logging choices that operators have to interpret for themselves. 
- Valid values are: "Normal", "Debug", "Trace", "TraceAll". Defaults to "Normal".
+| operatorLogLevel is an intent based logging for the operator itself.  It does not give fine grained control, but it is a
+simple way to manage coarse grained logging choices that operators have to interpret for themselves.
+
+Valid values are: "Normal", "Debug", "Trace", "TraceAll".
+Defaults to "Normal".
 
 | `proxy`
 | `object`
-| proxy defines the proxy to be used when calling master api, upstream registries, etc.
+| proxy defines the proxy to be used when calling master api, upstream
+registries, etc.
 
 | `readOnly`
 | `boolean`
-| readOnly indicates whether the registry instance should reject attempts to push new images or delete existing ones.
+| readOnly indicates whether the registry instance should reject attempts
+to push new images or delete existing ones.
 
 | `replicas`
 | `integer`
@@ -125,7 +139,8 @@ Required::
 
 | `requests`
 | `object`
-| requests controls how many parallel requests a given registry instance will handle before queuing additional requests.
+| requests controls how many parallel requests a given registry instance
+will handle before queuing additional requests.
 
 | `resources`
 | `object`
@@ -133,19 +148,23 @@ Required::
 
 | `rolloutStrategy`
 | `string`
-| rolloutStrategy defines rollout strategy for the image registry deployment.
+| rolloutStrategy defines rollout strategy for the image registry
+deployment.
 
 | `routes`
 | `array`
-| routes defines additional external facing routes which should be created for the registry.
+| routes defines additional external facing routes which should be
+created for the registry.
 
 | `routes[]`
 | `object`
-| ImageRegistryConfigRoute holds information on external route access to image registry.
+| ImageRegistryConfigRoute holds information on external route access to image
+registry.
 
 | `storage`
 | `object`
-| storage details for configuring registry storage, e.g. S3 bucket coordinates.
+| storage details for configuring registry storage, e.g. S3 bucket
+coordinates.
 
 | `tolerations`
 | `array`
@@ -153,7 +172,8 @@ Required::
 
 | `tolerations[]`
 | `object`
-| The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.
+| The pod this Toleration is attached to tolerates any taint that matches
+the triple <key,value,effect> using the matching operator <operator>.
 
 | `topologySpreadConstraints`
 | `array`
@@ -165,7 +185,11 @@ Required::
 
 | `unsupportedConfigOverrides`
 | ``
-| unsupportedConfigOverrides overrides the final configuration that was computed by the operator. Red Hat does not support the use of this field. Misuse of this field could lead to unexpected behavior or conflict with other configuration options. Seek guidance from the Red Hat support before using this field. Use of this property blocks cluster upgrades, it must be removed before upgrading your cluster.
+| unsupportedConfigOverrides overrides the final configuration that was computed by the operator.
+Red Hat does not support the use of this field.
+Misuse of this field could lead to unexpected behavior or conflict with other configuration options.
+Seek guidance from the Red Hat support before using this field.
+Use of this property blocks cluster upgrades, it must be removed before upgrading your cluster.
 
 |===
 === .spec.affinity
@@ -217,22 +241,43 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node matches the corresponding matchExpressions; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
+| An empty preferred scheduling term matches all objects with implicit weight 0
+(i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `object`
-| If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node.
+| If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to an update), the system
+may or may not try to eventually evict the pod from its node.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node matches the corresponding matchExpressions; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -245,7 +290,8 @@ Type::
 Description::
 +
 --
-An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
+An empty preferred scheduling term matches all objects with implicit weight 0
+(i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
 --
 
 Type::
@@ -293,7 +339,8 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 | `matchFields`
 | `array`
@@ -301,7 +348,8 @@ Type::
 
 | `matchFields[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[].preference.matchExpressions
@@ -321,7 +369,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -343,11 +392,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[].preference.matchFields
@@ -367,7 +421,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -389,18 +444,27 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node.
+If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to an update), the system
+may or may not try to eventually evict the pod from its node.
 --
 
 Type::
@@ -421,7 +485,9 @@ Required::
 
 | `nodeSelectorTerms[]`
 | `object`
-| A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
+| A null or empty node selector term matches no objects. The requirements of
+them are ANDed.
+The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms
@@ -441,7 +507,9 @@ Type::
 Description::
 +
 --
-A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
+A null or empty node selector term matches no objects. The requirements of
+them are ANDed.
+The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
 --
 
 Type::
@@ -460,7 +528,8 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 | `matchFields`
 | `array`
@@ -468,7 +537,8 @@ Type::
 
 | `matchFields[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchExpressions
@@ -488,7 +558,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -510,11 +581,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchFields
@@ -534,7 +610,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -556,11 +633,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.podAffinity
@@ -582,7 +664,15 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
@@ -590,18 +680,37 @@ Type::
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+| If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 
 | `requiredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+| Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -636,7 +745,8 @@ Required::
 
 | `weight`
 | `integer`
-| weight associated with matching the corresponding podAffinityTerm, in the range 1-100.
+| weight associated with matching the corresponding podAffinityTerm,
+in the range 1-100.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm
@@ -660,34 +770,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -706,11 +845,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector.matchExpressions
@@ -730,7 +872,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -752,18 +895,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -782,11 +933,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector.matchExpressions
@@ -806,7 +960,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -828,18 +983,28 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 --
 
 Type::
@@ -852,7 +1017,12 @@ Type::
 Description::
 +
 --
-Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 --
 
 Type::
@@ -869,34 +1039,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -915,11 +1114,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector.matchExpressions
@@ -939,7 +1141,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -961,18 +1164,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -991,11 +1202,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector.matchExpressions
@@ -1015,7 +1229,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1037,11 +1252,15 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity
@@ -1063,7 +1282,15 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the anti-affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling anti-affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
@@ -1071,18 +1298,37 @@ Type::
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+| If the anti-affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the anti-affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 
 | `requiredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+| Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the anti-affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling anti-affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -1117,7 +1363,8 @@ Required::
 
 | `weight`
 | `integer`
-| weight associated with matching the corresponding podAffinityTerm, in the range 1-100.
+| weight associated with matching the corresponding podAffinityTerm,
+in the range 1-100.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm
@@ -1141,34 +1388,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -1187,11 +1463,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector.matchExpressions
@@ -1211,7 +1490,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1233,18 +1513,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -1263,11 +1551,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector.matchExpressions
@@ -1287,7 +1578,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1309,18 +1601,28 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+If the anti-affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the anti-affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 --
 
 Type::
@@ -1333,7 +1635,12 @@ Type::
 Description::
 +
 --
-Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 --
 
 Type::
@@ -1350,34 +1657,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -1396,11 +1732,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector.matchExpressions
@@ -1420,7 +1759,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1442,18 +1782,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -1472,11 +1820,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector.matchExpressions
@@ -1496,7 +1847,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1518,18 +1870,23 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.proxy
 Description::
 +
 --
-proxy defines the proxy to be used when calling master api, upstream registries, etc.
+proxy defines the proxy to be used when calling master api, upstream
+registries, etc.
 --
 
 Type::
@@ -1544,22 +1901,26 @@ Type::
 
 | `http`
 | `string`
-| http defines the proxy to be used by the image registry when accessing HTTP endpoints.
+| http defines the proxy to be used by the image registry when
+accessing HTTP endpoints.
 
 | `https`
 | `string`
-| https defines the proxy to be used by the image registry when accessing HTTPS endpoints.
+| https defines the proxy to be used by the image registry when
+accessing HTTPS endpoints.
 
 | `noProxy`
 | `string`
-| noProxy defines a comma-separated list of host names that shouldn't go through any proxy.
+| noProxy defines a comma-separated list of host names that shouldn't
+go through any proxy.
 
 |===
 === .spec.requests
 Description::
 +
 --
-requests controls how many parallel requests a given registry instance will handle before queuing additional requests.
+requests controls how many parallel requests a given registry instance
+will handle before queuing additional requests.
 --
 
 Type::
@@ -1608,7 +1969,8 @@ Type::
 
 | `maxWaitInQueue`
 | `string`
-| maxWaitInQueue sets the maximum time a request can wait in the queue before being rejected.
+| maxWaitInQueue sets the maximum time a request can wait in the queue
+before being rejected.
 
 |===
 === .spec.requests.write
@@ -1638,7 +2000,8 @@ Type::
 
 | `maxWaitInQueue`
 | `string`
-| maxWaitInQueue sets the maximum time a request can wait in the queue before being rejected.
+| maxWaitInQueue sets the maximum time a request can wait in the queue
+before being rejected.
 
 |===
 === .spec.resources
@@ -1660,9 +2023,13 @@ Type::
 
 | `claims`
 | `array`
-| Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. 
- This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. 
- This field is immutable. It can only be set for containers.
+| Claims lists the names of resources, defined in spec.resourceClaims,
+that are used by this container.
+
+This is an alpha field and requires enabling the
+DynamicResourceAllocation feature gate.
+
+This field is immutable. It can only be set for containers.
 
 | `claims[]`
 | `object`
@@ -1670,20 +2037,28 @@ Type::
 
 | `limits`
 | `integer-or-string`
-| Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
+| Limits describes the maximum amount of compute resources allowed.
+More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
 
 | `requests`
 | `integer-or-string`
-| Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
+| Requests describes the minimum amount of compute resources required.
+If Requests is omitted for a container, it defaults to Limits if that is explicitly specified,
+otherwise to an implementation-defined value. Requests cannot exceed Limits.
+More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
 
 |===
 === .spec.resources.claims
 Description::
 +
 --
-Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. 
- This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. 
- This field is immutable. It can only be set for containers.
+Claims lists the names of resources, defined in spec.resourceClaims,
+that are used by this container.
+
+This is an alpha field and requires enabling the
+DynamicResourceAllocation feature gate.
+
+This field is immutable. It can only be set for containers.
 --
 
 Type::
@@ -1713,14 +2088,23 @@ Required::
 
 | `name`
 | `string`
-| Name must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container.
+| Name must match the name of one entry in pod.spec.resourceClaims of
+the Pod where this field is used. It makes that resource available
+inside a container.
+
+| `request`
+| `string`
+| Request is the name chosen for a request in the referenced claim.
+If empty, everything from the claim is made available, otherwise
+only the result of this request.
 
 |===
 === .spec.routes
 Description::
 +
 --
-routes defines additional external facing routes which should be created for the registry.
+routes defines additional external facing routes which should be
+created for the registry.
 --
 
 Type::
@@ -1733,7 +2117,8 @@ Type::
 Description::
 +
 --
-ImageRegistryConfigRoute holds information on external route access to image registry.
+ImageRegistryConfigRoute holds information on external route access to image
+registry.
 --
 
 Type::
@@ -1758,14 +2143,16 @@ Required::
 
 | `secretName`
 | `string`
-| secretName points to secret containing the certificates to be used by the route.
+| secretName points to secret containing the certificates to be used
+by the route.
 
 |===
 === .spec.storage
 Description::
 +
 --
-storage details for configuring registry storage, e.g. S3 bucket coordinates.
+storage details for configuring registry storage, e.g. S3 bucket
+coordinates.
 --
 
 Type::
@@ -1784,7 +2171,10 @@ Type::
 
 | `emptyDir`
 | `object`
-| emptyDir represents ephemeral storage on the pod's host node. WARNING: this storage cannot be used with more than 1 replica and is not suitable for production use. When the pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
+| emptyDir represents ephemeral storage on the pod's host node.
+WARNING: this storage cannot be used with more than 1 replica and
+is not suitable for production use. When the pod is removed from a
+node for any reason, the data in the emptyDir is deleted forever.
 
 | `gcs`
 | `object`
@@ -1796,7 +2186,9 @@ Type::
 
 | `managementState`
 | `string`
-| managementState indicates if the operator manages the underlying storage unit. If Managed the operator will remove the storage when this operator gets Removed.
+| managementState indicates if the operator manages the underlying
+storage unit. If Managed the operator will remove the storage when
+this operator gets Removed.
 
 | `oss`
 | `object`
@@ -1838,7 +2230,9 @@ Type::
 
 | `cloudName`
 | `string`
-| cloudName is the name of the Azure cloud environment to be used by the registry. If empty, the operator will set it based on the infrastructure object.
+| cloudName is the name of the Azure cloud environment to be used by the
+registry. If empty, the operator will set it based on the infrastructure
+object.
 
 | `container`
 | `string`
@@ -1846,14 +2240,16 @@ Type::
 
 | `networkAccess`
 | `object`
-| networkAccess defines the network access properties for the storage account. Defaults to type: External.
+| networkAccess defines the network access properties for the storage account.
+Defaults to type: External.
 
 |===
 === .spec.storage.azure.networkAccess
 Description::
 +
 --
-networkAccess defines the network access properties for the storage account. Defaults to type: External.
+networkAccess defines the network access properties for the storage account.
+Defaults to type: External.
 --
 
 Type::
@@ -1868,18 +2264,36 @@ Type::
 
 | `internal`
 | `object`
-| internal defines the vnet and subnet names to configure a private endpoint and connect it to the storage account in order to make it private. when type: Internal and internal is unset, the image registry operator will discover vnet and subnet names, and generate a private endpoint name.
+| internal defines the vnet and subnet names to configure a private
+endpoint and connect it to the storage account in order to make it
+private.
+when type: Internal and internal is unset, the image registry operator
+will discover vnet and subnet names, and generate a private endpoint
+name.
 
 | `type`
 | `string`
-| type is the network access level to be used for the storage account. type: Internal means the storage account will be private, type: External means the storage account will be publicly accessible. Internal storage accounts are only exposed within the cluster's vnet. External storage accounts are publicly exposed on the internet. When type: Internal is used, a vnetName, subNetName and privateEndpointName may optionally be specified. If unspecificed, the image registry operator will discover vnet and subnet names, and generate a privateEndpointName. Defaults to "External".
+| type is the network access level to be used for the storage account.
+type: Internal means the storage account will be private, type: External
+means the storage account will be publicly accessible.
+Internal storage accounts are only exposed within the cluster's vnet.
+External storage accounts are publicly exposed on the internet.
+When type: Internal is used, a vnetName, subNetName and privateEndpointName
+may optionally be specified. If unspecificed, the image registry operator
+will discover vnet and subnet names, and generate a privateEndpointName.
+Defaults to "External".
 
 |===
 === .spec.storage.azure.networkAccess.internal
 Description::
 +
 --
-internal defines the vnet and subnet names to configure a private endpoint and connect it to the storage account in order to make it private. when type: Internal and internal is unset, the image registry operator will discover vnet and subnet names, and generate a private endpoint name.
+internal defines the vnet and subnet names to configure a private
+endpoint and connect it to the storage account in order to make it
+private.
+when type: Internal and internal is unset, the image registry operator
+will discover vnet and subnet names, and generate a private endpoint
+name.
 --
 
 Type::
@@ -1894,26 +2308,58 @@ Type::
 
 | `networkResourceGroupName`
 | `string`
-| networkResourceGroupName is the resource group name where the cluster's vnet and subnet are. When omitted, the registry operator will use the cluster resource group (from in the infrastructure status). If you set a networkResourceGroupName on your install-config.yaml, that value will be used automatically (for clusters configured with publish:Internal). Note that both vnet and subnet must be in the same resource group. It must be between 1 and 90 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_), and not end with a period.
+| networkResourceGroupName is the resource group name where the cluster's vnet
+and subnet are. When omitted, the registry operator will use the cluster
+resource group (from in the infrastructure status).
+If you set a networkResourceGroupName on your install-config.yaml, that
+value will be used automatically (for clusters configured with publish:Internal).
+Note that both vnet and subnet must be in the same resource group.
+It must be between 1 and 90 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_), and
+not end with a period.
 
 | `privateEndpointName`
 | `string`
-| privateEndpointName is the name of the private endpoint for the registry. When provided, the registry will use it as the name of the private endpoint it will create for the storage account. When omitted, the registry will generate one. It must be between 2 and 64 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_). It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
+| privateEndpointName is the name of the private endpoint for the registry.
+When provided, the registry will use it as the name of the private endpoint
+it will create for the storage account. When omitted, the registry will
+generate one.
+It must be between 2 and 64 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
 
 | `subnetName`
 | `string`
-| subnetName is the name of the subnet the registry operates in. When omitted, the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>` tag in the vnet resource, then using one of listed subnets. Advanced cluster network configurations that use network security groups to protect subnets should ensure the provided subnetName has access to Azure Storage service. It must be between 1 and 80 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+| subnetName is the name of the subnet the registry operates in. When omitted,
+the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>`
+tag in the vnet resource, then using one of listed subnets.
+Advanced cluster network configurations that use network security groups
+to protect subnets should ensure the provided subnetName has access to
+Azure Storage service.
+It must be between 1 and 80 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
 
 | `vnetName`
 | `string`
-| vnetName is the name of the vnet the registry operates in. When omitted, the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>` tag in the vnet resource. This tag is set automatically by the installer. Commonly, this will be the same vnet as the cluster. Advanced cluster network configurations should ensure the provided vnetName is the vnet of the nodes where the image registry pods are running from. It must be between 2 and 64 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_). It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
+| vnetName is the name of the vnet the registry operates in. When omitted,
+the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>`
+tag in the vnet resource. This tag is set automatically by the installer.
+Commonly, this will be the same vnet as the cluster.
+Advanced cluster network configurations should ensure the provided vnetName
+is the vnet of the nodes where the image registry pods are running from.
+It must be between 2 and 64 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
 
 |===
 === .spec.storage.emptyDir
 Description::
 +
 --
-emptyDir represents ephemeral storage on the pod's host node. WARNING: this storage cannot be used with more than 1 replica and is not suitable for production use. When the pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
+emptyDir represents ephemeral storage on the pod's host node.
+WARNING: this storage cannot be used with more than 1 replica and
+is not suitable for production use. When the pod is removed from a
+node for any reason, the data in the emptyDir is deleted forever.
 --
 
 Type::
@@ -1941,19 +2387,25 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `keyID`
 | `string`
-| keyID is the KMS key ID to use for encryption. Optional, buckets are encrypted by default on GCP. This allows for the use of a custom encryption key.
+| keyID is the KMS key ID to use for encryption.
+Optional, buckets are encrypted by default on GCP.
+This allows for the use of a custom encryption key.
 
 | `projectID`
 | `string`
-| projectID is the Project ID of the GCP project that this bucket should be associated with.
+| projectID is the Project ID of the GCP project that this bucket should
+be associated with.
 
 | `region`
 | `string`
-| region is the GCS location in which your bucket exists. Optional, will be set based on the installed GCS Region.
+| region is the GCS location in which your bucket exists.
+Optional, will be set based on the installed GCS Region.
 
 |===
 === .spec.storage.ibmcos
@@ -1975,23 +2427,33 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `location`
 | `string`
-| location is the IBM Cloud location in which your bucket exists. Optional, will be set based on the installed IBM Cloud location.
+| location is the IBM Cloud location in which your bucket exists.
+Optional, will be set based on the installed IBM Cloud location.
 
 | `resourceGroupName`
 | `string`
-| resourceGroupName is the name of the IBM Cloud resource group that this bucket and its service instance is associated with. Optional, will be set based on the installed IBM Cloud resource group.
+| resourceGroupName is the name of the IBM Cloud resource group that this
+bucket and its service instance is associated with.
+Optional, will be set based on the installed IBM Cloud resource group.
 
 | `resourceKeyCRN`
 | `string`
-| resourceKeyCRN is the CRN of the IBM Cloud resource key that is created for the service instance. Commonly referred as a service credential and must contain HMAC type credentials. Optional, will be computed if not provided.
+| resourceKeyCRN is the CRN of the IBM Cloud resource key that is created
+for the service instance. Commonly referred as a service credential and
+must contain HMAC type credentials.
+Optional, will be computed if not provided.
 
 | `serviceInstanceCRN`
 | `string`
-| serviceInstanceCRN is the CRN of the IBM Cloud Object Storage service instance that this bucket is associated with. Optional, will be computed if not provided.
+| serviceInstanceCRN is the CRN of the IBM Cloud Object Storage service
+instance that this bucket is associated with.
+Optional, will be computed if not provided.
 
 |===
 === .spec.storage.oss
@@ -2013,26 +2475,36 @@ Type::
 
 | `bucket`
 | `string`
-| Bucket is the bucket name in which you want to store the registry's data. About Bucket naming, more details you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/257087.htm) Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default will be autogenerated in the form of <clusterid>-image-registry-<region>-<random string 27 chars>
+| Bucket is the bucket name in which you want to store the registry's data.
+About Bucket naming, more details you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/257087.htm)
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default will be autogenerated in the form of <clusterid>-image-registry-<region>-<random string 27 chars>
 
 | `encryption`
 | `object`
-| Encryption specifies whether you would like your data encrypted on the server side. More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
+| Encryption specifies whether you would like your data encrypted on the server side.
+More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
 
 | `endpointAccessibility`
 | `string`
-| EndpointAccessibility specifies whether the registry use the OSS VPC internal endpoint Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default is `Internal`.
+| EndpointAccessibility specifies whether the registry use the OSS VPC internal endpoint
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default is `Internal`.
 
 | `region`
 | `string`
-| Region is the Alibaba Cloud Region in which your bucket exists. For a list of regions, you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/31837.html). Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default will be based on the installed Alibaba Cloud Region.
+| Region is the Alibaba Cloud Region in which your bucket exists.
+For a list of regions, you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/31837.html).
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default will be based on the installed Alibaba Cloud Region.
 
 |===
 === .spec.storage.oss.encryption
 Description::
 +
 --
-Encryption specifies whether you would like your data encrypted on the server side. More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
+Encryption specifies whether you would like your data encrypted on the server side.
+More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
 --
 
 Type::
@@ -2051,7 +2523,9 @@ Type::
 
 | `method`
 | `string`
-| Method defines the different encrytion modes available Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default is `AES256`.
+| Method defines the different encrytion modes available
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default is `AES256`.
 
 |===
 === .spec.storage.oss.encryption.kms
@@ -2119,47 +2593,69 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `chunkSizeMiB`
 | `integer`
-| chunkSizeMiB defines the size of the multipart upload chunks of the S3 API. The S3 API requires multipart upload chunks to be at least 5MiB. When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default value is 10 MiB. The value is an integer number of MiB. The minimum value is 5 and the maximum value is 5120 (5 GiB).
+| chunkSizeMiB defines the size of the multipart upload chunks of the S3 API.
+The S3 API requires multipart upload chunks to be at least 5MiB.
+When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time.
+The current default value is 10 MiB.
+The value is an integer number of MiB.
+The minimum value is 5 and the maximum value is 5120 (5 GiB).
 
 | `cloudFront`
 | `object`
-| cloudFront configures Amazon Cloudfront as the storage middleware in a registry.
+| cloudFront configures Amazon Cloudfront as the storage middleware in a
+registry.
 
 | `encrypt`
 | `boolean`
-| encrypt specifies whether the registry stores the image in encrypted format or not. Optional, defaults to false.
+| encrypt specifies whether the registry stores the image in encrypted
+format or not.
+Optional, defaults to false.
 
 | `keyID`
 | `string`
-| keyID is the KMS key ID to use for encryption. Optional, Encrypt must be true, or this parameter is ignored.
+| keyID is the KMS key ID to use for encryption.
+Optional, Encrypt must be true, or this parameter is ignored.
 
 | `region`
 | `string`
-| region is the AWS region in which your bucket exists. Optional, will be set based on the installed AWS Region.
+| region is the AWS region in which your bucket exists.
+Optional, will be set based on the installed AWS Region.
 
 | `regionEndpoint`
 | `string`
-| regionEndpoint is the endpoint for S3 compatible storage services. It should be a valid URL with scheme, e.g. https://s3.example.com. Optional, defaults based on the Region that is provided.
+| regionEndpoint is the endpoint for S3 compatible storage services.
+It should be a valid URL with scheme, e.g. https://s3.example.com.
+Optional, defaults based on the Region that is provided.
 
 | `trustedCA`
 | `object`
-| trustedCA is a reference to a config map containing a CA bundle. The image registry and its operator use certificates from this bundle to verify S3 server certificates. 
- The namespace for the config map referenced by trustedCA is "openshift-config". The key for the bundle in the config map is "ca-bundle.crt".
+| trustedCA is a reference to a config map containing a CA bundle. The
+image registry and its operator use certificates from this bundle to
+verify S3 server certificates.
+
+The namespace for the config map referenced by trustedCA is
+"openshift-config". The key for the bundle in the config map is
+"ca-bundle.crt".
 
 | `virtualHostedStyle`
 | `boolean`
-| virtualHostedStyle enables using S3 virtual hosted style bucket paths with a custom RegionEndpoint Optional, defaults to false.
+| virtualHostedStyle enables using S3 virtual hosted style bucket paths with
+a custom RegionEndpoint
+Optional, defaults to false.
 
 |===
 === .spec.storage.s3.cloudFront
 Description::
 +
 --
-cloudFront configures Amazon Cloudfront as the storage middleware in a registry.
+cloudFront configures Amazon Cloudfront as the storage middleware in a
+registry.
 --
 
 Type::
@@ -2218,7 +2714,11 @@ Required::
 
 | `name`
 | `string`
-| Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. TODO: Add other useful fields. apiVersion, kind, uid? More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names TODO: Drop `kubebuilder:default` when controller-gen doesn't need it https://github.com/kubernetes-sigs/kubebuilder/issues/3896.
+| Name of the referent.
+This field is effectively required, but due to backwards compatibility is
+allowed to be empty. Instances of this type with an empty value here are
+almost certainly wrong.
+More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
 
 | `optional`
 | `boolean`
@@ -2229,8 +2729,13 @@ Required::
 Description::
 +
 --
-trustedCA is a reference to a config map containing a CA bundle. The image registry and its operator use certificates from this bundle to verify S3 server certificates. 
- The namespace for the config map referenced by trustedCA is "openshift-config". The key for the bundle in the config map is "ca-bundle.crt".
+trustedCA is a reference to a config map containing a CA bundle. The
+image registry and its operator use certificates from this bundle to
+verify S3 server certificates.
+
+The namespace for the config map referenced by trustedCA is
+"openshift-config". The key for the bundle in the config map is
+"ca-bundle.crt".
 --
 
 Type::
@@ -2245,7 +2750,12 @@ Type::
 
 | `name`
 | `string`
-| name is the metadata.name of the referenced config map. This field must adhere to standard config map naming restrictions. The name must consist solely of alphanumeric characters, hyphens (-) and periods (.). It has a maximum length of 253 characters. If this field is not specified or is empty string, the default trust bundle will be used.
+| name is the metadata.name of the referenced config map.
+This field must adhere to standard config map naming restrictions.
+The name must consist solely of alphanumeric characters, hyphens (-)
+and periods (.). It has a maximum length of 253 characters.
+If this field is not specified or is empty string, the default trust
+bundle will be used.
 
 |===
 === .spec.storage.swift
@@ -2275,7 +2785,8 @@ Type::
 
 | `container`
 | `string`
-| container defines the name of Swift container where to store the registry's data.
+| container defines the name of Swift container where to store the
+registry's data.
 
 | `domain`
 | `string`
@@ -2315,7 +2826,8 @@ Type::
 Description::
 +
 --
-The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.
+The pod this Toleration is attached to tolerates any taint that matches
+the triple <key,value,effect> using the matching operator <operator>.
 --
 
 Type::
@@ -2330,23 +2842,32 @@ Type::
 
 | `effect`
 | `string`
-| Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
+| Effect indicates the taint effect to match. Empty means match all taint effects.
+When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
 
 | `key`
 | `string`
-| Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys.
+| Key is the taint key that the toleration applies to. Empty means match all taint keys.
+If the key is empty, operator must be Exists; this combination means to match all values and all keys.
 
 | `operator`
 | `string`
-| Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
+| Operator represents a key's relationship to the value.
+Valid operators are Exists and Equal. Defaults to Equal.
+Exists is equivalent to wildcard for value, so that a pod can
+tolerate all taints of a particular category.
 
 | `tolerationSeconds`
 | `integer`
-| TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.
+| TolerationSeconds represents the period of time the toleration (which must be
+of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default,
+it is not set, which means tolerate the taint forever (do not evict). Zero and
+negative values will be treated as 0 (evict immediately) by the system.
 
 | `value`
 | `string`
-| Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.
+| Value is the taint value the toleration matches to.
+If the operator is Exists, the value should be empty, otherwise just a regular string.
 
 |===
 === .spec.topologySpreadConstraints
@@ -2385,46 +2906,128 @@ Required::
 
 | `labelSelector`
 | `object`
-| LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.
+| LabelSelector is used to find matching pods.
+Pods that match this label selector are counted to determine the number of pods
+in their corresponding topology domain.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select the pods over which spreading will be calculated. The keys are used to lookup values from the incoming pod labels, those key-value labels are ANDed with labelSelector to select the group of existing pods over which spreading will be calculated for the incoming pod. The same key is forbidden to exist in both MatchLabelKeys and LabelSelector. MatchLabelKeys cannot be set when LabelSelector isn't set. Keys that don't exist in the incoming pod labels will be ignored. A null or empty list means only match against labelSelector. 
- This is a beta field and requires the MatchLabelKeysInPodTopologySpread feature gate to be enabled (enabled by default).
+| MatchLabelKeys is a set of pod label keys to select the pods over which
+spreading will be calculated. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are ANDed with labelSelector
+to select the group of existing pods over which spreading will be calculated
+for the incoming pod. The same key is forbidden to exist in both MatchLabelKeys and LabelSelector.
+MatchLabelKeys cannot be set when LabelSelector isn't set.
+Keys that don't exist in the incoming pod labels will
+be ignored. A null or empty list means only match against labelSelector.
+
+This is a beta field and requires the MatchLabelKeysInPodTopologySpread feature gate to be enabled (enabled by default).
 
 | `maxSkew`
 | `integer`
-| MaxSkew describes the degree to which pods may be unevenly distributed. When `whenUnsatisfiable=DoNotSchedule`, it is the maximum permitted difference between the number of matching pods in the target topology and the global minimum. The global minimum is the minimum number of matching pods in an eligible domain or zero if the number of eligible domains is less than MinDomains. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 2/2/1: In this case, the global minimum is 1. \| zone1 \| zone2 \| zone3 \| \|  P P  \|  P P  \|   P   \| - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 2/2/2; scheduling it onto zone1(zone2) would make the ActualSkew(3-1) on zone1(zone2) violate MaxSkew(1). - if MaxSkew is 2, incoming pod can be scheduled onto any zone. When `whenUnsatisfiable=ScheduleAnyway`, it is used to give higher precedence to topologies that satisfy it. It's a required field. Default value is 1 and 0 is not allowed.
+| MaxSkew describes the degree to which pods may be unevenly distributed.
+When `whenUnsatisfiable=DoNotSchedule`, it is the maximum permitted difference
+between the number of matching pods in the target topology and the global minimum.
+The global minimum is the minimum number of matching pods in an eligible domain
+or zero if the number of eligible domains is less than MinDomains.
+For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same
+labelSelector spread as 2/2/1:
+In this case, the global minimum is 1.
+\| zone1 \| zone2 \| zone3 \|
+\|  P P  \|  P P  \|   P   \|
+- if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 2/2/2;
+scheduling it onto zone1(zone2) would make the ActualSkew(3-1) on zone1(zone2)
+violate MaxSkew(1).
+- if MaxSkew is 2, incoming pod can be scheduled onto any zone.
+When `whenUnsatisfiable=ScheduleAnyway`, it is used to give higher precedence
+to topologies that satisfy it.
+It's a required field. Default value is 1 and 0 is not allowed.
 
 | `minDomains`
 | `integer`
-| MinDomains indicates a minimum number of eligible domains. When the number of eligible domains with matching topology keys is less than minDomains, Pod Topology Spread treats "global minimum" as 0, and then the calculation of Skew is performed. And when the number of eligible domains with matching topology keys equals or greater than minDomains, this value has no effect on scheduling. As a result, when the number of eligible domains is less than minDomains, scheduler won't schedule more than maxSkew Pods to those domains. If value is nil, the constraint behaves as if MinDomains is equal to 1. Valid values are integers greater than 0. When value is not nil, WhenUnsatisfiable must be DoNotSchedule. 
- For example, in a 3-zone cluster, MaxSkew is set to 2, MinDomains is set to 5 and pods with the same labelSelector spread as 2/2/2: \| zone1 \| zone2 \| zone3 \| \|  P P  \|  P P  \|  P P  \| The number of domains is less than 5(MinDomains), so "global minimum" is treated as 0. In this situation, new pod with the same labelSelector cannot be scheduled, because computed skew will be 3(3 - 0) if new Pod is scheduled to any of the three zones, it will violate MaxSkew.
+| MinDomains indicates a minimum number of eligible domains.
+When the number of eligible domains with matching topology keys is less than minDomains,
+Pod Topology Spread treats "global minimum" as 0, and then the calculation of Skew is performed.
+And when the number of eligible domains with matching topology keys equals or greater than minDomains,
+this value has no effect on scheduling.
+As a result, when the number of eligible domains is less than minDomains,
+scheduler won't schedule more than maxSkew Pods to those domains.
+If value is nil, the constraint behaves as if MinDomains is equal to 1.
+Valid values are integers greater than 0.
+When value is not nil, WhenUnsatisfiable must be DoNotSchedule.
+
+For example, in a 3-zone cluster, MaxSkew is set to 2, MinDomains is set to 5 and pods with the same
+labelSelector spread as 2/2/2:
+\| zone1 \| zone2 \| zone3 \|
+\|  P P  \|  P P  \|  P P  \|
+The number of domains is less than 5(MinDomains), so "global minimum" is treated as 0.
+In this situation, new pod with the same labelSelector cannot be scheduled,
+because computed skew will be 3(3 - 0) if new Pod is scheduled to any of the three zones,
+it will violate MaxSkew.
 
 | `nodeAffinityPolicy`
 | `string`
-| NodeAffinityPolicy indicates how we will treat Pod's nodeAffinity/nodeSelector when calculating pod topology spread skew. Options are: - Honor: only nodes matching nodeAffinity/nodeSelector are included in the calculations. - Ignore: nodeAffinity/nodeSelector are ignored. All nodes are included in the calculations. 
- If this value is nil, the behavior is equivalent to the Honor policy. This is a beta-level feature default enabled by the NodeInclusionPolicyInPodTopologySpread feature flag.
+| NodeAffinityPolicy indicates how we will treat Pod's nodeAffinity/nodeSelector
+when calculating pod topology spread skew. Options are:
+- Honor: only nodes matching nodeAffinity/nodeSelector are included in the calculations.
+- Ignore: nodeAffinity/nodeSelector are ignored. All nodes are included in the calculations.
+
+If this value is nil, the behavior is equivalent to the Honor policy.
+This is a beta-level feature default enabled by the NodeInclusionPolicyInPodTopologySpread feature flag.
 
 | `nodeTaintsPolicy`
 | `string`
-| NodeTaintsPolicy indicates how we will treat node taints when calculating pod topology spread skew. Options are: - Honor: nodes without taints, along with tainted nodes for which the incoming pod has a toleration, are included. - Ignore: node taints are ignored. All nodes are included. 
- If this value is nil, the behavior is equivalent to the Ignore policy. This is a beta-level feature default enabled by the NodeInclusionPolicyInPodTopologySpread feature flag.
+| NodeTaintsPolicy indicates how we will treat node taints when calculating
+pod topology spread skew. Options are:
+- Honor: nodes without taints, along with tainted nodes for which the incoming pod
+has a toleration, are included.
+- Ignore: node taints are ignored. All nodes are included.
+
+If this value is nil, the behavior is equivalent to the Ignore policy.
+This is a beta-level feature default enabled by the NodeInclusionPolicyInPodTopologySpread feature flag.
 
 | `topologyKey`
 | `string`
-| TopologyKey is the key of node labels. Nodes that have a label with this key and identical values are considered to be in the same topology. We consider each <key, value> as a "bucket", and try to put balanced number of pods into each bucket. We define a domain as a particular instance of a topology. Also, we define an eligible domain as a domain whose nodes meet the requirements of nodeAffinityPolicy and nodeTaintsPolicy. e.g. If TopologyKey is "kubernetes.io/hostname", each Node is a domain of that topology. And, if TopologyKey is "topology.kubernetes.io/zone", each zone is a domain of that topology. It's a required field.
+| TopologyKey is the key of node labels. Nodes that have a label with this key
+and identical values are considered to be in the same topology.
+We consider each <key, value> as a "bucket", and try to put balanced number
+of pods into each bucket.
+We define a domain as a particular instance of a topology.
+Also, we define an eligible domain as a domain whose nodes meet the requirements of
+nodeAffinityPolicy and nodeTaintsPolicy.
+e.g. If TopologyKey is "kubernetes.io/hostname", each Node is a domain of that topology.
+And, if TopologyKey is "topology.kubernetes.io/zone", each zone is a domain of that topology.
+It's a required field.
 
 | `whenUnsatisfiable`
 | `string`
-| WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location, but giving higher precedence to topologies that would help reduce the skew. A constraint is considered "Unsatisfiable" for an incoming pod if and only if every possible node assignment for that pod would violate "MaxSkew" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: \| zone1 \| zone2 \| zone3 \| \| P P P \|   P   \|   P   \| If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it *more* imbalanced. It's a required field.
+| WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy
+the spread constraint.
+- DoNotSchedule (default) tells the scheduler not to schedule it.
+- ScheduleAnyway tells the scheduler to schedule the pod in any location,
+  but giving higher precedence to topologies that would help reduce the
+  skew.
+A constraint is considered "Unsatisfiable" for an incoming pod
+if and only if every possible node assignment for that pod would violate
+"MaxSkew" on some topology.
+For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same
+labelSelector spread as 3/1/1:
+\| zone1 \| zone2 \| zone3 \|
+\| P P P \|   P   \|   P   \|
+If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled
+to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies
+MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler
+won't make it *more* imbalanced.
+It's a required field.
 
 |===
 === .spec.topologySpreadConstraints[].labelSelector
 Description::
 +
 --
-LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.
+LabelSelector is used to find matching pods.
+Pods that match this label selector are counted to determine the number of pods
+in their corresponding topology domain.
 --
 
 Type::
@@ -2443,11 +3046,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.topologySpreadConstraints[].labelSelector.matchExpressions
@@ -2467,7 +3073,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -2489,11 +3096,15 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .status
@@ -2532,6 +3143,10 @@ Required::
 | `object`
 | GenerationStatus keeps track of the generation for a given resource so that decisions about forced updates can be made.
 
+| `latestAvailableRevision`
+| `integer`
+| latestAvailableRevision is the deploymentID of the most recent deployment
+
 | `observedGeneration`
 | `integer`
 | observedGeneration is the last generation change you've dealt with
@@ -2542,7 +3157,8 @@ Required::
 
 | `storage`
 | `object`
-| storage indicates the current applied storage configuration of the registry.
+| storage indicates the current applied storage configuration of the
+registry.
 
 | `storageManaged`
 | `boolean`
@@ -2577,6 +3193,8 @@ Type::
   `object`
 
 Required::
+  - `lastTransitionTime`
+  - `status`
   - `type`
 
 
@@ -2587,7 +3205,8 @@ Required::
 
 | `lastTransitionTime`
 | `string`
-| 
+| lastTransitionTime is the last time the condition transitioned from one status to another.
+This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.
 
 | `message`
 | `string`
@@ -2599,11 +3218,11 @@ Required::
 
 | `status`
 | `string`
-| 
+| status of the condition, one of True, False, Unknown.
 
 | `type`
 | `string`
-| 
+| type of condition in CamelCase or in foo.example.com/CamelCase.
 
 |===
 === .status.generations
@@ -2629,6 +3248,11 @@ GenerationStatus keeps track of the generation for a given resource so that deci
 Type::
   `object`
 
+Required::
+  - `group`
+  - `name`
+  - `namespace`
+  - `resource`
 
 
 
@@ -2665,7 +3289,8 @@ Type::
 Description::
 +
 --
-storage indicates the current applied storage configuration of the registry.
+storage indicates the current applied storage configuration of the
+registry.
 --
 
 Type::
@@ -2684,7 +3309,10 @@ Type::
 
 | `emptyDir`
 | `object`
-| emptyDir represents ephemeral storage on the pod's host node. WARNING: this storage cannot be used with more than 1 replica and is not suitable for production use. When the pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
+| emptyDir represents ephemeral storage on the pod's host node.
+WARNING: this storage cannot be used with more than 1 replica and
+is not suitable for production use. When the pod is removed from a
+node for any reason, the data in the emptyDir is deleted forever.
 
 | `gcs`
 | `object`
@@ -2696,7 +3324,9 @@ Type::
 
 | `managementState`
 | `string`
-| managementState indicates if the operator manages the underlying storage unit. If Managed the operator will remove the storage when this operator gets Removed.
+| managementState indicates if the operator manages the underlying
+storage unit. If Managed the operator will remove the storage when
+this operator gets Removed.
 
 | `oss`
 | `object`
@@ -2738,7 +3368,9 @@ Type::
 
 | `cloudName`
 | `string`
-| cloudName is the name of the Azure cloud environment to be used by the registry. If empty, the operator will set it based on the infrastructure object.
+| cloudName is the name of the Azure cloud environment to be used by the
+registry. If empty, the operator will set it based on the infrastructure
+object.
 
 | `container`
 | `string`
@@ -2746,14 +3378,16 @@ Type::
 
 | `networkAccess`
 | `object`
-| networkAccess defines the network access properties for the storage account. Defaults to type: External.
+| networkAccess defines the network access properties for the storage account.
+Defaults to type: External.
 
 |===
 === .status.storage.azure.networkAccess
 Description::
 +
 --
-networkAccess defines the network access properties for the storage account. Defaults to type: External.
+networkAccess defines the network access properties for the storage account.
+Defaults to type: External.
 --
 
 Type::
@@ -2768,18 +3402,36 @@ Type::
 
 | `internal`
 | `object`
-| internal defines the vnet and subnet names to configure a private endpoint and connect it to the storage account in order to make it private. when type: Internal and internal is unset, the image registry operator will discover vnet and subnet names, and generate a private endpoint name.
+| internal defines the vnet and subnet names to configure a private
+endpoint and connect it to the storage account in order to make it
+private.
+when type: Internal and internal is unset, the image registry operator
+will discover vnet and subnet names, and generate a private endpoint
+name.
 
 | `type`
 | `string`
-| type is the network access level to be used for the storage account. type: Internal means the storage account will be private, type: External means the storage account will be publicly accessible. Internal storage accounts are only exposed within the cluster's vnet. External storage accounts are publicly exposed on the internet. When type: Internal is used, a vnetName, subNetName and privateEndpointName may optionally be specified. If unspecificed, the image registry operator will discover vnet and subnet names, and generate a privateEndpointName. Defaults to "External".
+| type is the network access level to be used for the storage account.
+type: Internal means the storage account will be private, type: External
+means the storage account will be publicly accessible.
+Internal storage accounts are only exposed within the cluster's vnet.
+External storage accounts are publicly exposed on the internet.
+When type: Internal is used, a vnetName, subNetName and privateEndpointName
+may optionally be specified. If unspecificed, the image registry operator
+will discover vnet and subnet names, and generate a privateEndpointName.
+Defaults to "External".
 
 |===
 === .status.storage.azure.networkAccess.internal
 Description::
 +
 --
-internal defines the vnet and subnet names to configure a private endpoint and connect it to the storage account in order to make it private. when type: Internal and internal is unset, the image registry operator will discover vnet and subnet names, and generate a private endpoint name.
+internal defines the vnet and subnet names to configure a private
+endpoint and connect it to the storage account in order to make it
+private.
+when type: Internal and internal is unset, the image registry operator
+will discover vnet and subnet names, and generate a private endpoint
+name.
 --
 
 Type::
@@ -2794,26 +3446,58 @@ Type::
 
 | `networkResourceGroupName`
 | `string`
-| networkResourceGroupName is the resource group name where the cluster's vnet and subnet are. When omitted, the registry operator will use the cluster resource group (from in the infrastructure status). If you set a networkResourceGroupName on your install-config.yaml, that value will be used automatically (for clusters configured with publish:Internal). Note that both vnet and subnet must be in the same resource group. It must be between 1 and 90 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_), and not end with a period.
+| networkResourceGroupName is the resource group name where the cluster's vnet
+and subnet are. When omitted, the registry operator will use the cluster
+resource group (from in the infrastructure status).
+If you set a networkResourceGroupName on your install-config.yaml, that
+value will be used automatically (for clusters configured with publish:Internal).
+Note that both vnet and subnet must be in the same resource group.
+It must be between 1 and 90 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_), and
+not end with a period.
 
 | `privateEndpointName`
 | `string`
-| privateEndpointName is the name of the private endpoint for the registry. When provided, the registry will use it as the name of the private endpoint it will create for the storage account. When omitted, the registry will generate one. It must be between 2 and 64 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_). It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
+| privateEndpointName is the name of the private endpoint for the registry.
+When provided, the registry will use it as the name of the private endpoint
+it will create for the storage account. When omitted, the registry will
+generate one.
+It must be between 2 and 64 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
 
 | `subnetName`
 | `string`
-| subnetName is the name of the subnet the registry operates in. When omitted, the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>` tag in the vnet resource, then using one of listed subnets. Advanced cluster network configurations that use network security groups to protect subnets should ensure the provided subnetName has access to Azure Storage service. It must be between 1 and 80 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+| subnetName is the name of the subnet the registry operates in. When omitted,
+the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>`
+tag in the vnet resource, then using one of listed subnets.
+Advanced cluster network configurations that use network security groups
+to protect subnets should ensure the provided subnetName has access to
+Azure Storage service.
+It must be between 1 and 80 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
 
 | `vnetName`
 | `string`
-| vnetName is the name of the vnet the registry operates in. When omitted, the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>` tag in the vnet resource. This tag is set automatically by the installer. Commonly, this will be the same vnet as the cluster. Advanced cluster network configurations should ensure the provided vnetName is the vnet of the nodes where the image registry pods are running from. It must be between 2 and 64 characters in length and must consist only of alphanumeric characters, hyphens (-), periods (.) and underscores (_). It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
+| vnetName is the name of the vnet the registry operates in. When omitted,
+the registry operator will discover and set this by using the `kubernetes.io_cluster.<cluster-id>`
+tag in the vnet resource. This tag is set automatically by the installer.
+Commonly, this will be the same vnet as the cluster.
+Advanced cluster network configurations should ensure the provided vnetName
+is the vnet of the nodes where the image registry pods are running from.
+It must be between 2 and 64 characters in length and must consist only of
+alphanumeric characters, hyphens (-), periods (.) and underscores (_).
+It must start with an alphanumeric character and end with an alphanumeric character or an underscore.
 
 |===
 === .status.storage.emptyDir
 Description::
 +
 --
-emptyDir represents ephemeral storage on the pod's host node. WARNING: this storage cannot be used with more than 1 replica and is not suitable for production use. When the pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
+emptyDir represents ephemeral storage on the pod's host node.
+WARNING: this storage cannot be used with more than 1 replica and
+is not suitable for production use. When the pod is removed from a
+node for any reason, the data in the emptyDir is deleted forever.
 --
 
 Type::
@@ -2841,19 +3525,25 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `keyID`
 | `string`
-| keyID is the KMS key ID to use for encryption. Optional, buckets are encrypted by default on GCP. This allows for the use of a custom encryption key.
+| keyID is the KMS key ID to use for encryption.
+Optional, buckets are encrypted by default on GCP.
+This allows for the use of a custom encryption key.
 
 | `projectID`
 | `string`
-| projectID is the Project ID of the GCP project that this bucket should be associated with.
+| projectID is the Project ID of the GCP project that this bucket should
+be associated with.
 
 | `region`
 | `string`
-| region is the GCS location in which your bucket exists. Optional, will be set based on the installed GCS Region.
+| region is the GCS location in which your bucket exists.
+Optional, will be set based on the installed GCS Region.
 
 |===
 === .status.storage.ibmcos
@@ -2875,23 +3565,33 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `location`
 | `string`
-| location is the IBM Cloud location in which your bucket exists. Optional, will be set based on the installed IBM Cloud location.
+| location is the IBM Cloud location in which your bucket exists.
+Optional, will be set based on the installed IBM Cloud location.
 
 | `resourceGroupName`
 | `string`
-| resourceGroupName is the name of the IBM Cloud resource group that this bucket and its service instance is associated with. Optional, will be set based on the installed IBM Cloud resource group.
+| resourceGroupName is the name of the IBM Cloud resource group that this
+bucket and its service instance is associated with.
+Optional, will be set based on the installed IBM Cloud resource group.
 
 | `resourceKeyCRN`
 | `string`
-| resourceKeyCRN is the CRN of the IBM Cloud resource key that is created for the service instance. Commonly referred as a service credential and must contain HMAC type credentials. Optional, will be computed if not provided.
+| resourceKeyCRN is the CRN of the IBM Cloud resource key that is created
+for the service instance. Commonly referred as a service credential and
+must contain HMAC type credentials.
+Optional, will be computed if not provided.
 
 | `serviceInstanceCRN`
 | `string`
-| serviceInstanceCRN is the CRN of the IBM Cloud Object Storage service instance that this bucket is associated with. Optional, will be computed if not provided.
+| serviceInstanceCRN is the CRN of the IBM Cloud Object Storage service
+instance that this bucket is associated with.
+Optional, will be computed if not provided.
 
 |===
 === .status.storage.oss
@@ -2913,26 +3613,36 @@ Type::
 
 | `bucket`
 | `string`
-| Bucket is the bucket name in which you want to store the registry's data. About Bucket naming, more details you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/257087.htm) Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default will be autogenerated in the form of <clusterid>-image-registry-<region>-<random string 27 chars>
+| Bucket is the bucket name in which you want to store the registry's data.
+About Bucket naming, more details you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/257087.htm)
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default will be autogenerated in the form of <clusterid>-image-registry-<region>-<random string 27 chars>
 
 | `encryption`
 | `object`
-| Encryption specifies whether you would like your data encrypted on the server side. More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
+| Encryption specifies whether you would like your data encrypted on the server side.
+More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
 
 | `endpointAccessibility`
 | `string`
-| EndpointAccessibility specifies whether the registry use the OSS VPC internal endpoint Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default is `Internal`.
+| EndpointAccessibility specifies whether the registry use the OSS VPC internal endpoint
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default is `Internal`.
 
 | `region`
 | `string`
-| Region is the Alibaba Cloud Region in which your bucket exists. For a list of regions, you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/31837.html). Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default will be based on the installed Alibaba Cloud Region.
+| Region is the Alibaba Cloud Region in which your bucket exists.
+For a list of regions, you can look at the [official documentation](https://www.alibabacloud.com/help/doc-detail/31837.html).
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default will be based on the installed Alibaba Cloud Region.
 
 |===
 === .status.storage.oss.encryption
 Description::
 +
 --
-Encryption specifies whether you would like your data encrypted on the server side. More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
+Encryption specifies whether you would like your data encrypted on the server side.
+More details, you can look cat the [official documentation](https://www.alibabacloud.com/help/doc-detail/117914.htm)
 --
 
 Type::
@@ -2951,7 +3661,9 @@ Type::
 
 | `method`
 | `string`
-| Method defines the different encrytion modes available Empty value means no opinion and the platform chooses the a default, which is subject to change over time. Currently the default is `AES256`.
+| Method defines the different encrytion modes available
+Empty value means no opinion and the platform chooses the a default, which is subject to change over time.
+Currently the default is `AES256`.
 
 |===
 === .status.storage.oss.encryption.kms
@@ -3019,47 +3731,69 @@ Type::
 
 | `bucket`
 | `string`
-| bucket is the bucket name in which you want to store the registry's data. Optional, will be generated if not provided.
+| bucket is the bucket name in which you want to store the registry's
+data.
+Optional, will be generated if not provided.
 
 | `chunkSizeMiB`
 | `integer`
-| chunkSizeMiB defines the size of the multipart upload chunks of the S3 API. The S3 API requires multipart upload chunks to be at least 5MiB. When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default value is 10 MiB. The value is an integer number of MiB. The minimum value is 5 and the maximum value is 5120 (5 GiB).
+| chunkSizeMiB defines the size of the multipart upload chunks of the S3 API.
+The S3 API requires multipart upload chunks to be at least 5MiB.
+When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time.
+The current default value is 10 MiB.
+The value is an integer number of MiB.
+The minimum value is 5 and the maximum value is 5120 (5 GiB).
 
 | `cloudFront`
 | `object`
-| cloudFront configures Amazon Cloudfront as the storage middleware in a registry.
+| cloudFront configures Amazon Cloudfront as the storage middleware in a
+registry.
 
 | `encrypt`
 | `boolean`
-| encrypt specifies whether the registry stores the image in encrypted format or not. Optional, defaults to false.
+| encrypt specifies whether the registry stores the image in encrypted
+format or not.
+Optional, defaults to false.
 
 | `keyID`
 | `string`
-| keyID is the KMS key ID to use for encryption. Optional, Encrypt must be true, or this parameter is ignored.
+| keyID is the KMS key ID to use for encryption.
+Optional, Encrypt must be true, or this parameter is ignored.
 
 | `region`
 | `string`
-| region is the AWS region in which your bucket exists. Optional, will be set based on the installed AWS Region.
+| region is the AWS region in which your bucket exists.
+Optional, will be set based on the installed AWS Region.
 
 | `regionEndpoint`
 | `string`
-| regionEndpoint is the endpoint for S3 compatible storage services. It should be a valid URL with scheme, e.g. https://s3.example.com. Optional, defaults based on the Region that is provided.
+| regionEndpoint is the endpoint for S3 compatible storage services.
+It should be a valid URL with scheme, e.g. https://s3.example.com.
+Optional, defaults based on the Region that is provided.
 
 | `trustedCA`
 | `object`
-| trustedCA is a reference to a config map containing a CA bundle. The image registry and its operator use certificates from this bundle to verify S3 server certificates. 
- The namespace for the config map referenced by trustedCA is "openshift-config". The key for the bundle in the config map is "ca-bundle.crt".
+| trustedCA is a reference to a config map containing a CA bundle. The
+image registry and its operator use certificates from this bundle to
+verify S3 server certificates.
+
+The namespace for the config map referenced by trustedCA is
+"openshift-config". The key for the bundle in the config map is
+"ca-bundle.crt".
 
 | `virtualHostedStyle`
 | `boolean`
-| virtualHostedStyle enables using S3 virtual hosted style bucket paths with a custom RegionEndpoint Optional, defaults to false.
+| virtualHostedStyle enables using S3 virtual hosted style bucket paths with
+a custom RegionEndpoint
+Optional, defaults to false.
 
 |===
 === .status.storage.s3.cloudFront
 Description::
 +
 --
-cloudFront configures Amazon Cloudfront as the storage middleware in a registry.
+cloudFront configures Amazon Cloudfront as the storage middleware in a
+registry.
 --
 
 Type::
@@ -3118,7 +3852,11 @@ Required::
 
 | `name`
 | `string`
-| Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. TODO: Add other useful fields. apiVersion, kind, uid? More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names TODO: Drop `kubebuilder:default` when controller-gen doesn't need it https://github.com/kubernetes-sigs/kubebuilder/issues/3896.
+| Name of the referent.
+This field is effectively required, but due to backwards compatibility is
+allowed to be empty. Instances of this type with an empty value here are
+almost certainly wrong.
+More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
 
 | `optional`
 | `boolean`
@@ -3129,8 +3867,13 @@ Required::
 Description::
 +
 --
-trustedCA is a reference to a config map containing a CA bundle. The image registry and its operator use certificates from this bundle to verify S3 server certificates. 
- The namespace for the config map referenced by trustedCA is "openshift-config". The key for the bundle in the config map is "ca-bundle.crt".
+trustedCA is a reference to a config map containing a CA bundle. The
+image registry and its operator use certificates from this bundle to
+verify S3 server certificates.
+
+The namespace for the config map referenced by trustedCA is
+"openshift-config". The key for the bundle in the config map is
+"ca-bundle.crt".
 --
 
 Type::
@@ -3145,7 +3888,12 @@ Type::
 
 | `name`
 | `string`
-| name is the metadata.name of the referenced config map. This field must adhere to standard config map naming restrictions. The name must consist solely of alphanumeric characters, hyphens (-) and periods (.). It has a maximum length of 253 characters. If this field is not specified or is empty string, the default trust bundle will be used.
+| name is the metadata.name of the referenced config map.
+This field must adhere to standard config map naming restrictions.
+The name must consist solely of alphanumeric characters, hyphens (-)
+and periods (.). It has a maximum length of 253 characters.
+If this field is not specified or is empty string, the default trust
+bundle will be used.
 
 |===
 === .status.storage.swift
@@ -3175,7 +3923,8 @@ Type::
 
 | `container`
 | `string`
-| container defines the name of Swift container where to store the registry's data.
+| container defines the name of Swift container where to store the
+registry's data.
 
 | `domain`
 | `string`
diff --git a/rest_api/operator_apis/imagepruner-imageregistry-operator-openshift-io-v1.adoc b/rest_api/operator_apis/imagepruner-imageregistry-operator-openshift-io-v1.adoc
index 76678011fd35..cb3bdf209f27 100644
--- a/rest_api/operator_apis/imagepruner-imageregistry-operator-openshift-io-v1.adoc
+++ b/rest_api/operator_apis/imagepruner-imageregistry-operator-openshift-io-v1.adoc
@@ -11,8 +11,10 @@ toc::[]
 Description::
 +
 --
-ImagePruner is the configuration object for an image registry pruner managed by the registry operator. 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+ImagePruner is the configuration object for an image registry pruner
+managed by the registry operator.
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
@@ -73,28 +75,35 @@ Type::
 
 | `failedJobsHistoryLimit`
 | `integer`
-| failedJobsHistoryLimit specifies how many failed image pruner jobs to retain. Defaults to 3 if not set.
+| failedJobsHistoryLimit specifies how many failed image pruner jobs to retain.
+Defaults to 3 if not set.
 
 | `ignoreInvalidImageReferences`
 | `boolean`
-| ignoreInvalidImageReferences indicates whether the pruner can ignore errors while parsing image references.
+| ignoreInvalidImageReferences indicates whether the pruner can ignore
+errors while parsing image references.
 
 | `keepTagRevisions`
 | `integer`
-| keepTagRevisions specifies the number of image revisions for a tag in an image stream that will be preserved. Defaults to 3.
+| keepTagRevisions specifies the number of image revisions for a tag in an image stream that will be preserved.
+Defaults to 3.
 
 | `keepYoungerThan`
 | `integer`
-| keepYoungerThan specifies the minimum age in nanoseconds of an image and its referrers for it to be considered a candidate for pruning. DEPRECATED: This field is deprecated in favor of keepYoungerThanDuration. If both are set, this field is ignored and keepYoungerThanDuration takes precedence.
+| keepYoungerThan specifies the minimum age in nanoseconds of an image and its referrers for it to be considered a candidate for pruning.
+DEPRECATED: This field is deprecated in favor of keepYoungerThanDuration. If both are set, this field is ignored and keepYoungerThanDuration takes precedence.
 
 | `keepYoungerThanDuration`
 | `string`
-| keepYoungerThanDuration specifies the minimum age of an image and its referrers for it to be considered a candidate for pruning. Defaults to 60m (60 minutes).
+| keepYoungerThanDuration specifies the minimum age of an image and its referrers for it to be considered a candidate for pruning.
+Defaults to 60m (60 minutes).
 
 | `logLevel`
 | `string`
-| logLevel sets the level of log output for the pruner job. 
- Valid values are: "Normal", "Debug", "Trace", "TraceAll". Defaults to "Normal".
+| logLevel sets the level of log output for the pruner job.
+
+Valid values are: "Normal", "Debug", "Trace", "TraceAll".
+Defaults to "Normal".
 
 | `nodeSelector`
 | `object (string)`
@@ -106,15 +115,18 @@ Type::
 
 | `schedule`
 | `string`
-| schedule specifies when to execute the job using standard cronjob syntax: https://wikipedia.org/wiki/Cron. Defaults to `0 0 * * *`.
+| schedule specifies when to execute the job using standard cronjob syntax: https://wikipedia.org/wiki/Cron.
+Defaults to `0 0 * * *`.
 
 | `successfulJobsHistoryLimit`
 | `integer`
-| successfulJobsHistoryLimit specifies how many successful image pruner jobs to retain. Defaults to 3 if not set.
+| successfulJobsHistoryLimit specifies how many successful image pruner jobs to retain.
+Defaults to 3 if not set.
 
 | `suspend`
 | `boolean`
-| suspend specifies whether or not to suspend subsequent executions of this cronjob. Defaults to false.
+| suspend specifies whether or not to suspend subsequent executions of this cronjob.
+Defaults to false.
 
 | `tolerations`
 | `array`
@@ -122,7 +134,8 @@ Type::
 
 | `tolerations[]`
 | `object`
-| The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.
+| The pod this Toleration is attached to tolerates any taint that matches
+the triple <key,value,effect> using the matching operator <operator>.
 
 |===
 === .spec.affinity
@@ -174,22 +187,43 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node matches the corresponding matchExpressions; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
+| An empty preferred scheduling term matches all objects with implicit weight 0
+(i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `object`
-| If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node.
+| If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to an update), the system
+may or may not try to eventually evict the pod from its node.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node matches the corresponding matchExpressions; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -202,7 +236,8 @@ Type::
 Description::
 +
 --
-An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
+An empty preferred scheduling term matches all objects with implicit weight 0
+(i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).
 --
 
 Type::
@@ -250,7 +285,8 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 | `matchFields`
 | `array`
@@ -258,7 +294,8 @@ Type::
 
 | `matchFields[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[].preference.matchExpressions
@@ -278,7 +315,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -300,11 +338,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[].preference.matchFields
@@ -324,7 +367,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -346,18 +390,27 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node.
+If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to an update), the system
+may or may not try to eventually evict the pod from its node.
 --
 
 Type::
@@ -378,7 +431,9 @@ Required::
 
 | `nodeSelectorTerms[]`
 | `object`
-| A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
+| A null or empty node selector term matches no objects. The requirements of
+them are ANDed.
+The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms
@@ -398,7 +453,9 @@ Type::
 Description::
 +
 --
-A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
+A null or empty node selector term matches no objects. The requirements of
+them are ANDed.
+The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.
 --
 
 Type::
@@ -417,7 +474,8 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 | `matchFields`
 | `array`
@@ -425,7 +483,8 @@ Type::
 
 | `matchFields[]`
 | `object`
-| A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchExpressions
@@ -445,7 +504,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -467,11 +527,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchFields
@@ -491,7 +556,8 @@ Type::
 Description::
 +
 --
-A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A node selector requirement is a selector that contains values, a key, and an operator
+that relates the key and values.
 --
 
 Type::
@@ -513,11 +579,16 @@ Required::
 
 | `operator`
 | `string`
-| Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
+| Represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
 
 | `values`
 | `array (string)`
-| An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
+| An array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. If the operator is Gt or Lt, the values
+array must have a single element, which will be interpreted as an integer.
+This array is replaced during a strategic merge patch.
 
 |===
 === .spec.affinity.podAffinity
@@ -539,7 +610,15 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
@@ -547,18 +626,37 @@ Type::
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+| If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 
 | `requiredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+| Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -593,7 +691,8 @@ Required::
 
 | `weight`
 | `integer`
-| weight associated with matching the corresponding podAffinityTerm, in the range 1-100.
+| weight associated with matching the corresponding podAffinityTerm,
+in the range 1-100.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm
@@ -617,34 +716,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -663,11 +791,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector.matchExpressions
@@ -687,7 +818,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -709,18 +841,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -739,11 +879,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector.matchExpressions
@@ -763,7 +906,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -785,18 +929,28 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+If the affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 --
 
 Type::
@@ -809,7 +963,12 @@ Type::
 Description::
 +
 --
-Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 --
 
 Type::
@@ -826,34 +985,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -872,11 +1060,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector.matchExpressions
@@ -896,7 +1087,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -918,18 +1110,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -948,11 +1148,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector.matchExpressions
@@ -972,7 +1175,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -994,11 +1198,15 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity
@@ -1020,7 +1228,15 @@ Type::
 
 | `preferredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+| The scheduler will prefer to schedule pods to nodes that satisfy
+the anti-affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling anti-affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 
 | `preferredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
@@ -1028,18 +1244,37 @@ Type::
 
 | `requiredDuringSchedulingIgnoredDuringExecution`
 | `array`
-| If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+| If the anti-affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the anti-affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 
 | `requiredDuringSchedulingIgnoredDuringExecution[]`
 | `object`
-| Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+| Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.
+The scheduler will prefer to schedule pods to nodes that satisfy
+the anti-affinity expressions specified by this field, but it may choose
+a node that violates one or more of the expressions. The node that is
+most preferred is the one with the greatest sum of weights, i.e.
+for each node that meets all of the scheduling requirements (resource
+request, requiredDuringScheduling anti-affinity expressions, etc.),
+compute a sum by iterating through the elements of this field and adding
+"weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the
+node(s) with the highest sum are the most preferred.
 --
 
 Type::
@@ -1074,7 +1309,8 @@ Required::
 
 | `weight`
 | `integer`
-| weight associated with matching the corresponding podAffinityTerm, in the range 1-100.
+| weight associated with matching the corresponding podAffinityTerm,
+in the range 1-100.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm
@@ -1098,34 +1334,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -1144,11 +1409,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.labelSelector.matchExpressions
@@ -1168,7 +1436,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1190,18 +1459,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -1220,11 +1497,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[].podAffinityTerm.namespaceSelector.matchExpressions
@@ -1244,7 +1524,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1266,18 +1547,28 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution
 Description::
 +
 --
-If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.
+If the anti-affinity requirements specified by this field are not met at
+scheduling time, the pod will not be scheduled onto the node.
+If the anti-affinity requirements specified by this field cease to be met
+at some point during pod execution (e.g. due to a pod label update), the
+system may or may not try to eventually evict the pod from its node.
+When there are multiple elements, the lists of nodes corresponding to each
+podAffinityTerm are intersected, i.e. all terms must be satisfied.
 --
 
 Type::
@@ -1290,7 +1581,12 @@ Type::
 Description::
 +
 --
-Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+Defines a set of pods (namely those matching the labelSelector
+relative to the given namespace(s)) that this pod should be
+co-located (affinity) or not co-located (anti-affinity) with,
+where co-located is defined as running on a node whose value of
+the label with key <topologyKey> matches that of any node on which
+a pod of the set of pods is running
 --
 
 Type::
@@ -1307,34 +1603,63 @@ Required::
 
 | `labelSelector`
 | `object`
-| A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+| A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 
 | `matchLabelKeys`
 | `array (string)`
-| MatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both matchLabelKeys and labelSelector. Also, matchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key in (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both matchLabelKeys and labelSelector.
+Also, matchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `mismatchLabelKeys`
 | `array (string)`
-| MismatchLabelKeys is a set of pod label keys to select which pods will be taken into consideration. The keys are used to lookup values from the incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)` to select the group of existing pods which pods will be taken into consideration for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming pod labels will be ignored. The default value is empty. The same key is forbidden to exist in both mismatchLabelKeys and labelSelector. Also, mismatchLabelKeys cannot be set when labelSelector isn't set. This is an alpha field and requires enabling MatchLabelKeysInPodAffinity feature gate.
+| MismatchLabelKeys is a set of pod label keys to select which pods will
+be taken into consideration. The keys are used to lookup values from the
+incoming pod labels, those key-value labels are merged with `labelSelector` as `key notin (value)`
+to select the group of existing pods which pods will be taken into consideration
+for the incoming pod's pod (anti) affinity. Keys that don't exist in the incoming
+pod labels will be ignored. The default value is empty.
+The same key is forbidden to exist in both mismatchLabelKeys and labelSelector.
+Also, mismatchLabelKeys cannot be set when labelSelector isn't set.
+This is a beta field and requires enabling MatchLabelKeysInPodAffinity feature gate (enabled by default).
 
 | `namespaceSelector`
 | `object`
-| A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+| A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 
 | `namespaces`
 | `array (string)`
-| namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace".
+| namespaces specifies a static list of namespace names that the term applies to.
+The term is applied to the union of the namespaces listed in this field
+and the ones selected by namespaceSelector.
+null or empty namespaces list and null namespaceSelector means "this pod's namespace".
 
 | `topologyKey`
 | `string`
-| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.
+| This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching
+the labelSelector in the specified namespaces, where co-located is defined as running on a node
+whose value of the label with key topologyKey matches that of any node on which any of the
+selected pods is running.
+Empty topologyKey is not allowed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector
 Description::
 +
 --
-A label query over a set of resources, in this case pods. If it's null, this PodAffinityTerm matches with no Pods.
+A label query over a set of resources, in this case pods.
+If it's null, this PodAffinityTerm matches with no Pods.
 --
 
 Type::
@@ -1353,11 +1678,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].labelSelector.matchExpressions
@@ -1377,7 +1705,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1399,18 +1728,26 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector
 Description::
 +
 --
-A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces.
+A label query over the set of namespaces that the term applies to.
+The term is applied to the union of the namespaces selected by this field
+and the ones listed in the namespaces field.
+null selector and null or empty namespaces list means "this pod's namespace".
+An empty selector ({}) matches all namespaces.
 --
 
 Type::
@@ -1429,11 +1766,14 @@ Type::
 
 | `matchExpressions[]`
 | `object`
-| A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+| A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 
 | `matchLabels`
 | `object (string)`
-| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
+| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is "key", the
+operator is "In", and the values array contains only "value". The requirements are ANDed.
 
 |===
 === .spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[].namespaceSelector.matchExpressions
@@ -1453,7 +1793,8 @@ Type::
 Description::
 +
 --
-A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.
+A label selector requirement is a selector that contains values, a key, and an operator that
+relates the key and values.
 --
 
 Type::
@@ -1475,11 +1816,15 @@ Required::
 
 | `operator`
 | `string`
-| operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
+| operator represents a key's relationship to a set of values.
+Valid operators are In, NotIn, Exists and DoesNotExist.
 
 | `values`
 | `array (string)`
-| values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
+| values is an array of string values. If the operator is In or NotIn,
+the values array must be non-empty. If the operator is Exists or DoesNotExist,
+the values array must be empty. This array is replaced during a strategic
+merge patch.
 
 |===
 === .spec.resources
@@ -1501,9 +1846,13 @@ Type::
 
 | `claims`
 | `array`
-| Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. 
- This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. 
- This field is immutable. It can only be set for containers.
+| Claims lists the names of resources, defined in spec.resourceClaims,
+that are used by this container.
+
+This is an alpha field and requires enabling the
+DynamicResourceAllocation feature gate.
+
+This field is immutable. It can only be set for containers.
 
 | `claims[]`
 | `object`
@@ -1511,20 +1860,28 @@ Type::
 
 | `limits`
 | `integer-or-string`
-| Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
+| Limits describes the maximum amount of compute resources allowed.
+More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
 
 | `requests`
 | `integer-or-string`
-| Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
+| Requests describes the minimum amount of compute resources required.
+If Requests is omitted for a container, it defaults to Limits if that is explicitly specified,
+otherwise to an implementation-defined value. Requests cannot exceed Limits.
+More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
 
 |===
 === .spec.resources.claims
 Description::
 +
 --
-Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. 
- This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. 
- This field is immutable. It can only be set for containers.
+Claims lists the names of resources, defined in spec.resourceClaims,
+that are used by this container.
+
+This is an alpha field and requires enabling the
+DynamicResourceAllocation feature gate.
+
+This field is immutable. It can only be set for containers.
 --
 
 Type::
@@ -1554,7 +1911,15 @@ Required::
 
 | `name`
 | `string`
-| Name must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container.
+| Name must match the name of one entry in pod.spec.resourceClaims of
+the Pod where this field is used. It makes that resource available
+inside a container.
+
+| `request`
+| `string`
+| Request is the name chosen for a request in the referenced claim.
+If empty, everything from the claim is made available, otherwise
+only the result of this request.
 
 |===
 === .spec.tolerations
@@ -1574,7 +1939,8 @@ Type::
 Description::
 +
 --
-The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.
+The pod this Toleration is attached to tolerates any taint that matches
+the triple <key,value,effect> using the matching operator <operator>.
 --
 
 Type::
@@ -1589,23 +1955,32 @@ Type::
 
 | `effect`
 | `string`
-| Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
+| Effect indicates the taint effect to match. Empty means match all taint effects.
+When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
 
 | `key`
 | `string`
-| Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys.
+| Key is the taint key that the toleration applies to. Empty means match all taint keys.
+If the key is empty, operator must be Exists; this combination means to match all values and all keys.
 
 | `operator`
 | `string`
-| Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
+| Operator represents a key's relationship to the value.
+Valid operators are Exists and Equal. Defaults to Equal.
+Exists is equivalent to wildcard for value, so that a pod can
+tolerate all taints of a particular category.
 
 | `tolerationSeconds`
 | `integer`
-| TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.
+| TolerationSeconds represents the period of time the toleration (which must be
+of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default,
+it is not set, which means tolerate the taint forever (do not evict). Zero and
+negative values will be treated as 0 (evict immediately) by the system.
 
 | `value`
 | `string`
-| Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.
+| Value is the taint value the toleration matches to.
+If the operator is Exists, the value should be empty, otherwise just a regular string.
 
 |===
 === .status
@@ -1662,6 +2037,8 @@ Type::
   `object`
 
 Required::
+  - `lastTransitionTime`
+  - `status`
   - `type`
 
 
@@ -1672,7 +2049,8 @@ Required::
 
 | `lastTransitionTime`
 | `string`
-| 
+| lastTransitionTime is the last time the condition transitioned from one status to another.
+This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.
 
 | `message`
 | `string`
@@ -1684,11 +2062,11 @@ Required::
 
 | `status`
 | `string`
-| 
+| status of the condition, one of True, False, Unknown.
 
 | `type`
 | `string`
-| 
+| type of condition in CamelCase or in foo.example.com/CamelCase.
 
 |===
 
diff --git a/rest_api/operator_apis/ingresscontroller-operator-openshift-io-v1.adoc b/rest_api/operator_apis/ingresscontroller-operator-openshift-io-v1.adoc
index bbe8210a841f..e1cd522bfbc8 100644
--- a/rest_api/operator_apis/ingresscontroller-operator-openshift-io-v1.adoc
+++ b/rest_api/operator_apis/ingresscontroller-operator-openshift-io-v1.adoc
@@ -993,7 +993,7 @@ Type::
 | `string`
 | protocol specifies whether the load balancer uses PROXY protocol to forward connections to
 the IngressController. See "service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features:
-"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas"
+"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas
 
 PROXY protocol can be used with load balancers that support it to
 communicate the source addresses of client connections when
@@ -2948,11 +2948,11 @@ This should be when the underlying condition changed.  If that is not known, the
 
 | `message`
 | `string`
-| 
+|
 
 | `reason`
 | `string`
-| 
+|
 
 | `status`
 | `string`
@@ -3548,7 +3548,7 @@ Type::
 | `string`
 | protocol specifies whether the load balancer uses PROXY protocol to forward connections to
 the IngressController. See "service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features:
-"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas"
+"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas
 
 PROXY protocol can be used with load balancers that support it to
 communicate the source addresses of client connections when
@@ -4012,7 +4012,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -4145,7 +4145,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -4247,7 +4247,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -4349,7 +4349,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rest_api/operator_apis/kubestorageversionmigrator-operator-openshift-io-v1.adoc b/rest_api/operator_apis/kubestorageversionmigrator-operator-openshift-io-v1.adoc
index 3d404c15ed63..38f50a1b52e0 100644
--- a/rest_api/operator_apis/kubestorageversionmigrator-operator-openshift-io-v1.adoc
+++ b/rest_api/operator_apis/kubestorageversionmigrator-operator-openshift-io-v1.adoc
@@ -11,8 +11,9 @@ toc::[]
 Description::
 +
 --
-KubeStorageVersionMigrator provides information to configure an operator to manage kube-storage-version-migrator. 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+KubeStorageVersionMigrator provides information to configure an operator to manage kube-storage-version-migrator.
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
@@ -68,8 +69,11 @@ Type::
 
 | `logLevel`
 | `string`
-| logLevel is an intent based logging for an overall component.  It does not give fine grained control, but it is a simple way to manage coarse grained logging choices that operators have to interpret for their operands. 
- Valid values are: "Normal", "Debug", "Trace", "TraceAll". Defaults to "Normal".
+| logLevel is an intent based logging for an overall component.  It does not give fine grained control, but it is a
+simple way to manage coarse grained logging choices that operators have to interpret for their operands.
+
+Valid values are: "Normal", "Debug", "Trace", "TraceAll".
+Defaults to "Normal".
 
 | `managementState`
 | `string`
@@ -77,16 +81,24 @@ Type::
 
 | `observedConfig`
 | ``
-| observedConfig holds a sparse config that controller has observed from the cluster state.  It exists in spec because it is an input to the level for the operator
+| observedConfig holds a sparse config that controller has observed from the cluster state.  It exists in spec because
+it is an input to the level for the operator
 
 | `operatorLogLevel`
 | `string`
-| operatorLogLevel is an intent based logging for the operator itself.  It does not give fine grained control, but it is a simple way to manage coarse grained logging choices that operators have to interpret for themselves. 
- Valid values are: "Normal", "Debug", "Trace", "TraceAll". Defaults to "Normal".
+| operatorLogLevel is an intent based logging for the operator itself.  It does not give fine grained control, but it is a
+simple way to manage coarse grained logging choices that operators have to interpret for themselves.
+
+Valid values are: "Normal", "Debug", "Trace", "TraceAll".
+Defaults to "Normal".
 
 | `unsupportedConfigOverrides`
 | ``
-| unsupportedConfigOverrides overrides the final configuration that was computed by the operator. Red Hat does not support the use of this field. Misuse of this field could lead to unexpected behavior or conflict with other configuration options. Seek guidance from the Red Hat support before using this field. Use of this property blocks cluster upgrades, it must be removed before upgrading your cluster.
+| unsupportedConfigOverrides overrides the final configuration that was computed by the operator.
+Red Hat does not support the use of this field.
+Misuse of this field could lead to unexpected behavior or conflict with other configuration options.
+Seek guidance from the Red Hat support before using this field.
+Use of this property blocks cluster upgrades, it must be removed before upgrading your cluster.
 
 |===
 === .status
@@ -122,6 +134,10 @@ Type::
 | `object`
 | GenerationStatus keeps track of the generation for a given resource so that decisions about forced updates can be made.
 
+| `latestAvailableRevision`
+| `integer`
+| latestAvailableRevision is the deploymentID of the most recent deployment
+
 | `observedGeneration`
 | `integer`
 | observedGeneration is the last generation change you've dealt with
@@ -159,6 +175,8 @@ Type::
   `object`
 
 Required::
+  - `lastTransitionTime`
+  - `status`
   - `type`
 
 
@@ -169,7 +187,8 @@ Required::
 
 | `lastTransitionTime`
 | `string`
-| 
+| lastTransitionTime is the last time the condition transitioned from one status to another.
+This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.
 
 | `message`
 | `string`
@@ -181,11 +200,11 @@ Required::
 
 | `status`
 | `string`
-| 
+| status of the condition, one of True, False, Unknown.
 
 | `type`
 | `string`
-| 
+| type of condition in CamelCase or in foo.example.com/CamelCase.
 
 |===
 === .status.generations
@@ -211,6 +230,11 @@ GenerationStatus keeps track of the generation for a given resource so that deci
 Type::
   `object`
 
+Required::
+  - `group`
+  - `name`
+  - `namespace`
+  - `resource`
 
 
 
diff --git a/rest_api/operator_apis/operator-apis-index.adoc b/rest_api/operator_apis/operator-apis-index.adoc
index d0e33659784c..56fb6dc6b0ca 100644
--- a/rest_api/operator_apis/operator-apis-index.adoc
+++ b/rest_api/operator_apis/operator-apis-index.adoc
@@ -79,8 +79,10 @@ Type::
 Description::
 +
 --
-Config is the configuration object for a registry instance managed by the registry operator 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+Config is the configuration object for a registry instance managed by
+the registry operator
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
@@ -177,8 +179,10 @@ Type::
 Description::
 +
 --
-ImagePruner is the configuration object for an image registry pruner managed by the registry operator. 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+ImagePruner is the configuration object for an image registry pruner
+managed by the registry operator.
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
@@ -265,8 +269,9 @@ Type::
 Description::
 +
 --
-KubeStorageVersionMigrator provides information to configure an operator to manage kube-storage-version-migrator. 
- Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
+KubeStorageVersionMigrator provides information to configure an operator to manage kube-storage-version-migrator.
+
+Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
 --
 
 Type::
diff --git a/rest_api/security_apis/securitycontextconstraints-security-openshift-io-v1.adoc b/rest_api/security_apis/securitycontextconstraints-security-openshift-io-v1.adoc
index 1456b1c5f98c..de76d838f5e2 100644
--- a/rest_api/security_apis/securitycontextconstraints-security-openshift-io-v1.adoc
+++ b/rest_api/security_apis/securitycontextconstraints-security-openshift-io-v1.adoc
@@ -85,12 +85,12 @@ is allowed in the "Volumes" field.
 | `allowedUnsafeSysctls`
 | ``
 | AllowedUnsafeSysctls is a list of explicitly allowed unsafe sysctls, defaults to none.
-Each entry is either a plain sysctl name or ends in "*" in which case it is considered
+Each entry is either a plain sysctl name or ends in "\*" in which case it is considered
 as a prefix of allowed sysctls. Single * means all unsafe sysctls are allowed.
 Kubelet has to whitelist all allowed unsafe sysctls explicitly to avoid rejection.
 
 Examples:
-e.g. "foo/*" allows "foo/bar", "foo/baz", etc.
+e.g. "foo/\*" allows "foo/bar", "foo/baz", etc.
 e.g. "foo.*" allows "foo.bar", "foo.baz", etc.
 
 | `apiVersion`
@@ -111,11 +111,11 @@ process can gain more privileges than its parent process.
 | `forbiddenSysctls`
 | ``
 | ForbiddenSysctls is a list of explicitly forbidden sysctls, defaults to none.
-Each entry is either a plain sysctl name or ends in "*" in which case it is considered
+Each entry is either a plain sysctl name or ends in "\*" in which case it is considered
 as a prefix of forbidden sysctls. Single * means all sysctls are forbidden.
 
 Examples:
-e.g. "foo/*" forbids "foo/bar", "foo/baz", etc.
+e.g. "foo/\*" forbids "foo/bar", "foo/baz", etc.
 e.g. "foo.*" forbids "foo.bar", "foo.baz", etc.
 
 | `fsGroup`
@@ -274,7 +274,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../security_apis/securitycontextconstraints-security-openshift-io-v1.adoc#securitycontextconstraints-security-openshift-io-v1[`SecurityContextConstraints`] schema
-| 
+|
 |===
 
 .HTTP responses
@@ -429,7 +429,7 @@ Description::
 | Parameter | Type | Description
 | `body`
 | xref:../security_apis/securitycontextconstraints-security-openshift-io-v1.adoc#securitycontextconstraints-security-openshift-io-v1[`SecurityContextConstraints`] schema
-| 
+|
 |===
 
 .HTTP responses
diff --git a/rosa_architecture/about-hcp.adoc b/rosa_architecture/about-hcp.adoc
index cf18ed19b9ee..d75e17fd4dc6 100644
--- a/rosa_architecture/about-hcp.adoc
+++ b/rosa_architecture/about-hcp.adoc
@@ -89,7 +89,7 @@ ifdef::openshift-rosa-hcp[]
 link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.html#rosa-policy-process-security[Understanding process and security]
 endif::openshift-rosa-hcp[]
 ifndef::openshift-rosa-hcp[]
-xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-process-security[Understanding process and security]
+xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-process-security[Understanding process and security]
 endif::openshift-rosa-hcp[]
 | 
 xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-hcp-service-definition[{hcp-title} service definition]
@@ -148,6 +148,15 @@ endif::openshift-rosa-hcp[]
 | link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
 | 
 xref:../storage/index.adoc#storage-overview[Storage]
+| 
+ifdef::openshift-rosa-hcp[]
+link:https://docs.openshift.com/rosa/observability/monitoring/monitoring-overview.html#monitoring-overview_virt-monitoring-overview[Monitoring overview]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview_virt-monitoring-overview[Monitoring overview]
+endif::openshift-rosa-hcp[]
+| 
+xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[{hcp-title} life cycle]
 |
 ifdef::openshift-rosa-hcp[]
 link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html#rosa-policy-responsibility-matrix[ROSA responsibility matrix]
@@ -251,4 +260,4 @@ For additional information about ROSA installation, see link:https://www.redhat.
 * link:https://www.openshift.com/products/amazon-openshift[ROSA product page]
 * link:https://aws.amazon.com/rosa/[AWS product page]
 * link:https://access.redhat.com/products/red-hat-openshift-service-aws[Red{nbsp}Hat Customer Portal]
-* link:https://learn.openshift.com[Learn about OpenShift]
\ No newline at end of file
+* link:https://learn.openshift.com[Learn about OpenShift]
diff --git a/rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc b/rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc
index 83d134e93ed9..f4ef23ebc129 100644
--- a/rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc
+++ b/rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc
@@ -37,13 +37,28 @@ Security features for AWS STS include:
 
 [id="components-specific-to-rosa-hcp-with-sts"]
 == Components of {hcp-title}
-* *AWS infrastructure* - The infrastructure required for the cluster including the Amazon EC2 instances, Amazon EBS storage, and networking components. See link:https://docs.openshift/rosa/rosa_architecture/rosa_policy_service_definition/rosa-service-definition.html#rosa-sdpolicy-aws-compute-types_rosa-service-definition[AWS compute types] to see the supported instance types for compute nodes and link:https://docs.openshift/rosa/rosa_planning/rosa-sts-aws-prereqs.html#rosa-ec2-instances_rosa-sts-aws-prereqs[provisioned AWS infrastructure] for more information on cloud resource configuration.
+* *AWS infrastructure* - The infrastructure required for the cluster including the Amazon EC2 instances, Amazon EBS storage, and networking components. See xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-instance-types_rosa-hcp-service-definition[AWS compute types] to see the supported instance types for compute nodes and xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-ec2-instances_rosa-sts-aws-prereqs[provisioned AWS infrastructure] for more information on cloud resource configuration.
 * *AWS STS* - A method for granting short-term, dynamic tokens to provide users the necessary permissions to temporarily interact with your AWS account resources.
 * *OpenID Connect (OIDC)* - A mechanism for cluster Operators to authenticate with AWS, assume the cluster roles through a trust policy, and obtain temporary credentials from AWS IAM STS to make the required API calls.
 * *Roles and policies* - The roles and policies used by {hcp-title} can be divided into account-wide roles and policies and Operator roles and policies.
 +
-The policies determine the allowed actions for each of the roles. See link:https://docs.openshift/rosa/rosa_architecture/rosa-sts-about-iam-resources.html#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS] for more details about the individual roles and policies and link:https://docs.openshift/rosa/rosa_planning/rosa-sts-ocm-role.html#rosa-sts-ocm-role[ROSA IAM role resource] for more details about trust policies.
+The policies determine the allowed actions for each of the roles.
+ifdef::openshift-rosa[]
+See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources] for more details about the individual roles and policies. See xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[ROSA IAM role resource] for more details about trust policies.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-hcp-about-iam-resources[About IAM resources] for more details about the individual roles and policies. See xref:../rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc#rosa-hcp-prepare-iam-roles-resources[Required IAM roles and resources] for more details on preparing these resources in your cluster.
+endif::openshift-rosa-hcp[]
 +
+--
+** The following account-wide roles are required:
+
+*** `<prefix>-HCP-ROSA-Worker-Role`
+*** `<prefix>-HCP-ROSA-Support-Role`
+*** `<prefix>-HCP-ROSA-Installer-Role`
+
+** The following account-wide AWS-managed policies are required:
+
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAInstallerPolicy.html[ROSAInstallerPolicy]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAWorkerInstancePolicy.html[ROSAWorkerInstancePolicy]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy.html[ROSASRESupportPolicy]
@@ -56,6 +71,7 @@ The policies determine the allowed actions for each of the roles. See link:https
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAKubeControllerPolicy.html[ROSAKubeControllerPolicy]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html[ROSAManageSubscription]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSANodePoolManagementPolicy.html[ROSANodePoolManagementPolicy]
+--
 +
 [NOTE]
 ====
@@ -63,7 +79,7 @@ Certain policies are used by the cluster Operator roles, listed below. The Opera
 ====
 +
 ** The Operator roles are:
-+
+
 *** <operator_role_prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials
 *** <operator_role_prefix>-openshift-cloud-network-config-controller-cloud-credentials
 *** <operator_role_prefix>-openshift-machine-api-aws-cloud-credentials
diff --git a/rosa_architecture/index.adoc b/rosa_architecture/index.adoc
index b0b62f907eae..4816e2cb3163 100644
--- a/rosa_architecture/index.adoc
+++ b/rosa_architecture/index.adoc
@@ -120,7 +120,7 @@ xref:../installing/installing_vsphere/upi/installing-restricted-networks-vsphere
 xref:../installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc#installing-restricted-networks-bare-metal[bare metal] and the cluster
 does not have full access to the internet, you must mirror the {product-title} installation images. To do this action, use one of the following methods, so that you can install a cluster in a restricted network.
 *** xref:../disconnected/mirroring/installing-mirroring-installation-images.adoc#installing-mirroring-installation-images[Mirroring images for a disconnected installation]
-*** xref:../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation by using the oc-mirror plug-in]
+*** xref:../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]
 endif::openshift-origin[]
 
 ifdef::openshift-origin[]
@@ -185,7 +185,7 @@ xref:../applications/working_with_helm_charts/understanding-helm.adoc#understand
 
 - **xref:../applications/deployments/what-deployments-are.adoc#what-deployments-are[Create deployments]**:  Use `Deployment` objects to exert fine-grained management over applications. Deployments create replica sets according to the rollout strategy, which orchestrates pod lifecycles.
 
-- **xref:../openshift_images/using-templates.adoc#using-templates[Create templates]**: Use existing templates or create your own templates that describe how an application is built or deployed. A template can combine images with descriptions, parameters, replicas, exposed ports and other content that defines how an application can be run or built.
+- **xref:../applications/creating_applications/using-templates.adoc#using-templates[Create templates]**: Use existing templates or create your own templates that describe how an application is built or deployed. A template can combine images with descriptions, parameters, replicas, exposed ports and other content that defines how an application can be run or built.
 
 - **xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Understand Operators]**: Operators are the preferred method for creating on-cluster applications for {product-title} {product-version}. Learn about the Operator Framework and how to deploy applications by using installed Operators into your projects.
 
@@ -242,7 +242,7 @@ Manage machines, provide services to users, and follow monitoring and logging re
 
 - **xref:../authentication/understanding-authentication.adoc#understanding-authentication[Manage authentication]**: Learn how user, group, and API authentication works in {product-title}. {product-title} supports xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[multiple identity providers].
 
-- **Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates**: {product-title} creates certificates by default for the Ingress Operator, the API server, and for services needed by complex middleware applications that require encryption. You might need to change, add, or rotate these certificates.
+- **Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates**: {product-title} creates certificates by default for the Ingress Operator, the API server, and for services needed by complex middleware applications that require encryption. You might need to change, add, or rotate these certificates.
 
 - **xref:../networking/understanding-networking.adoc#understanding-networking[Manage networking]**: The cluster network in {product-title} is managed by the xref:../networking/networking_operators/cluster-network-operator.adoc#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] (CNO). The Multus Container Network Interface adds the capability to attach xref:../networking/multiple_networks/understanding-multiple-networks.adoc#understanding-multiple-networks[multiple network interfaces] to a pod. By using
 xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[network policy] features, you can isolate your pods or permit selected traffic.
@@ -272,8 +272,6 @@ Use the Cluster Version Operator (CVO) to upgrade your {product-title} cluster.
 
 === Observe a cluster
 
-- **xref:../observability/logging/cluster-logging.adoc#cluster-logging[OpenShift Logging]**: Learn about logging and configure different logging components, such as log storage, log collectors, and the logging web console plugin.
-
 - **xref:../observability/distr_tracing/distr_tracing_arch/distr-tracing-architecture.adoc#distr-tracing-architecture[Red Hat OpenShift distributed tracing platform]**: Store and visualize large volumes of requests passing through distributed systems, across the whole stack of microservices, and under heavy loads. Use the distributed tracing platform for monitoring distributed transactions, gathering insights into your instrumented services, network profiling, performance and latency optimization, root cause analysis, and troubleshooting the interaction between components in modern cloud-native microservices-based applications.
 
 // xreffing to the installation page until further notice because OTEL content is currently planned for internal restructuring across pages that is likely to result in renamed page files
@@ -281,9 +279,9 @@ Use the Cluster Version Operator (CVO) to upgrade your {product-title} cluster.
 
 - **xref:../observability/network_observability/network-observability-overview.adoc#network-observability-overview[Network Observability]**: Observe network traffic for {product-title} clusters by using eBPF technology to create and enrich network flows. You can xref:../observability/network_observability/metrics-alerts-dashboards.adoc#metrics-alerts-dashboards_metrics-alerts-dashboards[view dashboards, customize alerts], and xref:../observability/network_observability/observing-network-traffic.adoc#network-observability-trafficflow_nw-observe-network-traffic[analyze network flow] information for further insight and troubleshooting.
 
-- **xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[In-cluster monitoring]**:
-Learn to  xref:../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[configure the monitoring stack].
-After configuring monitoring, use the web console to access xref:../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[monitoring dashboards]. In addition to infrastructure metrics, you can also scrape and view metrics for your own services.
+- **xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[In-cluster monitoring]**:
+Learn to  xref:../observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc#core-platform-monitoring-first-steps[configure the monitoring stack].
+After configuring monitoring, use the web console to access xref:../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#reviewing-monitoring-dashboards-admin_accessing-metrics-as-an-administrator[monitoring dashboards]. In addition to infrastructure metrics, you can also scrape and view metrics for your own services.
 
 - **xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring_about-remote-health-monitoring[Remote health monitoring]**: {product-title} collects anonymized aggregated information about your cluster. By using Telemetry and the Insights Operator, this data is received by Red Hat and used to improve {product-title}. You can view the xref:../support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc#showing-data-collected-by-remote-health-monitoring_showing-data-collected-by-remote-health-monitoring[data collected by remote health monitoring].
 
diff --git a/rosa_architecture/learn_more_about_openshift.adoc b/rosa_architecture/learn_more_about_openshift.adoc
index 4c1c18f62bbf..ab9a86b20262 100644
--- a/rosa_architecture/learn_more_about_openshift.adoc
+++ b/rosa_architecture/learn_more_about_openshift.adoc
@@ -47,12 +47,11 @@ Use the following sections to find content to help you learn about and use {prod
 
 | xref:../architecture/architecture.adoc#architecture[Architecture]
 | xref:../machine_configuration/index.adoc#machine-config-overview[Machine configuration overview]
-| xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
 | link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]
 
 | link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
 | xref:../networking/understanding-networking.adoc#understanding-networking[Networking]
-| xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+| xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
 | link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]
 
 |
@@ -88,7 +87,6 @@ Use the following sections to find content to help you learn about and use {prod
 | link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]
 
 |
-| xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
 | link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]
 
 |
@@ -96,7 +94,7 @@ Use the following sections to find content to help you learn about and use {prod
 |
 
 |
-| xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring]
+| xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[Monitoring]
 |
 
 |
diff --git a/rosa_architecture/rosa-sts-about-iam-resources.adoc b/rosa_architecture/rosa-sts-about-iam-resources.adoc
index c36e6b7b7959..4e43c336d01a 100644
--- a/rosa_architecture/rosa-sts-about-iam-resources.adoc
+++ b/rosa_architecture/rosa-sts-about-iam-resources.adoc
@@ -1,41 +1,72 @@
 :_mod-docs-content-type: ASSEMBLY
+// This assembly is the target of a symbolic link.
+// The symbolic link at openshift-docs/rosa_planning/rosa-hcp-iam-resources.adoc
+// points to this file's real location, which is
+// openshift-docs/rosa_architecture/rosa-sts-about-iam-resources.adoc
+ifndef::openshift-rosa-hcp[]
 [id="rosa-sts-about-iam-resources"]
-= About IAM resources for ROSA clusters that use STS
+= Required IAM resources for STS clusters
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: rosa-sts-about-iam-resources
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+[id="rosa-hcp-about-iam-resources"]
+= Required IAM resources
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: rosa-sts-about-iam-resources
+endif::openshift-rosa-hcp[]
 
 toc::[]
 
-To deploy a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS), you must create the following AWS Identity Access Management (IAM) resources:
-
-* Specific account-wide IAM roles and policies that provide the STS permissions required for ROSA support, installation, control plane, and compute functionality. This includes account-wide Operator policies.
+ifndef::openshift-rosa-hcp[]
+To deploy a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS),
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title-first} uses the AWS Security Token Service (STS) to provide temporary, limited-permission credentials for your cluster. This means that before you deploy your cluster,
+endif::openshift-rosa-hcp[]
+you must create the following AWS Identity Access Management (IAM) resources:
+
+* Specific account-wide IAM roles and policies that provide the STS permissions required for ROSA support, installation,
+ifndef::openshift-rosa-hcp[]
+control plane,
+endif::openshift-rosa-hcp[]
+and compute functionality. This includes account-wide Operator policies.
 * Cluster-specific Operator IAM roles that permit the ROSA cluster Operators to carry out core OpenShift functionality.
 * An OpenID Connect (OIDC) provider that the cluster Operators use to authenticate.
-* If you deploy ROSA by using {cluster-manager}, you must create the additional resources:
+* If you deploy and manage your cluster using {cluster-manager}, you must create the following additional resources:
 ** An {cluster-manager} IAM role to complete the installation on your cluster.
 ** A user role without any permissions to verify your AWS account identity.
 
-This document provides reference information about the IAM resources that you must deploy when you create a ROSA cluster that uses STS. It also includes the `aws` CLI commands that are generated when you use `manual` mode with the `rosa create` command.
+This document provides reference information about the IAM resources that you must deploy
+ifdef::openshift-rosa[]
+when you create a ROSA cluster that uses STS.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+when you create a {hcp-title} cluster.
+endif::openshift-rosa-hcp[]
+It also includes the `aws` CLI commands that are generated when you use `manual` mode with the `rosa create` command.
 
 [role="_additional-resources"]
 .Additional resources
-
-* For steps to quickly create a ROSA cluster with STS, including the AWS IAM resources, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Creating a ROSA cluster with STS using the default options].
-* For steps to create a ROSA cluster with STS using customizations, including the AWS IAM resources, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-a-cluster-with-customizations[Creating a ROSA cluster with STS using customizations].
+ifndef::openshift-rosa-hcp[]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Creating a ROSA cluster with STS using the default options]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-a-cluster-with-customizations[Creating a ROSA cluster with STS using customizations]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Creating a {hcp-title} cluster quickly]
+endif::openshift-rosa-hcp[]
 
 [id="rosa-sts-ocm-roles-and-permissions_{context}"]
 == {cluster-manager} roles and permissions
 
-If you create ROSA clusters by using {cluster-manager-url}, you must have the following AWS IAM roles linked to your AWS account to create and manage the clusters. For more information about linking your IAM roles to your AWS account, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-associating-account_rosa-sts-aws-prereqs[Associating your AWS account].
-
-[TIP]
-====
-If you only use the ROSA CLI (`rosa`), then you do not need to create these IAM roles.
-====
+If you create ROSA clusters by using {cluster-manager-url}, you must have the following AWS IAM roles linked to your AWS account to create and manage the clusters.
+ifndef::openshift-rosa-hcp[]
+For more information about linking your IAM roles to your AWS account, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-associating-account_rosa-sts-aws-prereqs[Associating your AWS account].
+endif::openshift-rosa-hcp[]
 
 These AWS IAM roles are as follows:
 
-* The ROSA user role is an AWS role used by Red{nbsp}Hat to verify the customer's AWS identity. This role has no additional permissions, and the role has a trust relationship with the Red{nbsp}Hat installer account.
+* The ROSA user role (`user-role`) is an AWS role used by Red{nbsp}Hat to verify the customer's AWS identity. This role has no additional permissions, and the role has a trust relationship with the Red{nbsp}Hat installer account.
 * An `ocm-role` resource grants the required permissions for installation of ROSA clusters in {cluster-manager}. You can apply basic or administrative permissions to the `ocm-role` resource. If you create an administrative `ocm-role` resource, {cluster-manager} can create the needed AWS Operator roles and OpenID Connect (OIDC) provider. This IAM role also creates a trust relationship with the Red{nbsp}Hat installer account as well.
 +
 [NOTE]
@@ -54,7 +85,10 @@ include::modules/rosa-sts-understanding-ocm-role.adoc[leveloffset=+2]
 [discrete]
 include::modules/rosa-sts-ocm-role-creation.adoc[leveloffset=+2]
 
-AWS IAM roles link to your AWS account to create and manage the clusters. For more information about linking your IAM roles to your AWS account, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-associating-account_rosa-sts-aws-prereqs[Associating your AWS account].
+AWS IAM roles link to your AWS account to create and manage the clusters.
+ifndef::openshift-rosa-hcp[]
+For more information about linking your IAM roles to your AWS account, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-associating-account_rosa-sts-aws-prereqs[Associating your AWS account].
+endif::openshift-rosa-hcp[]
 
 [role="_additional-resources"]
 [id="additional-resources_about-iam-resources_{context}"]
@@ -63,17 +97,17 @@ AWS IAM roles link to your AWS account to create and manage the clusters. For mo
 * link:https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Types.html[Amazon Elastic Computer Cloud Data Types]
 * link:https://docs.aws.amazon.com/STS/latest/APIReference/API_Types.html[AWS Token Security Service Data Types]
 * xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
-//
-// Keep this commented out until PR # 45306 is merged
-//
-//* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-a-cluster-with-customizations[Understanding the auto and manual deployment modes]
 
 include::modules/rosa-sts-account-wide-roles-and-policies.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-
-* For a definition of OpenShift major, minor, and patch versions, see xref:../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle-definitions_rosa-life-cycle[the {product-title} update life cycle].
+ifdef::openshift-rosa[]
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle-definitions_rosa-life-cycle[{product-title} update life cycle]
+endif::[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[{hcp-title} update life cycle]
+endif::openshift-rosa-hcp[]
 
 include::modules/rosa-sts-account-wide-role-and-policy-commands.adoc[leveloffset=+2]
 include::modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc[leveloffset=+1]
@@ -81,16 +115,24 @@ include::modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc[levelo
 [role="_additional-resources"]
 .Additional resources
 
-* For more information, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] (AWS documentation).
-* For more information about creating the required account-wide STS roles and policies see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[Creating the account-wide STS roles and policies].
+* link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] (AWS documentation)
+ifdef::openshift-rosa[]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[Creating the account-wide STS roles and policies]
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-hcp-sts-creating-a-cluster-quickly[Creating account-wide roles and policies]
+endif::openshift-rosa-hcp[]
 
 include::modules/rosa-sts-operator-roles.adoc[leveloffset=+1]
 include::modules/rosa-sts-operator-role-commands.adoc[leveloffset=+2]
 include::modules/rosa-sts-about-operator-role-prefixes.adoc[leveloffset=+2]
 
+ifdef::openshift-rosa[]
 [role="_additional-resources"]
 .Additional resources
- For steps to create the cluster-specific Operator IAM roles using a custom prefix, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-cluster-customizations-cli_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations using the CLI] or xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-cluster-customizations-ocm_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations by using {cluster-manager}].
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-cluster-customizations-cli_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations using the CLI]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-cluster-customizations-ocm_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations by using {cluster-manager}]
+endif::openshift-rosa[]
 
 [id="rosa-sts-oidc-provider-requirements-for-operators_{context}"]
 == Open ID Connect (OIDC) requirements for Operator authentication
diff --git a/rosa_architecture/rosa-understanding.adoc b/rosa_architecture/rosa-understanding.adoc
index 0d4c63888b31..663c87307350 100644
--- a/rosa_architecture/rosa-understanding.adoc
+++ b/rosa_architecture/rosa-understanding.adoc
@@ -60,6 +60,7 @@ To get started with deploying your cluster, ensure your AWS account has met the
 == Additional resources
 
 * xref:../ocm/ocm-overview.adoc#ocm-overview[OpenShift Cluster Manager]
+//* xref ../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources]
 * xref:../rosa_getting_started/rosa-getting-started.adoc#rosa-getting-started[Getting started with {product-title}]
 * link:https://aws.amazon.com/rosa/pricing/[AWS pricing page]
 
diff --git a/rosa_architecture/rosa_policy_service_definition/rosa-hcp-instance-types.adoc b/rosa_architecture/rosa_policy_service_definition/rosa-hcp-instance-types.adoc
index 79685a49b51e..d62b811f68b4 100644
--- a/rosa_architecture/rosa_policy_service_definition/rosa-hcp-instance-types.adoc
+++ b/rosa_architecture/rosa_policy_service_definition/rosa-hcp-instance-types.adoc
@@ -7,9 +7,10 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 toc::[]
 {hcp-title} offers the following worker node instance types and sizes:
 
+//TODO OSDOCS-11789: Confirm this
 [NOTE]
 ====
-Currently, {hcp-title} supports a maximum of 250 worker nodes.
+Currently, {hcp-title} supports a maximum of 500 worker nodes.
 ====
 
 include::modules/rosa-sdpolicy-am-aws-compute-types.adoc[leveloffset=+1]
diff --git a/rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc b/rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
index 2e74983e0097..241126dc28fb 100644
--- a/rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
+++ b/rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
@@ -26,7 +26,7 @@ include::modules/rosa-sdpolicy-instance-types.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../rosa_policy_service_definition/rosa-hcp-instance-types.adoc#rosa-hcp-instance-types[{hcp-title} instance types]
+For a detailed listing of supported instance types, see xref:../rosa_policy_service_definition/rosa-hcp-instance-types.adoc#rosa-hcp-instance-types[{hcp-title} instance types].
 
 include::modules/rosa-sdpolicy-am-regions-az.adoc[leveloffset=+2]
 
@@ -66,8 +66,4 @@ ifdef::openshift-rosa-hcp[]
 * link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.html[Understanding security for ROSA]
 endif::openshift-rosa-hcp[]
 
-ifndef::openshift-rosa-hcp[]
-* xref:../rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-process-security[Understanding security for ROSA]
-endif::openshift-rosa-hcp[]
-
-* xref:../rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[ROSA life cycle]
\ No newline at end of file
+* See xref:../rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[ROSA life cycle]
diff --git a/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc b/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc
index 9c4a1ea09f17..72f9ea885716 100644
--- a/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc
+++ b/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc
@@ -10,12 +10,15 @@ This documentation outlines Red{nbsp}Hat, Amazon Web Services (AWS), and custome
 
 include::modules/rosa-policy-responsibilities.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
+ifdef::openshift-rosa[]
+* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for ROSA (classic architecture) clusters using STS]
+endif::openshift-rosa[]
+ifdef::openshift-dedicated[]
+* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites]
+endif::openshift-dedicated[]
 
-* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
-endif::openshift-rosa-hcp[]
 
 
 
@@ -30,17 +33,28 @@ include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
 //---
 
 include::modules/rosa-policy-incident.adoc[leveloffset=+1]
-include::modules/rosa-policy-change-management.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
+* xref:../../rosa_cluster_admin/rosa-cluster-notifications.adoc#rosa-cluster-notifications[Cluster notifications]
+
+include::modules/rosa-policy-change-management.adoc[leveloffset=+1]
 
-* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
+[role="_additional-resources"]
+.Additional resources
+ifdef::openshift-rosa-hcp[]
+* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for {hcp-title}]
 endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa[]
+* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for ROSA (classic architecture) clusters using STS]
+endif::openshift-rosa[]
+ifdef::openshift-dedicated[]
+* xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites]
+endif::openshift-dedicated[]
 
 include::modules/rosa-policy-security-and-compliance.adoc[leveloffset=+1]
 include::modules/rosa-policy-disaster-recovery.adoc[leveloffset=+1]
+include::modules/managed-resources.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc b/rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
index a5bbdb0f7bc5..f7f96c0e766a 100644
--- a/rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
+++ b/rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
@@ -19,6 +19,13 @@ include::modules/rosa-sdpolicy-am-cluster-self-service.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 
+ifdef::openshift-rosa-hcp[]
+* xref:../../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-red-hat-operator_rosa-hcp-service-definition[Red{nbsp}Hat Operator Support]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+* xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-red-hat-operator_rosa-service-definition[Red{nbsp}Hat Operator Support]
+endif::openshift-rosa-hcp[]
+
 ifdef::openshift-rosa-hcp[]
 * link:https://docs.openshift.com/rosa/rosa_cluster_admin/rosa-configuring-pid-limits.html#rosa-configuring-pid-limits[Configuring PID limits]
 endif::openshift-rosa-hcp[]
@@ -35,9 +42,7 @@ ifdef::openshift-rosa-hcp[]
 * xref:../rosa_policy_service_definition/rosa-hcp-instance-types.adoc#rosa-instance-types[{product-title} instance types].
 endif::openshift-rosa-hcp[]
 ifndef::openshift-rosa-hcp[]
-* xref:../rosa_policy_service_definition/rosa-instance-types.adoc#rosa-instance-types[{product-title} instance types]
-
-* xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and scalability]
+xref:../rosa_policy_service_definition/rosa-instance-types.adoc#rosa-instance-types[{product-title} instance types].
 endif::openshift-rosa-hcp[]
 
 include::modules/rosa-sdpolicy-am-regions-az.adoc[leveloffset=+2]
diff --git a/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc b/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc
index def40f6e3e24..9948eb0dbf18 100644
--- a/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc
+++ b/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc
@@ -29,8 +29,6 @@ include::modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/rosa-sts-about-iam-resources#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
+* For more information about the AWS IAM roles used by the cluster Operators, see xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
 
-* See policies and permissions that the cluster Operators require, link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/rosa-sts-about-iam-resources#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation].
-
-* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/support/approved-access[Approved Access].
+* For more information about the policies and permissions that the cluster Operators require, see xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation].
diff --git a/rosa_cluster_admin/rosa-cluster-autoscaling-hcp.adoc b/rosa_cluster_admin/rosa-cluster-autoscaling-hcp.adoc
new file mode 100644
index 000000000000..ed073456b34f
--- /dev/null
+++ b/rosa_cluster_admin/rosa-cluster-autoscaling-hcp.adoc
@@ -0,0 +1,159 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="rosa-cluster-autoscaling-hcp"]
+= Cluster autoscaling for ROSA HCP 
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: rosa-cluster-autoscaling-hcp
+
+toc::[]
+
+//This is a temporary assembly. Remove when the ROSA HCP docs are published.
+
+Applying autoscaling to {hcp-title-first} clusters involves configuring one or more machine pools with autoscaling. You can use the Cluster Autoscaler to further configure cluster-wide autoscaling that is applicable to all of the machine pools that are autoscaling.
+
+//The includes reference modules that are included in rosa-cluster-autoscaling.adoc. They are conditionalized to reflect the applicable information for ROSA Classic and ROSA HCP. Because this is a temporary assembly, I am putting the content directly here rather that creating three duplicate files that would have to be removed in the near future. 
+
+//include::modules/cluster-autoscaler-about.adoc[leveloffset=+1]
+[id="cluster-autoscaler-about_{context}"]
+== About the cluster autoscaler
+
+The cluster autoscaler adjusts the size of a {hcp-title} cluster to meet its current deployment needs. It uses declarative, Kubernetes-style arguments to provide infrastructure management that does not rely on objects of a specific cloud provider. The cluster autoscaler has a cluster scope, and is not associated with a particular namespace. In {hcp-title}, the Cluster Autoscaler is fully managed, which means it is hosted along with the control plane.
+
+The cluster autoscaler increases the size of the cluster when there are pods that fail to schedule on any of the current worker nodes due to insufficient resources or when another node is necessary to meet deployment needs. The cluster autoscaler does not increase the cluster resources beyond the limits that you specify.
+
+The cluster autoscaler computes the total memory, CPU, and GPU only on the nodes that belong to autoscaling machine pools. All of the machine pool nodes that are not autoscaling are excluded from this aggregation. For example, if you set the `maxNodesTotal` to `50` on a {hcp-title} cluster with three machine pools in which a single machine pool is not autoscaling, the cluster autoscaler restricts the total nodes to `50` in only those two machine pools that are autoscaling. The single manually scaling machine pool can have additional nodes, making the overall cluster nodes total more than `50`.
+
+[discrete]
+[id="cluster-autoscaler-scale-down_{context}"]
+=== Automatic node removal
+
+Every 10 seconds, the cluster autoscaler checks which nodes are unnecessary in the cluster and removes them. The cluster autoscaler considers a node for removal if the following conditions apply:
+
+* The node utilization is less than the _node utilization level_ threshold for the cluster. The node utilization level is the sum of the requested resources divided by the allocated resources for the node. If you do not specify a value in the `ClusterAutoscaler` custom resource, the cluster autoscaler uses a default value of `0.5`, which corresponds to 50% utilization.
+* The cluster autoscaler can move all pods running on the node to the other nodes. The Kubernetes scheduler is responsible for scheduling pods on the nodes.
+* The cluster autoscaler does not have scale down disabled annotation.
+
+If the following types of pods are present on a node, the cluster autoscaler will not remove the node:
+
+* Pods with restrictive pod disruption budgets (PDBs).
+* Kube-system pods that do not run on the node by default.
+* Kube-system pods that do not have a PDB or have a PDB that is too restrictive.
+* Pods that are not backed by a controller object such as a deployment, replica set, or stateful set.
+* Pods with local storage.
+* Pods that cannot be moved elsewhere because of a lack of resources, incompatible node selectors or affinity, matching anti-affinity, and so on.
+* Unless they also have a `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"` annotation, pods that have a `"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"` annotation.
+
+For example, you set the maximum CPU limit to 64 cores and configure the cluster autoscaler to only create machines that have 8 cores each. If your cluster starts with 30 cores, the cluster autoscaler can add up to 4 more nodes with 32 cores, for a total of 62.
+
+[discrete]
+[id="cluster-autoscaler-limitations_{context}"]
+=== Limitations
+
+If you configure the cluster autoscaler, additional usage restrictions apply:
+
+* Do not modify the nodes that are in autoscaled node groups directly. All nodes within the same node group have the same capacity and labels and run the same system pods.
+* Specify requests for your pods.
+* If you have to prevent pods from being deleted too quickly, configure appropriate PDBs.
+* Confirm that your cloud provider quota is large enough to support the maximum node pools that you configure.
+* Do not run additional node group autoscalers, especially the ones offered by your cloud provider.
+
+[NOTE]
+====
+The cluster autoscaler only adds nodes in autoscaled node groups if doing so would result in a schedulable pod.
+If the available node types cannot meet the requirements for a pod request, or if the node groups that could meet these requirements are at their maximum size, the cluster autoscaler cannot scale up.
+====
+
+[discrete]
+[id="cluster-autoscaler-interaction_{context}"]
+=== Interaction with other scheduling features
+
+The horizontal pod autoscaler (HPA) and the cluster autoscaler modify cluster resources in different ways. The HPA changes the deployment's or replica set's number of replicas based on the current CPU load. If the load increases, the HPA creates new replicas, regardless of the amount of resources available to the cluster. If there are not enough resources, the cluster autoscaler adds resources so that the HPA-created pods can run. If the load decreases, the HPA stops some replicas. If this action causes some nodes to be underutilized or completely empty, the cluster autoscaler deletes the unnecessary nodes.
+
+The cluster autoscaler takes pod priorities into account. The Pod Priority and Preemption feature enables scheduling pods based on priorities if the cluster does not have enough resources, but the cluster autoscaler ensures that the cluster has resources to run all pods. To honor the intention of both features, the cluster autoscaler includes a priority cutoff function. You can use this cutoff to schedule "best-effort" pods, which do not cause the cluster autoscaler to increase resources but instead run only when spare resources are available.
+
+Pods with priority lower than the cutoff value do not cause the cluster to scale up or prevent the cluster from scaling down. No new nodes are added to run the pods, and nodes running these pods might be deleted to free resources.
+
+////
+Default priority cutoff is 0. It can be changed using `--expendable-pods-priority-cutoff` flag, but we discourage it. cluster autoscaler also doesn't trigger scale-up if an unschedulable Pod is already waiting for a lower priority Pod preemption.
+////
+
+//::modules/rosa-cluster-autoscaler-cli-edit.adoc[leveloffset=+1]
+[id="rosa-edit-cluster-autoscale-cli_{context}"]
+== Edit autoscaling after cluster creation with the ROSA CLI
+
+You can edit any specific parameters of the cluster autoscaler after creating the autoscaler.
+
+.Procedure
+
+. To edit the cluster autoscaler, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa edit autoscaler -h --cluster=<mycluster>
+----
++
+.. To edit a specific parameter, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa edit autoscaler -h --cluster=<mycluster> <parameter>
+----
+
+//::modules/rosa-cluster-autoscaler-cli-describe.adoc[leveloffset=+1]
+[id="rosa-cluster-autoscaler-cli-describe_{context}"]
+== View autoscaler configurations with the ROSA CLI
+
+You can view your cluster autoscaler configurations using the `rosa describe autoscaler` command.
+
+.Procedure
+
+* To view cluster autoscaler configurations, run the following command:
++
+.Example
+[source,terminal]
+----
+$ rosa describe autoscaler -h --cluster=<mycluster>
+----
+
+//include::modules/rosa-cluster-autoscaler-cli-settings.adoc[leveloffset=+1]
+[id="rosa-cluster-cli-autoscale-parameters_{context}"]
+== Cluster autoscaling parameters using the ROSA CLI
+
+You can add the following parameters to the cluster creation command to configure autoscaler parameters when using the ROSA CLI (`rosa`).
+
+.Configurable autoscaler parameters available with the ROSA CLI (`rosa`)
+
+[cols="4",options="header"]
+|===
+|Setting
+|Description
+|Type or Range
+|Example/Instruction
+
+//Both Classic and HCP
+|`--autoscaler-max-pod-grace-period _int_`
+|Gives pods graceful termination time before scaling down, measured in seconds. Replace _int_ in the command with the number of seconds you want to use.
+|`integer`
+|`--autoscaler-max-pod-grace-period 0`
+
+//Both Classic and HCP
+|`--autoscaler-pod-priority-threshold _int_`
+|The priority that a pod must exceed to cause the cluster autoscaler to deploy additional nodes. Replace _int_ in the command with the number you want to use, can be negative.
+|`integer`
+|`--autoscaler-pod-priority-threshold -10`
+
+//Both Classic and HCP
+|`--autoscaler-max-node-provision-time _string_`
+|Maximum time that the cluster autoscaler waits for a node to be provisioned. Replace _string_ in the command with an integer and time unit (ns,us,µs,ms,s,m,h).
+|`string`
+|`--autoscaler-max-node-provision-time 35m`
+
+//Both Classic and HCP
+|`--autoscaler-max-nodes-total _int_`
+|Maximum amount of nodes in the cluster, including the autoscaled nodes. Replace _int_ in the command with the number you want to use.
+|`integer`
+|`--autoscaler-max-nodes-total 180`
+
+|===
+
diff --git a/rosa_cluster_admin/rosa-cluster-autoscaling.adoc b/rosa_cluster_admin/rosa-cluster-autoscaling.adoc
index da74872700b0..7d754f408c95 100644
--- a/rosa_cluster_admin/rosa-cluster-autoscaling.adoc
+++ b/rosa_cluster_admin/rosa-cluster-autoscaling.adoc
@@ -6,17 +6,30 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 
 toc::[]
 
-Applying autoscaling to {product-title} clusters involves configuring a cluster autoscaler and then configuring a machine autoscaler for at least one machine pool in your cluster.
+//Adding ROSA HCP commands 
 
+ifdef::openshift-rosa[]
+Applying autoscaling to {rosa-classic-first} clusters involves configuring a cluster autoscaler and then configuring a machine autoscaler for at least one machine pool in your cluster.
+endif::openshift-rosa[]
+
+ifdef::openshift-rosa-hcp[]
+Applying autoscaling to {product-title} clusters involves configuring one or more machine pools with autoscaling. You can use the Cluster Autoscaler to further configure cluster-wide autoscaling that is applicable to all of the machine pools that are autoscaling.
+endif::openshift-rosa-hcp[]
+
+//Machine API is not available or applicable in ROSA HCP.
+ifdef::openshift-rosa[]
 [IMPORTANT]
 ====
 You can configure the cluster autoscaler only in clusters where the machine API is operational.
 
 Only one cluster autoscaler can be created per cluster.
 ====
+endif::openshift-rosa[]
 
 include::modules/cluster-autoscaler-about.adoc[leveloffset=+1]
 
+//Need verification if the UI and interactive procedures match for ROSA HCP. Until then, they will only build on ROSA Classic. 
+ifdef::openshift-rosa[]
 include::modules/rosa-cluster-autoscaler-ui-during.adoc[leveloffset=+1]
 
 include::modules/rosa-cluster-autoscaler-ui-after.adoc[leveloffset=+1]
@@ -25,14 +38,19 @@ include::modules/rosa-cluster-autoscaler-ui-settings.adoc[leveloffset=+1]
 
 include::modules/rosa-cluster-autoscaler-cli-interactive-during.adoc[leveloffset=+1]
 
-include::modules/rosa-cluster-autoscaler-cli-interactive-after.adoc[leveloffset=+2]
+include::modules/rosa-cluster-autoscaler-cli-interactive-after.adoc[leveloffset=+1]
 
 include::modules/rosa-cluster-autoscaler-cli-during.adoc[leveloffset=+1]
 
-include::modules/rosa-cluster-autoscaler-cli-after.adoc[leveloffset=+2]
+include::modules/rosa-cluster-autoscaler-cli-after.adoc[leveloffset=+1]
+endif::openshift-rosa[]
+
+include::modules/rosa-cluster-autoscaler-cli-edit.adoc[leveloffset=+1]
 
-include::modules/rosa-cluster-autoscaler-cli-edit.adoc[leveloffset=+2]
+include::modules/rosa-cluster-autoscaler-cli-describe.adoc[leveloffset=+1]
 
-include::modules/rosa-cluster-autoscaler-cli-delete.adoc[leveloffset=+2]
+ifdef::openshift-rosa[]
+include::modules/rosa-cluster-autoscaler-cli-delete.adoc[leveloffset=+1]
+endif::openshift-rosa[]
 
 include::modules/rosa-cluster-autoscaler-cli-settings.adoc[leveloffset=+1]
diff --git a/rosa_cluster_admin/rosa-cluster-notifications.adoc b/rosa_cluster_admin/rosa-cluster-notifications.adoc
index fe2dbde3f948..03a45d9b4716 100644
--- a/rosa_cluster_admin/rosa-cluster-notifications.adoc
+++ b/rosa_cluster_admin/rosa-cluster-notifications.adoc
@@ -12,6 +12,10 @@ ifdef::openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 == Additional resources
 // TODO: Add this xref to ARO HCP.
+// TODO OSDOCS-11789: Confirm plan for responsibility matrix for HCP
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#notifications_rosa-policy-responsibility-matrix[Customer responsibilities: Review and action cluster notifications]
+endif::openshift-rosa-hcp[]
 ifndef::openshift-rosa-hcp[]
 * xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#notifications_rosa-policy-responsibility-matrix[Customer responsibilities: Review and action cluster notifications]
 endif::openshift-rosa-hcp[]
@@ -56,5 +60,11 @@ include::modules/managed-cluster-remove-notification-contacts.adoc[leveloffset=+
 * Ensure that your cluster can access resources at `api.openshift.com`.
 // TODO: Include this xref once all of the files have been added to the ROSA HCP distro.
 ifndef::openshift-rosa-hcp[]
-* Ensure that your firewall is configured according to the documented prerequisites: xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
-endif::openshift-rosa-hcp[]
+* Ensure that your firewall is configured according to the documented prerequisites:
+ifdef::openshift-rosa[]
+** xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for ROSA (classic architecture) clusters using STS]
+endif::openshift-rosa[]
+ifdef::openshift-dedicated[]
+** xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites]
+endif::openshift-dedicated[]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc b/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc
index 4e12882e8fb1..04d9618493f7 100644
--- a/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc
+++ b/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc
@@ -11,10 +11,12 @@ For {hcp-title-first} workloads that do not require public internet access, you
 //include::modules/osd-aws-privatelink-about.adoc[leveloffset=+1]
 //include::modules/osd-aws-privatelink-required-resources.adoc[leveloffset=+1]
 include::modules/rosa-hcp-aws-private-create-cluster.adoc[leveloffset=+1]
+include::modules/rosa-hcp-aws-private-security-groups.adoc[leveloffset=+1]
 include::modules/rosa-additional-principals-overview.adoc[leveloffset=+1]
 include::modules/rosa-additional-principals-create.adoc[leveloffset=+2]
 include::modules/rosa-additional-principals-edit.adoc[leveloffset=+2]
 
+//unclear on why this is here given this is a HCP assembly
 ifndef::openshift-rosa-hcp[]
 [id="next-steps_rosa-hcp-aws-private-creating-cluster"]
 == Next steps
@@ -25,9 +27,8 @@ xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.a
 == Additional resources
 
 * xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs[AWS PrivateLink firewall prerequisites]
-//* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS PrivateLink firewall prerequisites]
 * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-overview-of-the-deployment-workflow[Overview of the ROSA with STS deployment workflow]
 * xref:../rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc#rosa-sts-deleting-cluster[Deleting a ROSA cluster]
 * xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture models]
-* xref:../support/troubleshooting/rosa-troubleshooting-installations.adoc#rosa-troubleshooting-installing[Troubleshooting Red{nbsp}Hat OpenShift Service on AWS installations]
+* xref:../support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc#rosa-troubleshooting-installations-hcp[Troubleshooting ROSA with HCP cluster installations]
 endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/rosa_hcp/rosa-hcp-creating-cluster-with-aws-kms-key.adoc b/rosa_hcp/rosa-hcp-creating-cluster-with-aws-kms-key.adoc
index 01325c4d14ae..e04f39e5a2db 100644
--- a/rosa_hcp/rosa-hcp-creating-cluster-with-aws-kms-key.adoc
+++ b/rosa_hcp/rosa-hcp-creating-cluster-with-aws-kms-key.adoc
@@ -81,6 +81,6 @@ ifndef::openshift-rosa-hcp[]
 * For information about the prerequisites to installing ROSA with STS, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[AWS prerequisites for ROSA with STS].
 * For details about using the `auto` and `manual` modes to create the required STS resources, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-understanding-deployment-modes_rosa-sts-creating-a-cluster-with-customizations[Understanding the auto and manual deployment modes].
 * For more information about using OpenID Connect (OIDC) identity providers in AWS IAM, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html[Creating OpenID Connect (OIDC) identity providers].
-* For more information about troubleshooting ROSA cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations.adoc#rosa-troubleshooting-installations[Troubleshooting installations].
+* For more information about troubleshooting ROSA cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc#rosa-troubleshooting-installations-hcp[Troubleshooting ROSA with HCP cluster installations].
 * For steps to contact Red{nbsp}Hat Support for assistance, see xref:../support/getting-support.adoc#getting-support[Getting support for Red{nbsp}Hat OpenShift Service on AWS].
 endif::openshift-rosa-hcp[]
diff --git a/rosa_hcp/rosa-hcp-deleting-cluster.adoc b/rosa_hcp/rosa-hcp-deleting-cluster.adoc
index 80ea903d2744..21a91e595cb7 100644
--- a/rosa_hcp/rosa-hcp-deleting-cluster.adoc
+++ b/rosa_hcp/rosa-hcp-deleting-cluster.adoc
@@ -11,23 +11,25 @@ If you want to delete a {hcp-title-first} cluster, you can use either the {clust
 include::modules/rosa-hcp-deleting-cluster.adoc[leveloffset=+1]
 
 .Troubleshooting
+ifdef::openshift-rosa[]
 * If the cluster cannot be deleted because of missing IAM roles, see xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-cluster-deletion_rosa-troubleshooting-cluster-deployments[Repairing a cluster that cannot be deleted].
-* If the cluster cannot be deleted for other reasons:
-** Ensure that there are no add-ons for your cluster pending in the link:https://console.redhat.com/openshift[Hybrid Cloud Console].
-** Ensure that all AWS resources and dependencies have been deleted in the Amazon Web Console.
+endif::openshift-rosa[]
+* Ensure that there are no add-ons for your cluster pending in the link:https://console.redhat.com/openshift[Hybrid Cloud Console].
+* Ensure that all AWS resources and dependencies have been deleted in the Amazon Web Console.
 
 include::modules/rosa-deleting-sts-iam-resources-account-wide.adoc[leveloffset=+1]
 
+ifdef::openshift-rosa[]
 [role="_additional-resources"]
 .Additional resources
-
 * xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-cluster-deletion_rosa-troubleshooting-cluster-deployments[Repairing a cluster that cannot be deleted]
+endif::openshift-rosa[]
 
 include::modules/rosa-deleting-account-wide-iam-roles-and-policies.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS]
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources]
 
 include::modules/rosa-unlinking-and-deleting-ocm-and-user-iam-roles.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/rosa_hcp/rosa-hcp-egress-lockdown-install.adoc b/rosa_hcp/rosa-hcp-egress-lockdown-install.adoc
index 551cdba189b8..3b7d76a58c71 100644
--- a/rosa_hcp/rosa-hcp-egress-lockdown-install.adoc
+++ b/rosa_hcp/rosa-hcp-egress-lockdown-install.adoc
@@ -6,7 +6,31 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 toc::[]
 
 
-Creating a {product-title} cluster with egress lockdown provides a way to enhance your cluster's stability and security by allowing your cluster to use the image registry in the local region if the cluster cannot access the Internet. Your cluster will try to pull the images from Quay, but when they aren't reached, it will instead pull the images from the image registry in the local region. All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
+Creating a {product-title} cluster with egress lockdown provides a way to enhance your cluster's stability and security by allowing your cluster to use the image registry in the local region if the cluster cannot access the Internet. Your cluster will try to pull the images from Quay, but when they aren't reached, it will instead pull the images from the image registry in the local region. 
+
+[IMPORTANT]
+====
+You can only use egress lockdown on clusters that use the following AWS regions:
+
+* `us-west-2`
+* `us-east-1` 
+* `us-east-2`
+* `ap-northeast-1`
+* `ap-northeast-2`
+* `ap-northeast-3`
+* `ap-south-1`
+* `ap-southeast-1`
+* `ap-southeast-2`
+* `ca-central-1`
+* `eu-central-1`
+* `eu-north-1`
+* `eu-west-1`
+* `eu-west-2`
+* `eu-west-3`
+* `sa-east-1`
+====
+
+All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
 
 :FeatureName: Egress lockdown
 include::snippets/technology-preview.adoc[]
@@ -36,7 +60,7 @@ You must have a Virtual Private Cloud (VPC) to create {hcp-title} clusters. You
 
 [NOTE]
 ====
-The Terraform instructions are for testing and demonstration purposes. Your own installation requires modifications to the VPC for your specific needs and constraints. You should also ensure that when you use the following Terraform script it is in the same region that you intend to install your cluster. In the following examples, use `us-east-2`.
+The Terraform instructions are for testing and demonstration purposes. Your own installation requires modifications to the VPC for your specific needs and constraints. You should also ensure that when you use the following Terraform script it is in the same region that you intend to install your cluster.
 ====
 
 include::modules/rosa-hcp-vpc-terraform.adoc[leveloffset=+2]
diff --git a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.adoc b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.adoc
index 79adb467f57b..cbcf3326d1f1 100644
--- a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.adoc
+++ b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.adoc
@@ -83,5 +83,5 @@ include::modules/rosa-hcp-sts-creating-a-cluster-external-auth-provider-delete-c
 * For information about the prerequisites to installing ROSA with STS, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[AWS prerequisites for ROSA with STS].
 * For details about using the `auto` and `manual` modes to create the required STS resources, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-understanding-deployment-modes_rosa-sts-creating-a-cluster-with-customizations[Understanding the auto and manual deployment modes].
 * For more information about using OpenID Connect (OIDC) identity providers in AWS IAM, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html[Creating OpenID Connect (OIDC) identity providers] in the AWS documentation.
-* For more information about troubleshooting ROSA cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations.adoc#rosa-troubleshooting-installations[Troubleshooting installations].
+* For more information about troubleshooting ROSA cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc#rosa-troubleshooting-installations-hcp[Troubleshooting ROSA with HCP cluster installations].
 * For steps to contact Red{nbsp}Hat Support for assistance, see xref:../support/getting-support.adoc#getting-support[Getting support for Red{nbsp}Hat OpenShift Service on AWS].
\ No newline at end of file
diff --git a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc
index ff12e72e0091..2abbd4d0214c 100644
--- a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc
+++ b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc
@@ -57,6 +57,7 @@ endif::openshift-rosa-hcp[]
 
 include::modules/rosa-sts-overview-of-the-default-cluster-specifications.adoc[leveloffset=+1]
 
+//TODO OSDOCS-11789: Move these out of the deployment doc and into the prepare doc? Keep in both locations?
 [id="rosa-hcp-prereqs"]
 == {hcp-title} Prerequisites
 
@@ -136,6 +137,6 @@ ifndef::openshift-rosa-hcp[]
 * For information about the prerequisites to installing ROSA with STS, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[AWS prerequisites for ROSA with STS].
 * For details about using the `auto` and `manual` modes to create the required STS resources, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-understanding-deployment-modes_rosa-sts-creating-a-cluster-with-customizations[Understanding the auto and manual deployment modes].
 * For more information about using OpenID Connect (OIDC) identity providers in AWS IAM, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html[Creating OpenID Connect (OIDC) identity providers] in the AWS documentation.
-* For more information about troubleshooting ROSA cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations.adoc#rosa-troubleshooting-installations[Troubleshooting installations].
+* For more information about troubleshooting {hcp-title} cluster installations, see xref:../support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc#rosa-troubleshooting-installations-hcp[Troubleshooting ROSA with HCP installations].
 * For steps to contact Red{nbsp}Hat Support for assistance, see xref:../support/getting-support.adoc#getting-support[Getting support for Red{nbsp}Hat OpenShift Service on AWS].
 endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc b/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc
index cdef8239c260..9c13a6054fa7 100644
--- a/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc
+++ b/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc
@@ -20,7 +20,15 @@ include::modules/osd-aws-privatelink-config-dns-forwarding.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS PrivateLink firewall prerequisites]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for {hcp-title}]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites for ROSA (classic architecture) clusters using STS]
+endif::openshift-rosa[]
+ifdef::openshift-dedicated[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[Firewall prerequisites]
+endif::openshift-dedicated[]
 * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-overview-of-the-deployment-workflow[Overview of the ROSA with STS deployment workflow]
 * xref:../rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc#rosa-sts-deleting-cluster[Deleting a ROSA cluster]
 * xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture models]
diff --git a/rosa_install_access_delete_clusters/rosa-shared-vpc-config.adoc b/rosa_install_access_delete_clusters/rosa-shared-vpc-config.adoc
index a101f0560f62..ac35a7fe7cf6 100644
--- a/rosa_install_access_delete_clusters/rosa-shared-vpc-config.adoc
+++ b/rosa_install_access_delete_clusters/rosa-shared-vpc-config.adoc
@@ -31,7 +31,14 @@ image::372_OpenShift_on_AWS_persona_worflows_0923_all.png[]
 
 .Prerequisites for the *Cluster Creator*
 * You installed the link:https://console.redhat.com/openshift/downloads#tool-rosa[ROSA CLI (`rosa`)] 1.2.26 or later.
-* You created all of the required xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[ROSA account roles] for creating a cluster.
+* You created all of the required
+ifdef::openshift-rosa[]
+xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[account-wide roles and policies]
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-hcp-sts-creating-a-cluster-quickly[account-wide roles and policies]
+endif::openshift-rosa-hcp[]
+for creating a cluster.
 * The *Cluster Creator's* AWS account is separate from the *VPC Owner's* AWS account.
 * Both AWS accounts belong to the same AWS organization.
 
diff --git a/rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc b/rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc
index 477554d4d429..54ca0e5ab06f 100644
--- a/rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc
+++ b/rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc
@@ -41,5 +41,5 @@ include::modules/rosa-unlinking-and-deleting-ocm-and-user-iam-roles.adoc[levelof
 == Additional resources
 
 * For information about the cluster delete protection feature, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-edit-objects_rosa-managing-objects-cli[Edit objects].
-* For information about the AWS IAM resources for ROSA clusters that use STS, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS].
+* For information about the AWS IAM resources for ROSA clusters that use STS, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources].
 * For information on cluster errors that are due to missing IAM roles, see xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-cluster-deletion_rosa-troubleshooting-cluster-deployments[Repairing a cluster that cannot be deleted].
diff --git a/rosa_planning/rosa-cloud-expert-prereq-checklist.adoc b/rosa_planning/rosa-cloud-expert-prereq-checklist.adoc
index 69cc09436b42..cc02c23890aa 100644
--- a/rosa_planning/rosa-cloud-expert-prereq-checklist.adoc
+++ b/rosa_planning/rosa-cloud-expert-prereq-checklist.adoc
@@ -2,7 +2,12 @@
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: rosa-cloud-expert-prereq-checklist
 [id="rosa-cloud-expert-prereq-checklist"]
+ifndef::openshift-rosa-hcp[]
 = Prerequisites checklist for deploying ROSA using STS
+endif::[]
+ifdef::openshift-rosa-hcp[]
+= Prerequisites checklist for deploying ROSA with HCP
+endif::openshift-rosa-hcp[]
 
 toc::[]
 
@@ -18,147 +23,145 @@ toc::[]
 //  - Diana Sari
 //---
 
-This is a checklist of prerequisites needed to create a {product-title} (ROSA) classic cluster with link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[STS].
+This is a high level checklist of prerequisites needed to create a
+ifdef::openshift-rosa[]
+{rosa-classic-first} cluster with link:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[STS].
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+{hcp-title-first} cluster.
+endif::openshift-rosa-hcp[]
 
-[NOTE]
-====
-This is a high level checklist and your implementation can vary.
-====
+//TODO OSDOCS-11789: Consider adding the following to a subsection about the initiating/control machine, along with CLI sections?
+The machine that you run the installation process from must have access to the following:
 
-Before running the installation process, verify that you deploy this from a machine that has access to:
-
-* The API services for the cloud to which you provision.
-* Access to `api.openshift.com`, `oidc.op1.openshiftapps.com`, and `sso.redhat.com`.
-* The hosts on the network that you provision.
-* The internet to obtain installation media.
+* Amazon Web Services API and authentication service endpoints
+* Red Hat OpenShift API and authentication service endpoints (`api.openshift.com` and `sso.redhat.com`)
+* Internet connectivity to obtain installation artifacts
 
+//TODO OSDOCS-11789: This needs to be accessible from parts of the cluster, but not the deploying machine - omit entirely, or leave in place for Classic?
+ifdef::openshift-rosa[]
 [IMPORTANT]
 ====
 Starting with version 1.2.7 of the ROSA CLI, all OIDC provider endpoint URLs on new clusters use Amazon CloudFront and the link:http://oidc.op1.openshiftapps.com/[oidc.op1.openshiftapps.com] domain. This change improves access speed, reduces latency, and improves resiliency for new clusters created with the ROSA CLI 1.2.7 or later. There are no supported migration paths for existing OIDC provider configurations.
 ====
+endif::openshift-rosa[]
 
-== Accounts and CLIs Prerequisites
+//TODO OSDOCS-11789: Consider combining with other account and permission needs to avoid duplication of headers? This does need to happen to download the CLIs though.
+== Accounts and permissions
 
-Accounts and CLIs you must install to deploy the cluster.
+Ensure that you have the following accounts, credentials, and permissions.
 
 === AWS account
 
-* Gather the following details:
-** AWS IAM User
-** AWS Access Key ID
-** AWS Secret Access Key
-* Ensure that you have the right permissions as detailed link:https://docs.aws.amazon.com/ROSA/latest/userguide/security-iam-awsmanpol.html[AWS managed IAM policies for ROSA] and xref:../rosa_architecture/rosa-sts-about-iam-resources.html[About IAM resources for ROSA clusters that use STS].
-* See xref:../rosa_planning/rosa-sts-aws-prereqs.html#rosa-account_rosa-sts-aws-prereqs[Account] for more details.
-* See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-associating-your-aws-account_rosa-sts-creating-a-cluster-quickly[Associating your AWS account with your Red Hat organization] for intructions on associating your account. 
+* Create an AWS account if you do not already have one.
+* Gather the credentials required to log in to your AWS account.
+* Ensure that your AWS account has sufficient permissions to use the ROSA CLI: xref:../cli_reference/rosa_cli/rosa-cli-permission-examples.adoc#rosa-cli-permission-examples[Least privilege permissions for common ROSA CLI commands]
+//OSDOCS-11789: Moving these here because it is a permission / account level enablement
+* Enable ROSA for your AWS account on the link:https://console.aws.amazon.com/rosa/[AWS console].
+** If your account is the management account for your organization (used for AWS billing purposes), you must have `aws-marketplace:Subscribe` permissions available on your account. See _Service control policy (SCP) prerequisites_ for more information, or see the AWS documentation for troubleshooting: link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-troubleshoot.html#error-aws-orgs-scp-denies-permissions[AWS Organizations service control policy denies required AWS Marketplace permissions].
+
+=== Red{nbsp}Hat account
+
+//TODO OSDOCS-11789: Do we need to mention RH Organization here also?
+* Create a Red Hat account for the link:https://console.redhat.com/[{hybrid-console}] if you do not already have one.
+* Gather the credentials required to log in to your Red Hat account.
+
+== CLI requirements
+
+You need to download and install several CLI (command line interface) tools to be able to deploy a cluster.
 
 === AWS CLI (`aws`)
 
-* Install from link:https://aws.amazon.com/cli/[AWS Command Line Interface] if you have not already.
-* Configure the CLI:
-+
-. Enter `aws configure` in the terminal:
-+
-[source,terminal]
-----
-$ aws configure
-----
-+
-. Enter the AWS Access Key ID and press *enter*.
-. Enter the AWS Secret Access Key and press *enter*.
-. Enter the default region you want to deploy into.
-. Enter the output format you want, “table” or “json”.
-. Verify the output by running:
+. Install the link:https://aws.amazon.com/cli/[AWS Command Line Interface].
+. Log in to your AWS account using the AWS CLI: link:https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html[Sign in through the AWS CLI]
+. Verify your account identity:
 +
 [source,terminal]
 ----
  $ aws sts get-caller-identity
 ----
-+
-. Ensure that the service role for ELB already exists by running:
+. Check whether the service role for ELB (Elastic Load Balancing) exists:
 +
 [source,terminal]
 ----
 $ aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"
 ----
 +
-.. If it does not exist, run:
+If the role does not exist, create it by running the following command:
 +
 [source,terminal]
 ----
 $ aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
 ----
 
-=== Red{nbsp}Hat account
-
-* Create a link:https://console.redhat.com/[{hybrid-console}]  account if you have not already.
-
 === ROSA CLI (`rosa`)
 
-. Enable ROSA from your AWS account on the link:https://console.aws.amazon.com/rosa/[AWS console] if you have not already.
-. Install the CLI from xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-installing-rosa.html[Installing the Red{nbsp}Hat OpenShift Service on AWS (ROSA) CLI, rosa] or from the OpenShift console link:https://console.redhat.com/openshift/downloads#tool-rosa[AWS console].
-. Enter `rosa login` in a terminal, and this will prompt you to go to the link:https://console.redhat.com/openshift/token/rosa[token page] through the console:
+. Install the ROSA CLI from the link:https://console.redhat.com/openshift/downloads#tool-rosa[web console].
+ifdef::openshift-rosa[]
+See xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-installing-rosa.adoc[Installing the Red{nbsp}Hat OpenShift Service on AWS (ROSA) CLI, rosa] for detailed instructions.
+endif::openshift-rosa[]
+. Log in to your Red Hat account by running `rosa login` and following the instructions in the command output:
 +
 [source,terminal]
 ----
 $ rosa login
+To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
+? Copy the token and paste it here: 
 ----
 +
-. Log in with your Red{nbsp}Hat account credentials.
-. Click the *Load token* button.
-. Copy the token and paste it back into the CLI prompt and press *enter*.
-+
-* Alternatively, you can copy the full `$ rosa login --token=abc...` command and paste that in the terminal:
+Alternatively, you can copy the full `$ rosa login --token=abc...` command and paste that in the terminal:
 +
 [source,terminal]
 ----
 $ rosa login --token=<abc..>
 ----
-+
-. Verify your credentials by running:
+. Confirm you are logged in using the correct account and credentials:
 +
 [source,terminal]
 ----
 $ rosa whoami
 ----
-+
-. Ensure you have sufficient quota by running:
-+
-[source,terminal]
-----
-$ rosa verify quota
-----
-+
-* See xref:../rosa_planning/rosa-sts-aws-prereqs.html#rosa-aws-policy-provisioned_rosa-sts-aws-prereqs[Provisioned AWS Infrastructure] for more details on AWS services provisioned for ROSA cluster.
-* See xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Required AWS service quotas] for more details on AWS services quota.
-
 
 === OpenShift CLI (`oc`)
 
-. Install from xref:../cli_reference/openshift_cli/getting-started-cli.adoc#cli-getting-started[Getting started with the OpenShift CLI] or from the OpenShift console link:https://console.redhat.com/openshift/downloads#tool-oc[Command-line interface (CLI) tools].
-. Verify that the OpenShift CLI has been installed correctly by running:
+The OpenShift CLI (`oc`) is not required to deploy a {product-title} cluster, but is a useful tool for interacting with your cluster after it is deployed.
+
+. Download and install`oc` from the {cluster-manager} link:https://console.redhat.com/openshift/downloads#tool-oc[Command-line interface (CLI) tools] page, or follow the instructions in xref:../cli_reference/openshift_cli/getting-started-cli.adoc#cli-getting-started[Getting started with the OpenShift CLI].
+. Verify that the OpenShift CLI has been installed correctly by running the following command:
 +
 [source,terminal]
 ----
 $ rosa verify openshift-client
 ----
 
-Once you have the above prerequisites installed and enabled, proceed to the next steps.
-
-//This content is pulled from rosa-sts-associating-your-aws-account.adoc
-include::modules/rosa-sts-associating-your-aws-account.adoc[leveloffset=+2]
+//TODO OSDOCS-11789: Moved quota check to the point where it is actually useful - yes, this is checked during install, but it's also worth checking ahead of time so that any issues are known during preparation rather than deployment.
+== AWS infrastructure prerequisites
 
+* Optionally, ensure that your AWS account has sufficient quota available to deploy a cluster.
++
+[source,terminal]
+----
+$ rosa verify quota
+----
++
+This command only checks the total quota allocated to your account; it does not reflect the amount of quota already consumed from that quota. Running this command is optional because your quota is verified during cluster deployment. However, Red Hat recommends running this command to confirm your quota ahead of time so that deployment is not interrupted by issues with quota availability.
+ifdef::openshift-rosa[]
+* For more information about resources provisioned during ROSA cluster deployment, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-aws-policy-provisioned_rosa-sts-aws-prereqs[Provisioned AWS Infrastructure].
+* For more information about the required AWS service quotas, see xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Required AWS service quotas].
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* For more information about resources provisioned during ROSA cluster deployment, see xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-aws-policy-provisioned_rosa-hcp-prereqs[Provisioned AWS Infrastructure].
+* For more information about the required AWS service quotas, see xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Required AWS service quotas].
+endif::openshift-rosa-hcp[]
 
-== SCP Prerequisites
+== Service Control Policy (SCP) prerequisites
 
 ROSA clusters are hosted in an AWS account within an AWS organizational unit. A link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html[service control policy (SCP)] is created and applied to the AWS organizational unit that manages what services the AWS sub-accounts are permitted to access.
 
-* Ensure that your organization's SCPs are not more restrictive than the roles and policies required by the cluster.
-* Ensure that your SCP is configured to allow the required `aws-marketplace:Subscribe` permission when you choose *Enable ROSA* from the console, and see link:https://docs.aws.amazon.com/ROSA/latest/userguide/troubleshoot-rosa-enablement.html#error-aws-orgs-scp-denies-permissions[AWS Organizations service control policy (SCP) is denying required AWS Marketplace permissions] for more details.
-* When you create a ROSA classic cluster, an associated AWS OpenID Connect (OIDC) identity provider is created.
-** This OIDC provider configuration relies on a public key that is located in the `us-east-1` AWS region.
-** Customers with AWS SCPs must allow the use of the `us-east-1` AWS region, even if these clusters are deployed in a different region.
+* Ensure that your organization's SCPs are not more restrictive than the roles and policies required by the cluster. For more information, see the xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-minimum-scp_rosa-sts-about-iam-resources[Minimum set of effective permissions for SCPs].
+* When you create a ROSA cluster, an associated AWS OpenID Connect (OIDC) identity provider is created.
 
-== Networking Prerequisites
+== Networking prerequisites
 
 Prerequisites needed from a networking standpoint.
 
@@ -166,31 +169,18 @@ include::modules/mos-network-prereqs-min-bandwidth.adoc[leveloffset=+2]
 
 === Firewall
 
-* Configure your firewall to allow access to the domains and ports listed in xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites].
+//TODO OSDOCS-11789: Are these things that your cluster needs access to, or your deploying machine needs access to?
+* Configure your firewall to allow access to the domains and ports listed in
+ifdef::openshift-rosa[]
+xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites].
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-hcp-prereqs[AWS firewall prerequisites]
+endif::openshift-rosa-hcp[]
 
-=== Additional custom security groups
-
-When you create a cluster using an existing non-managed VPC, you can add additional custom security groups during cluster creation. Complete these prerequisites before you create the cluster:
-
-* Create the custom security groups in AWS before you create the cluster.
-* Associate the custom security groups with the VPC that you are using to create the cluster. Do not associate the custom security groups with any other VPC.
-* You may need to request additional AWS quota for `Security groups per network interface`.
-
-For more details see the detailed requirements for xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc#rosa-security-groups_prerequisites[Security groups].
-
-=== Custom DNS
-
-* If you want to use custom DNS, then the ROSA installer must be able to use VPC DNS with default DHCP options so it can resolve hosts locally.
-** To do so, run `aws ec2 describe-dhcp-options` and see if the VPC is using VPC Resolver:
-+
-[source,terminal]
-----
-$ aws ec2 describe-dhcp-options
-----
-+
-* Otherwise, the upstream DNS will need to forward the cluster scope to this VPC so the cluster can resolve internal IPs and services.
-
-== PrivateLink Prerequisites
+//Moving up prereqs that are actually required for deployment
+ifdef::openshift-rosa[]
+== VPC requirements for PrivateLink clusters
 
 If you choose to deploy a PrivateLink cluster, then be sure to deploy the cluster in the pre-existing BYO VPC:
 
@@ -216,3 +206,49 @@ xref:../networking/configuring-cluster-wide-proxy.adoc#configuring-cluster-wide-
 ====
 You can install a non-PrivateLink ROSA cluster in a pre-existing BYO VPC.
 ====
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+=== Create VPC before cluster deployment
+
+{hcp-title} clusters must be deployed into an existing Virtual Private Cloud (VPC).
+
+include::snippets/rosa-existing-vpc-requirements.adoc[leveloffset=+0]
+
+//TODO OSDOCS-11789: Does the following section need to be moved into this document only?
+// Is it reasonable to include it in preparation and in deployment process?
+// https://docs.openshift.com/rosa/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.html#rosa-hcp-prereqs
+
+//TODO OSDOCS-11789: We also link out into https://docs.openshift.com/container-platform/4.17/installing/installing_aws/ipi/installing-aws-vpc.html#installation-custom-aws-vpc_installing-aws-vpc for more information about what your VPC should be able to handle, but this needs review to omit OCP-only content if we're going to use it.
+endif::openshift-rosa-hcp[]
+
+=== Additional custom security groups
+
+During cluster creation, you can add additional custom security groups to a cluster that has an existing non-managed VPC. To do so, complete these prerequisites before you create the cluster:
+
+* Create the custom security groups in AWS before you create the cluster.
+* Associate the custom security groups with the VPC that you are using to create the cluster. Do not associate the custom security groups with any other VPC.
+* You may need to request additional AWS quota for `Security groups per network interface`.
+
+ifdef::openshift-rosa[]
+For more details see the detailed requirements for xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc#rosa-security-groups_prerequisites[Security groups].
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+For more details see the detailed requirements for xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-security-groups_rosa-hcp-prereqs[Security groups].
+endif::openshift-rosa-hcp[]
+
+=== Custom DNS and domains
+
+You can configure a custom domain name server and custom domain name for your cluster. To do so, complete the following prerequisites before you create the cluster:
+
+//TODO OSDOCS-11789: Needs verification from mmcneill
+* By default, ROSA clusters require you to set the `domain name servers` option to `AmazonProvidedDNS` to ensure successful cluster creation and operation.
+* To use a custom DNS server and domain name for your cluster, the ROSA installer must be able to use VPC DNS with default DHCP options so that it can resolve internal IPs and services. This means that you must create a custom DHCP option set to forward DNS lookups to your DNS server, and associate this option set with your VPC before you create the cluster.
+ifdef::openshift-rosa[]
+For more information, see xref:../cloud_experts_tutorials/cloud-experts-custom-dns-resolver.adoc#cloud-experts-custom-dns-resolver[Deploying ROSA with a custom DNS resolver].
+endif::openshift-rosa[]
+* Confirm that your VPC is using VPC Resolver by running the following command:
++
+[source,terminal]
+----
+$ aws ec2 describe-dhcp-options
+----
\ No newline at end of file
diff --git a/rosa_planning/rosa-hcp-iam-resources.adoc b/rosa_planning/rosa-hcp-iam-resources.adoc
new file mode 120000
index 000000000000..48658d4aa84e
--- /dev/null
+++ b/rosa_planning/rosa-hcp-iam-resources.adoc
@@ -0,0 +1 @@
+../rosa_architecture/rosa-sts-about-iam-resources.adoc
\ No newline at end of file
diff --git a/rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc b/rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc
new file mode 100644
index 000000000000..4bfab7c057d5
--- /dev/null
+++ b/rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc
@@ -0,0 +1,53 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="rosa-hcp-prepare-iam-roles-resources"]
+= Required IAM roles and resources
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: prepare-role-resources
+
+toc::[]
+
+You must create several role resources on your AWS account in order to create and manage a {product-title} (ROSA) cluster.
+
+include::modules/rosa-prereq-roles-overview.adoc[leveloffset=+1]
+
+[id="rosa-prepare-am-resources-roles-account"]
+== Roles required to create and manage clusters
+
+Several account-wide roles (`account-roles` in the ROSA CLI) are required to create or manage ROSA clusters. These roles must be created using the ROSA CLI (`rosa`), regardless of whether you typically use {cluster-manager} or the ROSA CLI to create and manage your clusters. These roles only need to be created once, and do not need to be created for every cluster you install.
+
+//account roles
+include::modules/rosa-hcp-creating-account-wide-sts-roles-and-policies.adoc[leveloffset=+2]
+
+[id="rosa-prepare-am-resources-roles-operator"]
+== Roles required to manage Operator features
+//operator roles
+//created per-cluster or per-OIDC provider if that is shared between clusters
+Cluster-specific Operator roles (`operator-roles` in the ROSA CLI) obtain the temporary permissions required to perform cluster operations that are provided by Operators, such as managing back-end storage, ingress, and registry. These roles are required for every cluster, as several Operators are used to provide cluster features by default.
+
+[id="rosa-prepare-iam-resources-oidc"]
+=== Required OIDC authentication resources
+
+{product-title} clusters use OIDC and the AWS Security Token Service (STS) to authenticate Operator access to AWS resources they require to perform their functions. Each production cluster requires its own OIDC configuration.
+
+include::modules/rosa-sts-byo-oidc.adoc[leveloffset=+3]
+
+include::modules/rosa-sts-operator-roles.adoc[leveloffset=+2]
+
+[id="rosa-prepare-iam-resources-roles-ocm"]
+== Roles required to use {cluster-manager}
+
+The roles in this section are only required when you want to use {cluster-manager} to create and manage clusters. If you intend to create and manage clusters using only the ROSA CLI (`rosa`) and the OpenShift CLI (`oc`), these roles are not required.
+
+include::modules/rosa-sts-ocm-role-creation.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_ocm-role-creation_{context}"]
+.Additional resources
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
+
+include::modules/rosa-sts-user-role-creation.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_user-role-creation_{context}"]
+.Additional resources
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
\ No newline at end of file
diff --git a/rosa_planning/rosa-hcp-prereqs.adoc b/rosa_planning/rosa-hcp-prereqs.adoc
deleted file mode 100644
index 2f865dd32728..000000000000
--- a/rosa_planning/rosa-hcp-prereqs.adoc
+++ /dev/null
@@ -1,86 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-include::_attributes/attributes-openshift-dedicated.adoc[]
-:context: rosa-hcp-aws-prereqs
-[id="rosa-hcp-prereqs"]
-= AWS prerequisites for {hcp-title}
-
-toc::[]
-
-{hcp-title-first} provides a model that Red Hat hosts the control plane and uses your AWS account to deploy clusters.
-
-Ensure that the following AWS prerequisites are met before installing ROSA with STS.
-
-[IMPORTANT]
-====
-When you create a ROSA cluster using AWS STS, an associated AWS OpenID Connect (OIDC) identity provider is created as well. This OIDC provider configuration relies on a public key that is located in the `us-east-1` AWS region. Customers with AWS SCPs must allow the use of the `us-east-1` AWS region, even if these clusters are deployed in a different region.
-====
-
-[id="rosa-sts-customer-requirements_{context}"]
-== Customer requirements when using STS for deployment
-
-The following prerequisites must be complete before you deploy a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS).
-
-include::modules/rosa-sts-aws-requirements-account.adoc[leveloffset=+2]
-[role="_additional-resources"]
-[id="additional-resources_aws-account-requirements_{context}"]
-.Additional resources
-* xref:../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and scalability]
-* xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-elb-service-role_rosa-troubleshooting-cluster-deployments[Creating the Elastic Load Balancing (ELB) service-linked role]
-
-include::modules/rosa-sts-aws-requirements-access-req.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-[id="additional-resources_aws-access-requirements_{context}"]
-.Additional resources
-* See xref:../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-applications-config-custom-domains[Configuring custom domains for applications]
-
-include::modules/rosa-sts-aws-requirements-support-req.adoc[leveloffset=+2]
-include::modules/rosa-sts-aws-requirements-security-req.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-[id="additional-resources_aws-security-requirements_{context}"]
-.Additional resources
-* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
-
-[role="_additional-resources"]
-.Additional resources
-
-*  xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring]
-
-include::modules/rosa-sts-aws-requirements-ocm.adoc[leveloffset=+2]
-include::modules/rosa-sts-aws-requirements-association-concept.adoc[leveloffset=+3]
-include::modules/rosa-sts-aws-requirements-creating-association.adoc[leveloffset=+3]
-
-[discrete]
-[role="_additional-resources"]
-[id="additional-resources_creating-association_{context}"]
-== Additional resources
-* See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies_rosa-sts-about-iam-resources[Account-wide IAM role and policy reference] for a list of IAM roles needed for cluster creation.
-
-include::modules/rosa-sts-aws-requirements-creating-multi-association.adoc[leveloffset=+3]
-
-
-include::modules/rosa-requirements-deploying-in-opt-in-regions.adoc[leveloffset=+1]
-include::modules/rosa-setting-the-aws-security-token-version.adoc[leveloffset=+2]
-
-[id="rosa-sts-policy-iam_{context}"]
-== Red Hat managed IAM references for AWS
-
-With the STS deployment model, Red Hat is no longer responsible for creating and managing Amazon Web Services (AWS) IAM policies, IAM users, or IAM roles. For information on creating these roles and policies, see the following sections on IAM roles.
-
-* To use the `ocm` CLI, you must have an `ocm-role` and `user-role` resource. See xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[OpenShift Cluster Manager IAM role resources].
-* If you have a single cluster, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies_rosa-sts-about-iam-resources[Account-wide IAM role and policy reference].
-* For every cluster, you must have the necessary operator roles. See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
-
-include::modules/rosa-aws-provisioned.adoc[leveloffset=+1]
-include::modules/rosa-hcp-firewall-prerequisites.adoc[leveloffset=+1]
-
-== Next steps
-* xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Review the required AWS service quotas]
-
-[role="_additional-resources"]
-[id="additional-resources_aws-prerequisites_{context}"]
-== Additional resources
-* xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-sre-access_rosa-policy-process-security[SRE access to all Red Hat OpenShift Service on AWS clusters]
-* xref:../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-applications-config-custom-domains[Configuring custom domains for applications]
-* xref:../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-instance-types_rosa-service-definition[Instance types]
diff --git a/rosa_planning/rosa-planning-environment.adoc b/rosa_planning/rosa-planning-environment.adoc
index 10416b9abea9..07153dda457e 100644
--- a/rosa_planning/rosa-planning-environment.adoc
+++ b/rosa_planning/rosa-planning-environment.adoc
@@ -2,10 +2,11 @@
 include::_attributes/attributes-openshift-dedicated.adoc[]
 
 [id="rosa-planning-environment"]
-= Planning your environment
+= Planning resource usage in your cluster
 :context: rosa-planning-environment
 
 toc::[]
 
 include::modules/rosa-planning-environment-cluster-max.adoc[leveloffset=+1]
 include::modules/rosa-planning-environment-application-reqs.adoc[leveloffset=+1]
+    
\ No newline at end of file
diff --git a/rosa_planning/rosa-sts-aws-prereqs.adoc b/rosa_planning/rosa-sts-aws-prereqs.adoc
index 7481540a9fd5..b2622f3a9e05 100644
--- a/rosa_planning/rosa-sts-aws-prereqs.adoc
+++ b/rosa_planning/rosa-sts-aws-prereqs.adoc
@@ -1,60 +1,88 @@
 :_mod-docs-content-type: ASSEMBLY
 include::_attributes/attributes-openshift-dedicated.adoc[]
+//title and ID conditions so this can be shared between Classic and HCP docs while it remains accurate for both
+ifndef::openshift-rosa-hcp[]
 :context: rosa-sts-aws-prereqs
 [id="rosa-sts-aws-prereqs"]
-= Detailed requirements for deploying ROSA using STS
+= Detailed requirements for deploying ROSA (classic architecture) using STS
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+:context: rosa-hcp-prereqs
+[id="rosa-hcp-prereqs"]
+= Detailed requirements for deploying {hcp-title}
+endif::openshift-rosa-hcp[]
 
 toc::[]
 
 {product-title} (ROSA) provides a model that allows Red{nbsp}Hat to deploy clusters into a customer’s existing Amazon Web Service (AWS) account.
 
-include::snippets/rosa-sts.adoc[]
+ifndef::openshift-rosa-hcp[]
+include::snippets/rosa-sts.adoc[leveloffset=+0]
+endif::openshift-rosa-hcp[]
 
-Ensure that the following AWS prerequisites are met before installing ROSA with STS.
-
-[IMPORTANT]
-====
-When you create a ROSA cluster using AWS STS, an associated AWS OpenID Connect (OIDC) identity provider is created as well. This OIDC provider configuration relies on a public key that is located in the `us-east-1` AWS region. Customers with AWS SCPs must allow the use of the `us-east-1` AWS region, even if these clusters are deployed in a different region.
-====
+Ensure that the following prerequisites are met before installing your cluster.
 
+ifndef::openshift-rosa-hcp[]
 [id="rosa-sts-customer-requirements_{context}"]
 == Customer requirements when using STS for deployment
 
 The following prerequisites must be complete before you deploy a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS).
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+[id="rosa-hcp-customer-requirements_{context}"]
+== Customer requirements for all {hcp-title} clusters
+
+The following prerequisites must be complete before you deploy a {hcp-title} cluster.
+endif::openshift-rosa-hcp[]
 
 include::modules/rosa-sts-aws-requirements-account.adoc[leveloffset=+2]
+
+//Adding conditions around these in case the Additional resources don't get ported to HCP or have different file names / locations; keeping all included for now 
+ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_aws-account-requirements_{context}"]
 .Additional resources
-* xref:../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and scalability]
 * xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-elb-service-role_rosa-troubleshooting-cluster-deployments[Creating the Elastic Load Balancing (ELB) service-linked role]
+endif::openshift-rosa-hcp[]
 
-include::modules/rosa-sts-aws-requirements-access-req.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-[id="additional-resources_aws-access-requirements_{context}"]
-.Additional resources
-* See xref:../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-applications-config-custom-domains[Configuring custom domains for applications]
-
+//TODO OSDOCS-11789: Nothing in the following module is actually a requirement, it's purely informative/recommended and needs to be re-validated by SRE/Support
 include::modules/rosa-sts-aws-requirements-support-req.adoc[leveloffset=+2]
+
+//TODO OSDOCS-11789: Need to have this re-validated by SRE/Support
 include::modules/rosa-sts-aws-requirements-security-req.adoc[leveloffset=+2]
 
+//Adding conditions around these in case the Additional resources don't get ported to HCP or have different file names / locations; keeping all included for now 
 [role="_additional-resources"]
 [id="additional-resources_aws-security-requirements_{context}"]
 .Additional resources
+ifdef::openshift-dedicated[]
 * xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
+endif::openshift-dedicated[]
+ifdef::openshift-rosa[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-hcp-prereqs[AWS firewall prerequisites]
+endif::openshift-rosa-hcp[]
 
-include::modules/rosa-sts-aws-requirements-ocm.adoc[leveloffset=+2]
-include::modules/rosa-sts-aws-requirements-association-concept.adoc[leveloffset=+3]
-include::modules/rosa-sts-aws-requirements-creating-association.adoc[leveloffset=+3]
+[id="rosa-ocm-requirements_{context}"]
+== Requirements for using {cluster-manager}
 
+The following configuration details are required only if you use {cluster-manager-url} to manage your clusters. If you use the CLI tools exclusively, then you can disregard these requirements.
+
+//TODO OSDOCS-11789: when are ocm-role and user-role actually created? Pretty sure this happens as part of the cluster install process, so doesn't need to be done ahead of time??
+include::modules/rosa-sts-aws-requirements-association-concept.adoc[leveloffset=+2]
+include::modules/rosa-sts-aws-requirements-creating-association.adoc[leveloffset=+2]
+
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 [discrete]
 [role="_additional-resources"]
 [id="additional-resources_creating-association_{context}"]
 == Additional resources
 * See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies_rosa-sts-about-iam-resources[Account-wide IAM role and policy reference] for a list of IAM roles needed for cluster creation.
+endif::openshift-rosa,openshift-rosa-hcp[]
 
-include::modules/rosa-sts-aws-requirements-creating-multi-association.adoc[leveloffset=+3]
+include::modules/rosa-sts-aws-requirements-creating-multi-association.adoc[leveloffset=+2]
 
 
 include::modules/rosa-requirements-deploying-in-opt-in-regions.adoc[leveloffset=+1]
@@ -63,11 +91,20 @@ include::modules/rosa-setting-the-aws-security-token-version.adoc[leveloffset=+2
 [id="rosa-sts-policy-iam_{context}"]
 == Red{nbsp}Hat managed IAM references for AWS
 
-With the STS deployment model, Red{nbsp}Hat is no longer responsible for creating and managing Amazon Web Services (AWS) IAM policies, IAM users, or IAM roles. For information on creating these roles and policies, see the following sections on IAM roles.
-
-* To use the `ocm` CLI, you must have an `ocm-role` and `user-role` resource. See xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[OpenShift Cluster Manager IAM role resources].
+ifndef::openshift-rosa-hcp[]
+When you use STS as your cluster credential method,
+endif::openshift-rosa-hcp[]
+Red{nbsp}Hat is not responsible for creating and managing Amazon Web Services (AWS) IAM policies, IAM users, or IAM roles. For information on creating these roles and policies, see the following sections on IAM roles.
+
+* To use the `ocm` CLI, you must have an `ocm-role` and `user-role` resource.
+ifndef::openshift-rosa-hcp[]
+See xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[OpenShift Cluster Manager IAM role resources].
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+See xref:../rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc#rosa-prepare-iam-resources-roles-ocm[Required IAM roles and resources].
+endif::openshift-rosa-hcp[]
 * If you have a single cluster, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies_rosa-sts-about-iam-resources[Account-wide IAM role and policy reference].
-* For every cluster, you must have the necessary operator roles. See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
+* For each cluster, you must have the necessary operator roles. See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
 
 include::modules/rosa-aws-provisioned.adoc[leveloffset=+1]
 
@@ -77,25 +114,43 @@ include::modules/rosa-aws-provisioned.adoc[leveloffset=+1]
 include::modules/mos-network-prereqs-min-bandwidth.adoc[leveloffset=+2]
 
 // Keeping existing ID to prevent link breakage
-[id="osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs"]
-=== AWS firewall prerequisites
+ifdef::openshift-rosa[]
+//[id="osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs"]
+//=== AWS firewall prerequisites
+
+//If you are using a firewall to control egress traffic from your {product-title}, you must configure your firewall to grant access to the certain domain and port combinations below. {product-title} requires this access to provide a fully managed OpenShift service.
 
-If you are using a firewall to control egress traffic from your {product-title}, you must configure your firewall to grant access to the certain domain and port combinations below. {product-title} requires this access to provide a fully managed OpenShift service.
+include::modules/osd-aws-privatelink-firewall-prerequisites.adoc[leveloffset=+2]
+// TODO HCP SPLIT - remove openshift-rosa from below condition when HCP docs are published
+include::modules/rosa-hcp-firewall-prerequisites.adoc[leveloffset=+2]
+endif::openshift-rosa[]
 
-include::modules/osd-aws-privatelink-firewall-prerequisites.adoc[leveloffset=+3]
-include::modules/rosa-hcp-firewall-prerequisites.adoc[leveloffset=+3]
+ifdef::openshift-rosa-hcp[]
+include::modules/rosa-hcp-firewall-prerequisites.adoc[leveloffset=+2]
+endif::openshift-rosa-hcp[]
 
+ifdef::openshift-rosa[]
 [role="_additional-resources"]
 .Additional resources
+* xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring]
+endif::openshift-rosa[]
 
-*  xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring]
-
+[discrete]
 == Next steps
-* xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Review the required AWS service quotas]
+* xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-required-aws-service-quotas_rosa-sts-required-aws-service-quotas[Review the required AWS service quotas]
 
+[discrete]
 [role="_additional-resources"]
 [id="additional-resources_aws-prerequisites_{context}"]
 == Additional resources
+ifdef::openshift-rosa[]
 * xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-sre-access_rosa-policy-process-security[SRE access to all Red{nbsp}Hat OpenShift Service on AWS clusters]
 * xref:../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-applications-config-custom-domains[Configuring custom domains for applications]
 * xref:../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-instance-types_rosa-service-definition[Instance types]
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc#rosa-sre-access[SRE and service account access]
+//Omitted until Applications has been ported for HCP
+//* xref ../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-applications-config-custom-domains[Configuring custom domains for applications]
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-instance-types.adoc#rosa-hcp-instance-types[Instance types]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/rosa_planning/rosa-sts-ocm-role.adoc b/rosa_planning/rosa-sts-ocm-role.adoc
index 2f7326cfe3ce..46fb0e012107 100644
--- a/rosa_planning/rosa-sts-ocm-role.adoc
+++ b/rosa_planning/rosa-sts-ocm-role.adoc
@@ -6,49 +6,37 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 
 toc::[]
 
-{product-title} (ROSA) web UI requires that you have specific permissions on your AWS account that create a trust relationship to provide the end-user experience at {cluster-manager-url} and for the `rosa` command line interface (CLI).
+You must create several role resources on your AWS account in order to create and manage a {product-title} (ROSA) cluster.
 
-This trust relationship is achieved through the creation and association of the `ocm-role` AWS IAM role. This role has a trust policy with the AWS installer that links your Red{nbsp}Hat account to your AWS account. In addition, you also need a `user-role` AWS IAM role for each web UI user, which serves to identify these users. This `user-role` AWS IAM role has no permissions.
+include::modules/rosa-prereq-roles-overview.adoc[leveloffset=+1]
 
-The AWS IAM roles required to use {cluster-manager} are:
+.Additional resources
+ifndef::openshift-rosa-hcp[]
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa[]
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference]
+endif::openshift-rosa[]
 
-* `ocm-role`
-* `user-role`
-
-Whether you manage your clusters using the ROSA CLI (`rosa`) or {cluster-manager} web UI, you must create the account-wide roles, known as `account-roles` in the ROSA CLI, by using the ROSA CLI. These account roles are necessary for your first cluster, and these roles can be used across multiple clusters. These required account roles are:
-
-* `Worker-Role`
-* `Support-Role`
-* `Installer-Role`
-* `ControlPlane-Role`
-
-[NOTE]
-====
-Role creation does not request your AWS access or secret keys. AWS Security Token Service (STS) is used as the basis of this workflow. AWS STS uses temporary, limited-privilege credentials to provide authentication.
-====
-
-For more information about creating these roles, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference].
-
-Cluster-specific Operator roles, known as `operator-roles` in the ROSA CLI, obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, ingress, and registry. These roles are required by the cluster that you create. These required Operator roles are:
-
-* `<cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credentials`
-* `<cluster_name>-<hash>-openshift-cloud-network-config-controller-credentials`
-* `<cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials`
-* `<cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-credentials`
-* `<cluster_name>-<hash>-openshift-image-registry-installer-cloud-credentials`
-* `<cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials`
-
-For more information on creating these roles, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
+//Roles required to use {cluster-manager}
 
 include::modules/rosa-sts-about-ocm-role.adoc[leveloffset=+1]
 
+ifdef::openshift-rosa[]
 [discrete]
 [id="additional-resources-about-ocm-role"]
 [role="_additional-resources"]
 == Additional resources
-* See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-understanding-ocm-role[Understanding the OpenShift Cluster Manager role]
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-understanding-ocm-role[Understanding the {cluster-manager} role]
+endif::openshift-rosa[]
 
 include::modules/rosa-sts-ocm-role-creation.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_ocm-role-creation_{context}"]
+.Additional resources
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
+
 include::modules/rosa-sts-about-user-role.adoc[leveloffset=+1]
 include::modules/rosa-sts-user-role-creation.adoc[leveloffset=+2]
 
@@ -57,14 +45,30 @@ include::modules/rosa-sts-user-role-creation.adoc[leveloffset=+2]
 If you unlink or delete your `user-role` IAM role prior to deleting your cluster, an error prevents you from deleting your cluster. You must create or relink this role to proceed with the deletion process. See xref:../support/troubleshooting/rosa-troubleshooting-deployments.adoc#rosa-troubleshooting-cluster-deletion_rosa-troubleshooting-cluster-deployments[Repairing a cluster that cannot be deleted] for more information.
 ====
 
+[role="_additional-resources"]
+[id="additional-resources_user-role-creation_{context}"]
+.Additional resources
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
+
 include::modules/rosa-sts-aws-requirements-association-concept.adoc[leveloffset=+1]
 include::modules/rosa-sts-aws-requirements-creating-association.adoc[leveloffset=+2]
 include::modules/rosa-sts-aws-requirements-creating-multi-association.adoc[leveloffset=+2]
+
+ifndef::openshift-rosa-hcp[]
 include::modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc[leveloffset=+1]
+endif::openshift-rosa-hcp[]
 
 [role="_additional-resources"]
 == Additional resources
-* See link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] (AWS documentation).
-* See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[Creating the account-wide STS roles and policies].
-* See xref:../support/troubleshooting/rosa-troubleshooting-iam-resources.adoc#rosa-sts-ocm-roles-and-permissions-troubleshooting[Troubleshooting IAM roles].
-* See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference] for a list of IAM roles needed for cluster creation.
\ No newline at end of file
+* link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities (AWS documentation)]
+ifdef::openshift-rosa[]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-sts-creating-a-cluster-quickly[Creating the account-wide STS roles and policies]
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-account-wide-sts-roles-and-policies_rosa-hcp-sts-creating-a-cluster-quickly[Creating account-wide roles and policies]
+endif::openshift-rosa-hcp[]
+* xref:../support/troubleshooting/rosa-troubleshooting-iam-resources.adoc#rosa-sts-ocm-roles-and-permissions-troubleshooting[Troubleshooting IAM roles]
+ifdef::openshift-rosa[]
+* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference]
+endif::openshift-rosa[]
+
diff --git a/rosa_planning/rosa-sts-required-aws-service-quotas.adoc b/rosa_planning/rosa-sts-required-aws-service-quotas.adoc
index d397920bd51a..07764c2f9272 100644
--- a/rosa_planning/rosa-sts-required-aws-service-quotas.adoc
+++ b/rosa_planning/rosa-sts-required-aws-service-quotas.adoc
@@ -11,4 +11,9 @@ Review this list of the required Amazon Web Service (AWS) service quotas that ar
 include::modules/rosa-required-aws-service-quotas.adoc[leveloffset=+1]
 
 == Next steps
-* xref:../rosa_planning/rosa-sts-setting-up-environment.adoc#rosa-sts-setting-up-environment[Set up the environment and install ROSA]
+ifndef::openshift-rosa-hcp[]
+* xref:../rosa_planning/rosa-sts-setting-up-environment.adoc#rosa-sts-setting-up-environment[Setting up the environment]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_planning/rosa-sts-setting-up-environment.adoc#rosa-hcp-setting-up-environment[Setting up the environment]
+endif::openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/rosa_planning/rosa-sts-setting-up-environment.adoc b/rosa_planning/rosa-sts-setting-up-environment.adoc
index 2ae41b6ccd6a..f774af2fb7fe 100644
--- a/rosa_planning/rosa-sts-setting-up-environment.adoc
+++ b/rosa_planning/rosa-sts-setting-up-environment.adoc
@@ -1,25 +1,54 @@
 :_mod-docs-content-type: ASSEMBLY
+ifndef::openshift-rosa-hcp[]
 [id="rosa-sts-setting-up-environment"]
 = Setting up the environment for using STS
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: rosa-sts-setting-up-environment
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+[id="rosa-hcp-setting-up-environment"]
+= Setting up the environment
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: rosa-hcp-setting-up-environment
+endif::openshift-rosa-hcp[]
 
 toc::[]
 
 After you meet the AWS prerequisites, set up your environment and install {product-title} (ROSA).
 
-include::snippets/rosa-sts.adoc[]
+//For ROSA clusters
+ifndef::openshift-rosa-hcp[]
+
+include::snippets/rosa-sts.adoc[leveloffset=+0]
 
 include::modules/rosa-sts-setting-up-environment.adoc[leveloffset=+1]
 
+endif::openshift-rosa-hcp[]
+
+//For HCP clusters
+ifdef::openshift-rosa-hcp[]
+
+include::modules/rosa-getting-started-install-configure-cli-tools.adoc[leveloffset=+1]
+
+endif::openshift-rosa-hcp[]
+
 [id="next-steps_rosa-sts-setting-up-environment"]
 == Next steps
-
+ifndef::openshift-rosa-hcp[]
 * xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Create a ROSA cluster with STS quickly] or xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-a-cluster-with-customizations[create a cluster using customizations].
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Create a ROSA with HCP cluster]
+endif::openshift-rosa-hcp[]
 
 [id="additional-resources"]
 [role="_additional-resources"]
 == Additional resources
-
+ifndef::openshift-rosa-hcp[]
 * xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[AWS Prerequisites]
 * xref:../rosa_planning/rosa-sts-required-aws-service-quotas.adoc#rosa-sts-required-aws-service-quotas[Required AWS service quotas and increase requests]
+endif::openshift-rosa-hcp[]
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-prereqs[AWS Prerequisites]
+// TODO OSDOCS-11789: AWS quotas for HCP
+endif::openshift-rosa-hcp[]
diff --git a/rosa_release_notes/rosa-release-notes.adoc b/rosa_release_notes/rosa-release-notes.adoc
index 0e6d6a20d0ce..4cf5d18ae081 100644
--- a/rosa_release_notes/rosa-release-notes.adoc
+++ b/rosa_release_notes/rosa-release-notes.adoc
@@ -1,6 +1,7 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="rosa-whats-new"]
 = What's new with {product-title}
+include::_attributes/common-attributes.adoc[]
 include::_attributes/attributes-openshift-dedicated.adoc[]
 :context: rosa-whats-new
 
@@ -8,7 +9,7 @@ toc::[]
 
 {product-title} (ROSA) is a fully-managed, turnkey application platform that allows you to focus on delivering value to your customers by building and deploying applications. Red{nbsp}Hat and AWS site reliability engineering (SRE) experts manage the underlying platform so you do not have to worry about the complexity of infrastructure management. ROSA provides seamless integration with a wide range of AWS compute, database, analytics, machine learning, networking, mobile, and other services to further accelerate the building and delivering of differentiating experiences to your customers.
 
-{product-title} clusters are available on the link:https://console.redhat.com/openshift[Hybrid Cloud Console]. With the Red{nbsp}Hat OpenShift Cluster Manager application for ROSA, you can deploy {product-title} clusters to either on-premises or cloud environments.
+{product-title} clusters are available on the link:https://console.redhat.com/openshift[Hybrid Cloud Console]. With the Red{nbsp}Hat {cluster-manager} application for ROSA, you can deploy {product-title} clusters to either on-premise or cloud environments.
 
 [id="rosa-new-changes-and-updates_{context}"]
 == New changes and updates
@@ -16,24 +17,64 @@ toc::[]
 [id="rosa-q1-2025_{context}"]
 === Q1 2025
 
+ifdef::openshift-rosa[]
+//Remove when ROSA HCP is published.
+* **Cluster autoscaling is now available for {hcp-title}.** You can configure cluster autoscaling for {hcp-title}. For more information, see xref:../rosa_cluster_admin/rosa-cluster-autoscaling-hcp.adoc#rosa-cluster-autoscaling-hcp[Cluster autoscaling].
+endif::openshift-rosa[]
+
+ifdef::openshift-rosa-hcp[]
+* **Cluster autoscaling is now available for {product-title}.** You can configure cluster autoscaling for {product-title}. For more information, see xref:../rosa_cluster_admin/rosa-cluster-autoscaling.adoc#rosa-cluster-autoscaling[Cluster autoscaling].
+endif::openshift-rosa-hcp[]
+
+ifdef::openshift-rosa[]
+* **New version of {product-title} available.** {product-title} version 4.18 is now available. For more information about upgrading to this latest version, see xref:../upgrading/rosa-upgrading-sts.adoc#rosa-upgrading-sts[Upgrading ROSA (classic architecture) clusters].
+endif::openshift-rosa[]
+
+//remove from rosa distro once HCP split occurs.
+* **New version of {hcp-title} available.** {hcp-title} version 4.18 is now available. For more information about upgrading to this latest version, see xref:../upgrading/rosa-hcp-upgrading.adoc#rosa-hcp-upgrading[Upgrading ROSA with HCP clusters].
+
+* **Graphical installer enhancements.** You can now use the graphical installer in {hybrid-console} to configure the following options when you create your cluster:
+** Configure a `cluster-admin` user and optionally define a custom password.
+** Configure the root disk size for the default machine pool.
+
+ifdef::openshift-rosa-hcp[]
+* **Edit the billing account for existing ROSA with HCP clusters.** You can now update the billing account associated with your {hcp-title} clusters after cluster creation. For more information, see the {cluster-manager} documentation: link:https://docs.redhat.com/en/documentation/openshift_cluster_manager/1-latest/html-single/managing_clusters/index#proc_updating-billing-accts-rosa-hcp_assembly-managing-clusters[Updating billing accounts].
+endif::openshift-rosa-hcp[]
+
+//The following is included in Classic only until the Images doc has been split for HCP
+ifndef::openshift-rosa-hcp[]
+* **Image configuration is now available for {hcp-title}.** You can configure registries within a cluster to exclude some registries or allow only a defined list. It also allows to expose additional trusted bundle for registries to pull from. For more information, see xref:../openshift_images/image-configuration-hcp.adoc#images-configuration-parameters-hcp_image-configuration-hcp[Image configuration resources for {hcp-title}].
+endif::openshift-rosa-hcp[]
+
 // These notes need to be duplicated until the ROSA with HCP split out is completed.
 ifdef::openshift-rosa[]
-[IMPORTANT]
-====
-Egress lockdown is a Technology Preview feature.
-====
+* **{rosa-classic} cluster node limit update.** {rosa-classic} clusters versions 4.14.14 and greater can now scale to 249 worker nodes. This is an increase from the previous limit of 180 nodes. For more information, see xref:../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and scalability].
 
-* **Egress lockdown is now available as a Technology Preview on {product-title} clusters.** You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster. For more information, see xref:../rosa_hcp/rosa-hcp-egress-lockdown-install.adoc#rosa-hcp-egress-lockdown-install[Creating a {product-title} cluster with egress lockdown].
+// * **{product-title} SDN network plugin blocks future major upgrades**
+* **Initiate live migration from OpenShift SDN to OVN-Kubernetes.**
+As part of the {product-title} move to OVN-Kubernetes as the only supported network plugin starting with {product-title} version 4.17, users can now initiate live migration from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin.
++
+If your cluster uses the OpenShift SDN network plugin, you cannot upgrade to future major versions of {product-title} without migrating to OVN-Kubernetes.
++
+For more information about migrating to OVN-Kubernetes, see xref:../networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc#migrate-from-openshift-sdn[Migrating from OpenShift SDN network plugin to OVN-Kubernetes network plugin].
+
+* **Red{nbsp}Hat SRE log-based alerting endpoints have been updated.** {rosa-classic} customers who are using a firewall to control egress traffic can now remove all references to `*.osdsecuritylogs.splunkcloud.com:9997` from your firewall allowlist. {rosa-classic} clusters still require the `http-inputs-osdsecuritylogs.splunkcloud.com:443` log-based alerting endpoint to be accessible from the cluster.
 endif::openshift-rosa[]
+
 ifdef::openshift-rosa-hcp[]
-[IMPORTANT]
-====
-Egress lockdown is a Technology Preview feature.
-====
+* **ROSA with HCP now creates independent security groups for the AWS PrivateLink endpoint and worker nodes.** {hcp-title} clusters version 4.17.2 and greater can now add additional AWS security groups to the AWS PrivateLink endpoint to allow additional ingress traffic to the cluster's API. For more information, see xref:../rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc#rosa-hcp-aws-private-security-groups_rosa-hcp-aws-private-creating-cluster[Adding additional AWS security groups to the AWS PrivateLink endpoint].
 
 * **Egress lockdown is now available as a Technology Preview on {product-title} clusters.** You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster. For more information, see xref:../rosa_hcp/rosa-hcp-egress-lockdown-install.adoc#rosa-hcp-egress-lockdown-install[Creating a {product-title} cluster with egress lockdown].
++
+--
+:FeatureName: Egress lockdown
+include::snippets/technology-preview.adoc[]
+--
 endif::openshift-rosa-hcp[]
+
+//The following omits all earlier updates from HCP builds, right down to Known Issues; unclear if we want this long term or if it's a stop-gap while we split the HCP docs
 ifdef::openshift-rosa[]
+
 [id="rosa-q4-2024_{context}"]
 === Q4 2024
 
@@ -145,7 +186,13 @@ For more information on region availabilities, see xref:../rosa_architecture/ros
 
 * **Configurable process identifier (PID) limits.** With the release of ROSA CLI (`rosa`) version 1.2.31, administrators can use the `rosa create kubeletconfig` and `rosa edit kubeletconfig` commands to set the maximum PIDs for an existing cluster. For more information, see link:https://access.redhat.com/articles/7033551[Changing the maximum number of process IDs per pod (podPidsLimit) for ROSA].
 
-* **Configure custom security groups.** With the release of ROSA CLI (`rosa`) version 1.2.31, administrators can use the `rosa create` command or the OpenShift Cluster Manager to create a new cluster or a new machine pool with up to 5 additional custom security groups. Configuring custom security groups gives administrators greater control over resource access in new clusters and machine pools. For more information, see xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc#rosa-security-groups_prerequisites[Security groups].
+* **Configure custom security groups.** With the release of ROSA CLI (`rosa`) version 1.2.31, administrators can use the `rosa create` command or the OpenShift Cluster Manager to create a new cluster or a new machine pool with up to 5 additional custom security groups. Configuring custom security groups gives administrators greater control over resource access in new clusters and machine pools. For more information, see
+ifdef::openshift-rosa[]
+xref:../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc#rosa-security-groups_prerequisites[Security groups].
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-security-groups_rosa-hcp-prereqs[Security groups].
+endif::openshift-rosa-hcp[]
 
 * **Command update.** With the release of ROSA CLI (`rosa`) version 1.2.28, a new command, `rosa describe machinepool`, was added that allows you to check detailed information regarding a specific ROSA cluster machine pool. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-describe-machinepool_rosa-managing-objects-cli[describe machinepool].
 
@@ -220,4 +267,4 @@ Some features available in previous releases have been deprecated or removed. De
 
 * **ROSA non-STS deployment mode.** ROSA non-STS deployment mode is no longer the preferred method for new clusters. Instead, users must deploy ROSA with the STS mode. This deprecation is in line with our new ROSA provisioning wizard UI experience at https://console.redhat.com/openshift/create/rosa/wizard.
 
-* **Label removal on core namespaces.** ROSA is no longer labeling OpenShift core using the `name` label. Customers should migrate to referencing the `kubernetes.io/metadata.name` label if needed for Network Policies or other use cases.
\ No newline at end of file
+* **Label removal on core namespaces.** ROSA is no longer labeling OpenShift core using the `name` label. Customers should migrate to referencing the `kubernetes.io/metadata.name` label if needed for Network Policies or other use cases.
diff --git a/scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc b/scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc
index 8148f850af31..c8972b79efc2 100644
--- a/scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc
+++ b/scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc
@@ -17,7 +17,7 @@ include::modules/understanding-a-reference-config.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../../scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc#telco-ref-design-overview_telco_ref_design_specs[Reference design specifications for telco 5G deployments]
+* xref:../../scalability_and_performance/telco-ran-du-rds.adoc#telco-ran-du-ref-design-specs[Telco RAN DU reference design specification for {product-title}]
 
 
 
diff --git a/scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc b/scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
index e5d068a196e1..c6087e488b4b 100644
--- a/scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
+++ b/scalability_and_performance/cluster-compare/using-the-cluster-compare-plugin.adoc
@@ -24,5 +24,5 @@ include::modules/using-cluster-compare-telco-ref.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources
-* xref:../../scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#using-cluster-compare-telco_ref_ran-ref-design-crs[Comparing a cluster with the telco RAN DU reference configuration]
-* xref:../../scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc#using-cluster-compare-telco_ref_ran-core-ref-design-crs[Comparing a cluster with the telco core reference configuration]
+* xref:../../scalability_and_performance/telco-ran-du-rds.adoc#using-cluster-compare-telco-ran_ran-ref-design-crs[Comparing a cluster with the telco RAN DU reference configuration]
+* xref:../../scalability_and_performance/telco-core-rds.adoc#using-cluster-compare-telco_core_telco-core[Comparing a cluster with the telco core reference configuration]
diff --git a/scalability_and_performance/cnf-debugging-low-latency-tuning-status.adoc b/scalability_and_performance/cnf-debugging-low-latency-tuning-status.adoc
new file mode 100644
index 000000000000..09248f04a138
--- /dev/null
+++ b/scalability_and_performance/cnf-debugging-low-latency-tuning-status.adoc
@@ -0,0 +1,26 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="cnf-debugging-low-latency-tuning-status"]
+= Debugging low latency node tuning status
+include::_attributes/common-attributes.adoc[]
+:context: cnf-debugging-low-latency
+
+toc::[]
+
+Use the `PerformanceProfile` custom resource (CR) status fields for reporting tuning status and debugging latency issues in the cluster node.
+
+include::modules/cnf-debugging-low-latency-cnf-tuning-status.adoc[leveloffset=+1]
+
+include::modules/cnf-collecting-low-latency-tuning-debugging-data-for-red-hat-support.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gathering data about your cluster with the `must-gather` tool]
+
+* xref:../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-managing[Managing nodes with MachineConfig and KubeletConfig CRs]
+
+* xref:../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator]
+
+* xref:../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#configuring-huge-pages_huge-pages[Configuring huge pages at boot time]
+
+* xref:../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#how-huge-pages-are-consumed-by-apps_huge-pages[How huge pages are consumed by apps]
diff --git a/scalability_and_performance/cnf-numa-aware-scheduling.adoc b/scalability_and_performance/cnf-numa-aware-scheduling.adoc
index c6b1ed839900..b59ffd6d30dc 100644
--- a/scalability_and_performance/cnf-numa-aware-scheduling.adoc
+++ b/scalability_and_performance/cnf-numa-aware-scheduling.adoc
@@ -14,9 +14,14 @@ The NUMA Resources Operator allows you to schedule high-performance workloads in
 
 include::modules/cnf-about-numa-aware-scheduling.adoc[leveloffset=+1]
 
+include::modules/cnf-numa-resource-scheduling-strategies.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
 .Additional resources
 
-* For more information about running secondary pod schedulers in your cluster and how to deploy pods with a secondary pod scheduler, see xref:../nodes/scheduling/secondary_scheduler/nodes-secondary-scheduler-configuring.adoc#secondary-scheduler-configuring[Scheduling pods using a secondary scheduler].
+* xref:../nodes/scheduling/secondary_scheduler/nodes-secondary-scheduler-configuring.adoc#secondary-scheduler-configuring[Scheduling pods using a secondary scheduler]
+
+* xref:../scalability_and_performance/cnf-numa-aware-scheduling.adoc#cnf-changing-where-high-performance-workloads-run_numa-aware[Changing where high-performance workloads run]
 
 [id="installing-the-numa-resources-operator_{context}"]
 == Installing the NUMA Resources Operator
@@ -35,11 +40,12 @@ include::modules/cnf-deploying-the-numa-aware-scheduler.adoc[leveloffset=+2]
 
 include::modules/cnf-configuring-single-numa-policy.adoc[leveloffset=+2]
 
+[role="_additional-resources"]
 .Additional resources
 
 * xref:../disconnected/updating/disconnected-update.adoc#images-configuration-registry-mirror-configuring_updating-disconnected-cluster[Configuring image registry repository mirroring]
 
-* xref:../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
 
 include::modules/cnf-sample-single-numa-policy-from-pp.adoc[leveloffset=+2]
 
@@ -53,6 +59,8 @@ include::modules/cnf-troubleshooting-numa-aware-workloads.adoc[leveloffset=+1]
 
 include::modules/cnf-reporting-more-exact-reource-availability.adoc[leveloffset=+2]
 
+include::modules/cnf-scheduling-exact-based-on-reource.adoc[leveloffset=+2]
+
 include::modules/cnf-checking-numa-aware-scheduler-logs.adoc[leveloffset=+2]
 
 include::modules/cnf-troubleshooting-resource-topo-exporter.adoc[leveloffset=+2]
diff --git a/scalability_and_performance/low_latency_tuning/cnf-performing-platform-verification-latency-tests.adoc b/scalability_and_performance/cnf-performing-platform-verification-latency-tests.adoc
similarity index 88%
rename from scalability_and_performance/low_latency_tuning/cnf-performing-platform-verification-latency-tests.adoc
rename to scalability_and_performance/cnf-performing-platform-verification-latency-tests.adoc
index 33dcc00b372b..dc010048b9a8 100644
--- a/scalability_and_performance/low_latency_tuning/cnf-performing-platform-verification-latency-tests.adoc
+++ b/scalability_and_performance/cnf-performing-platform-verification-latency-tests.adoc
@@ -22,7 +22,7 @@ Your cluster must meet the following requirements before you can run the latency
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc#cnf-scheduling-workload-onto-worker-with-real-time-capabilities_cnf-provisioning-low-latency[Scheduling a workload onto a worker with real-time capabilities]
+* xref:../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#cnf-scheduling-workload-onto-worker-with-real-time-capabilities_cnf-provisioning-low-latency[Scheduling a workload onto a worker with real-time capabilities]
 
 include::modules/cnf-measuring-latency.adoc[leveloffset=+1]
 
diff --git a/scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc b/scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc
similarity index 67%
rename from scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc
rename to scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc
index c213461c650f..b13a680b421e 100644
--- a/scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc
+++ b/scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc
@@ -20,14 +20,14 @@ When writing your applications, follow the general recommendations described in
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
 
 include::modules/cnf-scheduling-workload-onto-worker-with-real-time-capabilities.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-pods-node-selectors[Placing pods on specific nodes using node selectors]
+* xref:../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-pods-node-selectors[Placing pods on specific nodes using node selectors]
 
 * link:https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node[Assigning pods to nodes]
 
@@ -40,18 +40,18 @@ include::modules/cnf-configuring-high-priority-workload-pods.adoc[leveloffset=+1
 [role="_additional-resources"]
 .Additional resources
 
-xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
+xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
 
 include::modules/cnf-disabling-cpu-cfs-quota.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../edge_computing/ztp-vdu-validating-cluster-tuning.adoc#ztp-du-firmware-config-reference_vdu-config-ref[Recommended firmware configuration for vDU cluster hosts]
+* xref:../edge_computing/ztp-vdu-validating-cluster-tuning.adoc#ztp-du-firmware-config-reference_vdu-config-ref[Recommended firmware configuration for vDU cluster hosts]
 
 include::modules/cnf-disabling-interrupt-processing-for-individual-pods.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile#managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus_cnf-low-latency-perf-profile[Managing device interrupt processing for guaranteed pod isolated CPUs]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile#managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus_cnf-low-latency-perf-profile[Managing device interrupt processing for guaranteed pod isolated CPUs]
diff --git a/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc b/scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
similarity index 79%
rename from scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
rename to scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
index 719d1b382a3b..8080b04d4d2e 100644
--- a/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
+++ b/scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
@@ -45,7 +45,7 @@ include::modules/cnf-gathering-data-about-cluster-using-must-gather.adoc[levelof
 .Additional resources
 
 * For more information about the `must-gather` tool,
-see xref:../../support/gathering-cluster-data.adoc#nodes-nodes-managing[Gathering data about your cluster].
+see xref:../support/gathering-cluster-data.adoc#nodes-nodes-managing[Gathering data about your cluster].
 
 include::modules/cnf-running-the-performance-creator-profile.adoc[leveloffset=+2]
 
@@ -73,11 +73,11 @@ include::modules/cnf-configuring-power-saving-for-nodes.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc#cnf-configuring-high-priority-workload-pods_cnf-provisioning-low-latency[Disabling power saving mode for high priority pods]
+* xref:../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#cnf-configuring-high-priority-workload-pods_cnf-provisioning-low-latency[Disabling power saving mode for high priority pods]
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus_cnf-low-latency-perf-profile[Managing device interrupt processing for guaranteed pod isolated CPUs]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus_cnf-low-latency-perf-profile[Managing device interrupt processing for guaranteed pod isolated CPUs]
 
 include::modules/cnf-cpu-infra-container.adoc[leveloffset=+1]
 
@@ -89,7 +89,11 @@ include::modules/cnf-about-irq-affinity-setting.adoc[leveloffset=+2]
 
 include::modules/cnf-configure_for_irq_dynamic_load_balancing.adoc[leveloffset=+2]
 
-include::modules/cnf-configuring-huge-pages.adoc[leveloffset=+1]
+include::modules/cnf-memory-optimization.adoc[leveloffset=+1]
+
+include::modules/configuring-kernal-page-size.adoc[leveloffset=+2]
+
+include::modules/cnf-configuring-huge-pages.adoc[leveloffset=+2]
 
 include::modules/cnf-allocating-multiple-huge-page-sizes.adoc[leveloffset=+2]
 
@@ -104,7 +108,7 @@ include::modules/cnf-adjusting-nic-queues-with-the-performance-profile.adoc[leve
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile].
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile].
 
 include::modules/cnf-verifying-queue-status.adoc[leveloffset=+2]
 
diff --git a/scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc b/scalability_and_performance/cnf-understanding-low-latency.adoc
similarity index 79%
rename from scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc
rename to scalability_and_performance/cnf-understanding-low-latency.adoc
index e528aee325b7..1b119359a749 100644
--- a/scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc
+++ b/scalability_and_performance/cnf-understanding-low-latency.adoc
@@ -17,4 +17,4 @@ include::modules/cnf-about-hyperthreading-for-low-latency-and-real-time-applicat
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-hyperthreading-for-a-cluster_cnf-low-latency-perf-profile[Configuring Hyper-Threading for a cluster]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-hyperthreading-for-a-cluster_cnf-low-latency-perf-profile[Configuring Hyper-Threading for a cluster]
diff --git a/scalability_and_performance/enabling-workload-partitioning.adoc b/scalability_and_performance/enabling-workload-partitioning.adoc
index 02f8fe590f10..fd0302823bf6 100644
--- a/scalability_and_performance/enabling-workload-partitioning.adoc
+++ b/scalability_and_performance/enabling-workload-partitioning.adoc
@@ -30,7 +30,7 @@ include::modules/create-perf-profile-workload-partitioning.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
 
 
 == Sample performance profile configuration
diff --git a/scalability_and_performance/index.adoc b/scalability_and_performance/index.adoc
index 15937cda6ea6..e7e8c649b9d2 100644
--- a/scalability_and_performance/index.adoc
+++ b/scalability_and_performance/index.adoc
@@ -13,7 +13,7 @@ To contact Red Hat support, see xref:../support/getting-support.adoc#getting-sup
 
 [NOTE]
 ====
-Some performance and scalability Operators have release cycles that are independent from {product-title} release cycles. For more information, see link:access.redhat.com/support/policy/updates/openshift_operators[Openshift Operators].
+Some performance and scalability Operators have release cycles that are independent from {product-title} release cycles. For more information, see link:access.redhat.com/support/policy/updates/openshift_operators[OpenShift Operators].
 ====
 
 [discrete]
@@ -28,9 +28,9 @@ xref:../scalability_and_performance/recommended-performance-scale-practices/reco
 [discrete]
 == Telco reference design specifications
 
-xref:../scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc#telco-ran-architecture-overview_ran-ref-design-spec[Telco RAN DU specification]
+xref:../scalability_and_performance/telco-ran-du-rds.adoc#telco-ran-du-ref-design-specs[Telco RAN DU reference design specification for {product-title} {product-version}]
 
-xref:../scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc#telco-core-cluster-service-based-architecture-and-networking-topology_core-ref-design-overview[Telco core reference design specification]
+xref:../scalability_and_performance/telco-core-rds.adoc#telco-core-ref-design-specs[Telco core reference design specification]
 
 [discrete]
 == Planning, optimization, and measurement
@@ -50,7 +50,7 @@ xref:../scalability_and_performance/managing-bare-metal-hosts.adoc#managing-bare
 
 xref:../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#what-huge-pages-do-and-how-they-are-consumed[What are huge pages and how are they used by apps]
 
-xref:../scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc#cnf-understanding-low-latency[Low latency tuning for improving cluster stability and partitioning workload]
+xref:../scalability_and_performance/cnf-understanding-low-latency.adoc#cnf-understanding-low-latency[Low latency tuning for improving cluster stability and partitioning workload]
 
 xref:../scalability_and_performance/scaling-worker-latency-profiles.adoc#scaling-worker-latency-profiles[Improving cluster stability in high latency environments using worker latency profiles]
 
@@ -58,4 +58,4 @@ xref:../scalability_and_performance/enabling-workload-partitioning.adoc#enabling
 
 xref:../scalability_and_performance/node-observability-operator.adoc#using-node-observability-operator[Using the Node Observability Operator]
 
-// endif::[]
\ No newline at end of file
+// endif::[]
diff --git a/scalability_and_performance/low_latency_tuning/cnf-debugging-low-latency-tuning-status.adoc b/scalability_and_performance/low_latency_tuning/cnf-debugging-low-latency-tuning-status.adoc
deleted file mode 100644
index 297cfd533f77..000000000000
--- a/scalability_and_performance/low_latency_tuning/cnf-debugging-low-latency-tuning-status.adoc
+++ /dev/null
@@ -1,26 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="cnf-debugging-low-latency-tuning-status"]
-= Debugging low latency node tuning status
-include::_attributes/common-attributes.adoc[]
-:context: cnf-debugging-low-latency
-
-toc::[]
-
-Use the `PerformanceProfile` custom resource (CR) status fields for reporting tuning status and debugging latency issues in the cluster node.
-
-include::modules/cnf-debugging-low-latency-cnf-tuning-status.adoc[leveloffset=+1]
-
-include::modules/cnf-collecting-low-latency-tuning-debugging-data-for-red-hat-support.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../support/gathering-cluster-data.adoc#gathering-cluster-data[Gathering data about your cluster with the `must-gather` tool]
-
-* xref:../../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-managing[Managing nodes with MachineConfig and KubeletConfig CRs]
-
-* xref:../../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator]
-
-* xref:../../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#configuring-huge-pages_huge-pages[Configuring huge pages at boot time]
-
-* xref:../../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#how-huge-pages-are-consumed-by-apps_huge-pages[How huge pages are consumed by apps]
diff --git a/scalability_and_performance/managing-bare-metal-hosts.adoc b/scalability_and_performance/managing-bare-metal-hosts.adoc
index 04550ff9906f..8e1d334ef2e7 100644
--- a/scalability_and_performance/managing-bare-metal-hosts.adoc
+++ b/scalability_and_performance/managing-bare-metal-hosts.adoc
@@ -1,12 +1,12 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="managing-bare-metal-hosts"]
-= Managing bare metal hosts
+= Managing bare-metal hosts
 include::_attributes/common-attributes.adoc[]
 :context: managing-bare-metal-hosts
 
 toc::[]
 
-When you install {product-title} on a bare metal cluster, you can provision and manage bare metal nodes using `machine` and `machineset` custom resources (CRs) for bare metal hosts that exist in the cluster.
+When you install {product-title} on a bare-metal cluster, you can provision and manage bare-metal nodes by using `machine` and `machineset` custom resources (CRs) for bare-metal hosts that exist in the cluster.
 
 include::modules/about-bare-metal-hosts-and-nodes.adoc[leveloffset=+1]
 include::modules/maintaining-bare-metal-hosts.adoc[leveloffset=+1]
@@ -26,3 +26,5 @@ include::modules/removing-bare-metal-hosts-from-provisioner.adoc[leveloffset=+2]
 
 * xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#ipi-install-expanding-the-cluster[Expanding the cluster]
 * xref:../machine_management/deploying-machine-health-checks.adoc#machine-health-checks-bare-metal_deploying-machine-health-checks[MachineHealthChecks on bare metal]
+
+include::modules/powering-off-bare-metal-hosts-web-console.adoc[leveloffset=+2]
diff --git a/scalability_and_performance/optimization/optimizing-storage.adoc b/scalability_and_performance/optimization/optimizing-storage.adoc
index 2a17cc92913c..3fe7be661e09 100644
--- a/scalability_and_performance/optimization/optimizing-storage.adoc
+++ b/scalability_and_performance/optimization/optimizing-storage.adoc
@@ -31,8 +31,3 @@ include::modules/recommended-configurable-storage-technology.adoc[leveloffset=+1
 include::modules/data-storage-management.adoc[leveloffset=+1]
 
 include::modules/optimizing-storage-azure.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-[id="admission-plug-ins-additional-resources"]
-== Additional resources
-* xref:../../observability/logging/log_storage/logging-config-es-store.adoc#logging-config-es-store[Configuring the Elasticsearch log store]
diff --git a/scalability_and_performance/recommended-performance-scale-practices/recommended-etcd-practices.adoc b/scalability_and_performance/recommended-performance-scale-practices/recommended-etcd-practices.adoc
index f5f533f5f049..dad385b5e419 100644
--- a/scalability_and_performance/recommended-performance-scale-practices/recommended-etcd-practices.adoc
+++ b/scalability_and_performance/recommended-performance-scale-practices/recommended-etcd-practices.adoc
@@ -21,6 +21,7 @@ include::modules/etcd-node-scaling.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 * link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2024/html/installing_openshift_container_platform_with_the_assisted_installer/expanding-the-cluster#adding-hosts-with-the-api_expanding-the-cluster[Adding hosts with the API]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-healthy-cluster_expanding-the-cluster[Installing a primary control plane node on a healthy cluster]
 * link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2024/html/installing_openshift_container_platform_with_the_assisted_installer/expanding-the-cluster#installing-control-plane-node-healthy-cluster_expanding-the-cluster[Expanding the cluster]
 * xref:../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]
 
diff --git a/scalability_and_performance/telco-core-rds.adoc b/scalability_and_performance/telco-core-rds.adoc
new file mode 100644
index 000000000000..14b00cb1ce19
--- /dev/null
+++ b/scalability_and_performance/telco-core-rds.adoc
@@ -0,0 +1,235 @@
+:_mod-docs-content-type: ASSEMBLY
+:telco-core:
+[id="telco-core-ref-design-specs"]
+= Telco core reference design specifications
+include::_attributes/common-attributes.adoc[]
+:context: telco-core
+
+toc::[]
+
+The telco core reference design specifications (RDS) configures an {product-title} cluster running on commodity hardware to host telco core workloads.
+
+include::modules/telco-core-rds-product-version-use-model-overview.adoc[leveloffset=+1]
+
+include::modules/telco-core-about-the-telco-core-cluster-use-model.adoc[leveloffset=+1]
+
+include::modules/telco-ran-core-ref-design-spec.adoc[leveloffset=+1]
+
+include::modules/telco-deviations-from-the-ref-design.adoc[leveloffset=+1]
+
+include::modules/telco-core-common-baseline-model.adoc[leveloffset=+1]
+
+include::modules/telco-core-cluster-common-use-model-engineering-considerations.adoc[leveloffset=+1]
+
+include::modules/telco-core-application-workloads.adoc[leveloffset=+2]
+
+include::modules/telco-core-signaling-workloads.adoc[leveloffset=+2]
+
+[id="telco-core-rds-components"]
+== Telco core RDS components
+
+The following sections describe the various {product-title} components and configurations that you use to configure and deploy clusters to run telco core workloads.
+
+include::modules/telco-core-cpu-partitioning-and-performance-tuning.adoc[leveloffset=+2]
+
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
+
+* xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
+
+* xref:../installing/install_config/enabling-cgroup-v1.adoc#nodes-clusters-cgroups-2-install_nodes-cluster-cgroups-1[Enabling Linux cgroup v1 during installation]
+
+include::modules/telco-core-service-mesh.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[About OpenShift Service Mesh]
+
+include::modules/telco-core-networking.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/understanding-networking.adoc#understanding-networking[Understanding networking]
+
+include::modules/telco-core-cluster-network-operator.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/networking_operators/cluster-network-operator.adoc#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator]
+
+include::modules/telco-core-load-balancer.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/networking_operators/metallb-operator/about-metallb.adoc#nw-metallb-when-metallb_about-metallb-and-metallb-operator[When to use MetalLB]
+
+include::modules/telco-core-sr-iov.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/hardware_networks/about-sriov.adoc#about-sriov[About Single Root I/O Virtualization (SR-IOV) hardware networks]
+
+* xref:../networking/hardware_networks/about-sriov.adoc#supported-devices_about-sriov[Supported devices]
+
+* xref:../networking/hardware_networks/configuring-sriov-device.html#nw-sriov-nic-mlx-secure-boot_configuring-sriov-device[Configuring the SR-IOV Network Operator on Mellanox cards when Secure Boot is enabled]
+
+include::modules/telco-core-nmstate-operator.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Kubernetes NMState Operator]
+
+include::modules/telco-core-logging.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.openshift.com/container-platform/4.17/observability/logging/logging-6.0/log6x-about.html[Logging 6.0]
+
+include::modules/telco-core-power-management.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../rest_api/node_apis/performanceprofile-performance-openshift-io-v2.adoc#spec-workloadhints[performance.openshift.io/v2 API reference]
+
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes]
+
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
+
+include::modules/telco-core-storage.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../storage/persistent_storage/persistent-storage-ocs.adoc#red-hat-openshift-data-foundation[{rh-storage-first}]
+
+include::modules/telco-core-openshift-data-foundation.adoc[leveloffset=+3]
+
+include::modules/telco-core-additional-storage-solutions.adoc[leveloffset=+3]
+
+[id="telco-reference-core-deployment-components_{context}"]
+=== Telco core deployment components
+
+The following sections describe the various {product-title} components and configurations that you use to configure the hub cluster with {rh-rhacm-first}.
+
+include::modules/telco-core-red-hat-advanced-cluster-management.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-deploying-far-edge-clusters-at-scale.adoc#about-ztp_ztp-deploying-far-edge-clusters-at-scale[Using {ztp} to provision clusters at the network far edge]
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes[Red Hat Advanced Cluster Management for Kubernetes]
+
+include::modules/telco-core-topology-aware-lifecycle-manager.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/cnf-talm-for-cluster-upgrades.adoc#cnf-talm-for-cluster-updates[Updating managed clusters with the {cgu-operator-full}]
+
+include::modules/telco-core-gitops-operator-and-ztp-plugins.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
+
+* xref:../edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
+
+include::modules/telco-core-monitoring.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+
+include::modules/telco-core-scheduling.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../scalability_and_performance/cnf-numa-aware-scheduling.adoc#installing-the-numa-resources-operator_numa-aware[Installing the NUMA Resources Operator]
+
+* xref:../scalability_and_performance/cnf-numa-aware-scheduling.adoc#cnf-numa-aware-scheduling[Scheduling NUMA-aware workloads]
+
+xref:../scalability_and_performance/using-cpu-manager.adoc#topology_manager_policies_using-cpu-manager-and-topology_manager[Topology Manager policies]
+
+include::modules/telco-core-node-configuration.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-du-enabling-kdump_sno-configure-for-vdu[Automatic kernel crash dumps with kdump]
+
+* xref:../scalability_and_performance/optimization/optimizing-cpu-usage.adoc#optimizing-cpu-usage[Optimizing CPU usage with mount namespace encapsulation]
+
+include::modules/telco-core-host-firmware-and-boot-loader-configuration.adoc[leveloffset=+2]
+
+include::modules/telco-core-disconnected-environment.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../disconnected/updating/index.adoc#about-disconnected-updates[About cluster updates in a disconnected environment]
+
+
+include::modules/telco-core-agent-based-installer.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing an {product-title} cluster with the Agent-based Installer]
+
+include::modules/telco-core-security.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../installing/install_config/configuring-firewall.adoc#configuring-firewall_configuring-firewall[Configuring your firewall for {product-title}]
+
+* xref:../installing/install_config/configuring-firewall.adoc#network-flow-matrix_configuring-firewall[{product-title} network flow matrix]
+
+* xref:../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing security context constraints]
+
+* xref:../machine_configuration/machine-config-node-disruption.adoc#machine-config-node-disruption_machine-configs-configure[Using node disruption policies to minimize disruption from machine config changes]
+
+include::modules/telco-core-scalability.adoc[leveloffset=+2]
+
+[id="telco-core-reference-configuration-crs"]
+== Telco core reference configuration CRs
+
+Use the following custom resources (CRs) to configure and deploy {product-title} clusters with the telco core profile.
+Use the CRs to form the common baseline used in all the specific use models unless otherwise indicated.
+
+include::modules/telco-core-rds-container.adoc[leveloffset=+2]
+
+include::modules/using-cluster-compare-telco-core.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc#understanding-the-cluster-compare-plugin[Understanding the cluster-compare plugin]
+
+include::modules/telco-core-crs-node-configuration.adoc[leveloffset=+2]
+
+include::modules/telco-core-crs-resource-tuning.adoc[leveloffset=+2]
+
+include::modules/telco-core-crs-networking.adoc[leveloffset=+2]
+
+include::modules/telco-core-crs-scheduling.adoc[leveloffset=+2]
+
+include::modules/telco-core-crs-storage.adoc[leveloffset=+2]
+
+include::modules/telco-core-software-stack.adoc[leveloffset=+1]
+
+:!telco-core:
diff --git a/scalability_and_performance/telco-ran-du-rds.adoc b/scalability_and_performance/telco-ran-du-rds.adoc
new file mode 100644
index 000000000000..fec711038de9
--- /dev/null
+++ b/scalability_and_performance/telco-ran-du-rds.adoc
@@ -0,0 +1,171 @@
+:_mod-docs-content-type: ASSEMBLY
+:telco-ran:
+[id="telco-ran-du-ref-design-specs"]
+= Telco RAN DU reference design specifications
+include::_attributes/common-attributes.adoc[]
+:context: telco-ran-du
+
+toc::[]
+
+The telco RAN DU reference design specifications (RDS) describes the configuration for clusters running on commodity hardware to host 5G workloads in the Radio Access Network (RAN).
+It captures the recommended, tested, and supported configurations to get reliable and repeatable performance for a cluster running the telco RAN DU profile.
+
+include::modules/telco-ref-design-overview.adoc[leveloffset=+1]
+
+include::modules/telco-ran-core-ref-design-spec.adoc[leveloffset=+1]
+
+include::modules/telco-deviations-from-the-ref-design.adoc[leveloffset=+1]
+
+include::modules/telco-ran-engineering-considerations-for-the-ran-du-use-model.adoc[leveloffset=+1]
+
+include::modules/telco-ran-du-application-workloads.adoc[leveloffset=+1]
+
+include::modules/telco-ran-du-reference-design-components.adoc[leveloffset=+1]
+
+include::modules/telco-ran-bios-tuning.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-deploying-far-edge-sites.adoc#ztp-configuring-host-firmware-with-gitops-ztp_ztp-deploying-far-edge-sites[Managing host firmware settings with {ztp}]
+
+* xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
+
+* xref:../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#cnf-provisioning-low-latency-workloads[Provisioning real-time and low latency workloads]
+
+include::modules/telco-ran-node-tuning-operator.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#about_irq_affinity_setting_cnf-low-latency-perf-profile[Finding the effective IRQ affinity setting for a node]
+
+include::modules/telco-ran-ptp-operator.adoc[leveloffset=+2]
+
+include::modules/telco-ran-sr-iov-operator.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../networking/hardware_networks/about-sriov.adoc#supported-devices_about-sriov[Supported devices]
+
+* xref:../networking/hardware_networks/configuring-sriov-qinq-support.adoc#configuring-qinq-support[Configuring QinQ support for SR-IOV enabled workloads]
+
+include::modules/telco-ran-logging.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://docs.openshift.com/container-platform/4.17/observability/logging/logging-6.0/log6x-about.html[Logging 6.0]
+
+include::modules/telco-ran-sriov-fec-operator.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* link:https://catalog.redhat.com/software/containers/intel/sriov-fec-operator/6017de1669aea3122e6fa15f[SRIOV-FEC Operator for Intel® vRAN Dedicated Accelerator manager container]
+
+include::modules/telco-ran-lca-operator.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/image_based_upgrade/cnf-understanding-image-based-upgrade.adoc#cnf-understanding-image-based-upgrade[Understanding the image-based upgrade for {sno} clusters]
+
+* xref:../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition.adoc#ztp-image-based-upgrade-shared-container-partition_shared-container-partition[Configuring a shared container directory between ostree stateroots when using {ztp}]
+
+include::modules/telco-ran-local-storage-operator.adoc[leveloffset=+2]
+
+include::modules/telco-ran-lvms-operator.adoc[leveloffset=+2]
+
+include::modules/telco-ran-workload-partitioning.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../scalability_and_performance/enabling-workload-partitioning.adoc#enabling-workload-partitioning[Workload partitioning]
+
+include::modules/telco-ran-cluster-tuning.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities]
+
+include::modules/telco-ran-machine-configuration.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-install-time-cluster-config[Recommended {sno} cluster configuration for vDU application workloads].
+
+[id="telco-ran-du-deployment-components"]
+== Telco RAN DU deployment components
+
+The following sections describe the various {product-title} components and configurations that you use to configure the hub cluster with {rh-rhacm}.
+
+include::modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-deploying-far-edge-clusters-at-scale.adoc#about-ztp_ztp-deploying-far-edge-clusters-at-scale[Using {ztp} to provision clusters at the network far edge]
+
+* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes[Red Hat Advanced Cluster Management for Kubernetes]
+
+include::modules/telco-ran-siteconfig-operator.adoc[leveloffset=+2]
+
+include::modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/cnf-talm-for-cluster-upgrades.adoc#cnf-talm-for-cluster-updates[Updating managed clusters with the {cgu-operator-full}]
+
+include::modules/telco-ran-gitops-operator-and-ztp-plugins.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
+
+* xref:../edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
+
+include::modules/telco-ran-agent-based-installer-abi.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing an {product-title} cluster with the Agent-based Installer]
+
+[id="telco-ran-du-reference-configuration-crs"]
+== Telco RAN DU reference configuration CRs
+
+Use the following custom resources (CRs) to configure and deploy {product-title} clusters with the telco RAN DU profile.
+Use the CRs to form the common baseline used in all the specific use models unless otherwise indicated.
+
+[NOTE]
+====
+You can extract the complete set of RAN DU CRs from the `ztp-site-generate` container image.
+See xref:../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository] for more information.
+====
+
+include::modules/telco-ran-crs-cluster-tuning.adoc[leveloffset=+2]
+
+include::modules/telco-ran-crs-day-2-operators.adoc[leveloffset=+2]
+
+include::modules/telco-ran-crs-machine-configuration.adoc[leveloffset=+2]
+
+:context: ran-ref-design-crs
+include::modules/using-cluster-compare-telco-ran.adoc[leveloffset=+1]
+:context: telco-ran-du
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc#understanding-the-cluster-compare-plugin[Understanding the cluster-compare plugin]
+
+include::modules/ztp-telco-ran-software-versions.adoc[leveloffset=+1]
+
+include::modules/ztp-telco-hub-cluster-software-versions.adoc[leveloffset=+1]
+
+:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc b/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc
deleted file mode 100644
index e72c31dfa2de..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-core:
-:context: core-ref-design-overview
-include::_attributes/common-attributes.adoc[]
-[id="telco-core-ref-design-overview"]
-= {rds-caps} {product-version} reference design overview
-
-toc::[]
-
-The {rds} reference design specification (RDS) configures an {product-title} cluster running on commodity hardware to host {rds} workloads.
-
-include::modules/telco-core-cluster-service-based-architecture-and-networking-topology.adoc[leveloffset=+1]
-
-:!telco-core:
diff --git a/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc b/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc
deleted file mode 100644
index 98c7e8d073c4..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-core:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-rds-overview"]
-= {rds-caps} {product-version} use model overview
-:context: ran-core-design-overview
-
-toc::[]
-
-{rds-caps} clusters are configured as standard three control plane clusters with worker nodes configured with the stock non real-time (RT) kernel.
-
-To support workloads with varying networking and performance requirements, worker nodes are segmented using `MachineConfigPool` CRs. For example, this is done to separate non-user data plane nodes from high-throughput nodes. To support the required telco operational features, the clusters have a standard set of Operator Lifecycle Manager (OLM) Day 2 Operators installed.
-
-The networking prerequisites for {rds} functions are diverse and encompass an array of networking attributes and performance benchmarks.
-IPv6 is mandatory, with dual-stack configurations being prevalent. Certain functions demand maximum throughput and transaction rates, necessitating user plane networking support such as DPDK. Other functions adhere to conventional cloud-native patterns and can use solutions such as OVN-K, kernel networking, and load balancing.
-
-
-
-.Telco core use model architecture
-image:473_OpenShift_Telco_Core_Reference_arch_1123.png[Use model architecture]
-
-include::modules/telco-core-ref-design-baseline-model.adoc[leveloffset=+1]
-
-include::modules/telco-core-ref-eng-usecase-model.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc#telco-core-cpu-partitioning-performance-tune_core-ref-design-components[CPU partitioning and performance tuning]
-
-include::modules/telco-core-ref-application-workloads.adoc[leveloffset=+2]
-
-:!telco-core:
diff --git a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc b/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
deleted file mode 100644
index d0c7b7750145..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
+++ /dev/null
@@ -1,48 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-core:
-include::_attributes/common-attributes.adoc[]
-[id="telco-core-ref-du-crs"]
-= {rds-caps} {product-version} reference configuration CRs
-:context: ran-core-ref-design-crs
-
-toc::[]
-
-Use the following custom resources (CRs) to configure and deploy {product-title} clusters with the {rds} profile.
-Use the CRs to form the common baseline used in all the specific use models unless otherwise indicated.
-
-include::modules/telco-core-rds-container.adoc[leveloffset=+1]
-
-include::modules/using-cluster-compare-telco-ref.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../../scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc#understanding-the-cluster-compare-plugin[Understanding the cluster-compare plugin]
-
-include::modules/telco-core-crs-networking.adoc[leveloffset=+1]
-
-include::modules/telco-core-crs-node-configuration.adoc[leveloffset=+1]
-
-include::modules/telco-core-crs-other.adoc[leveloffset=+1]
-
-include::modules/telco-core-crs-resource-tuning.adoc[leveloffset=+1]
-
-include::modules/telco-core-crs-scheduling.adoc[leveloffset=+1]
-
-include::modules/telco-core-crs-storage.adoc[leveloffset=+1]
-
-[id="telco-reference-core-use-case-yaml_{context}"]
-== YAML reference
-
-include::modules/telco-core-yaml-ref-networking.adoc[leveloffset=+2]
-
-include::modules/telco-core-yaml-ref-node-configuration.adoc[leveloffset=+2]
-
-include::modules/telco-core-yaml-ref-other.adoc[leveloffset=+2]
-
-include::modules/telco-core-yaml-ref-resource-tuning.adoc[leveloffset=+2]
-
-include::modules/telco-core-yaml-ref-scheduling.adoc[leveloffset=+2]
-
-include::modules/telco-core-yaml-ref-storage.adoc[leveloffset=+2]
-
-:!telco-core:
diff --git a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc b/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
deleted file mode 100644
index 7583c18ed643..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+++ /dev/null
@@ -1,181 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-core:
-include::_attributes/common-attributes.adoc[]
-[id="telco-core-ref-components"]
-= {rds-caps} reference design components
-:context: core-ref-design-components
-
-toc::[]
-
-The following sections describe the various {product-title} components and configurations that you use to configure and deploy clusters to run {rds} workloads.
-
-include::modules/telco-core-cpu-partitioning-performance-tune.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
-
-* xref:../../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
-
-* xref:../../../installing/install_config/enabling-cgroup-v1.adoc#nodes-clusters-cgroups-2-install_nodes-cluster-cgroups-1[Enabling Linux cgroup v1 during installation]
-
-include::modules/telco-core-service-mesh.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../service_mesh/v2x/ossm-about.adoc#ossm-about[About OpenShift Service Mesh]
-
-include::modules/telco-core-rds-networking.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../networking/understanding-networking.adoc#understanding-networking[Understanding networking]
-
-include::modules/telco-core-cluster-network-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../networking/networking_operators/cluster-network-operator.adoc#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator]
-
-include::modules/telco-core-load-balancer.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../networking/networking_operators/metallb-operator/about-metallb.adoc#nw-metallb-when-metallb_about-metallb-and-metallb-operator[When to use MetalLB]
-
-include::modules/telco-core-sriov.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../networking/hardware_networks/about-sriov.adoc#about-sriov[About Single Root I/O Virtualization (SR-IOV) hardware networks]
-
-* xref:../../../networking/hardware_networks/about-sriov.adoc#supported-devices_about-sriov[Supported devices]
-
-include::modules/telco-nmstate-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Kubernetes NMState Operator]
-
-include::modules/telco-core-logging.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../observability/logging/logging-6.0/log6x-about.adoc#log6x-about[About logging]
-
-include::modules/telco-core-power-management.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../rest_api/node_apis/performanceprofile-performance-openshift-io-v2.adoc#spec-workloadhints[Performance Profile]
-
-* xref:../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes]
-
-* xref:../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
-
-include::modules/telco-core-storage.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../storage/persistent_storage/persistent-storage-ocs.adoc#red-hat-openshift-data-foundation[{rh-storage-first}]
-
-[id="telco-reference-core-deployment-components_{context}"]
-== {rds-caps} deployment components
-
-The following sections describe the various {product-title} components and configurations that you use to configure the hub cluster with {rh-rhacm-first}.
-
-include::modules/telco-core-red-hat-advanced-cluster-management-rhacm.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-deploying-far-edge-clusters-at-scale.adoc#about-ztp_ztp-deploying-far-edge-clusters-at-scale[Using {ztp} to provision clusters at the network far edge]
-
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes[Red Hat Advanced Cluster Management for Kubernetes]
-
-include::modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/cnf-talm-for-cluster-upgrades.adoc#cnf-talm-for-cluster-updates[Updating managed clusters with the {cgu-operator-full}]
-
-include::modules/telco-ran-gitops-operator-and-ztp-plugins.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
-
-* xref:../../../edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
-
-include::modules/telco-core-agent-based-installer-abi.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing an {product-title} cluster with the Agent-based Installer]
-
-include::modules/telco-core-monitoring.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../observability/monitoring/monitoring-overview.adoc#about-openshift-monitoring[About {product-version} monitoring]
-
-include::modules/telco-core-scheduling.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../nodes/scheduling/nodes-scheduler-about.adoc#nodes-scheduler-about[Controlling pod placement using the scheduler]
-
-* xref:../../../scalability_and_performance/cnf-numa-aware-scheduling.adoc#cnf-numa-aware-scheduling[Scheduling NUMA-aware workloads]
-
-* xref:../../../scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc#telco-core-cpu-partitioning-performance-tune_core-ref-design-components[CPU partitioning and performance tuning]
-
-include::modules/telco-core-node-configuration.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-du-enabling-kdump_sno-configure-for-vdu[Automatic kernel crash dumps with kdump]
-
-* xref:../../../scalability_and_performance/optimization/optimizing-cpu-usage.adoc#optimizing-cpu-usage[Optimizing CPU usage with mount namespace encapsulation]
-
-include::modules/telco-core-host-firmware-bootloader.adoc[leveloffset=+1]
-
-include::modules/telco-core-rds-disconnected.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../disconnected/updating/index.adoc#about-disconnected-updates[About cluster updates in a disconnected environment]
-
-include::modules/telco-core-security.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing security context constraints]
-
-* xref:../../../scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc#telco-core-host-firmware-and-bootloader-configuration_core-ref-design-components[Host firmware and boot loader configuration]
-
-include::modules/telco-core-scalability.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-use-cases.adoc#telco-core-ref-eng-usecase-model_ran-core-design-overview[{rds-caps} RDS engineering considerations]
-
-:!telco-core:
diff --git a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-software-artifacts.adoc b/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-software-artifacts.adoc
deleted file mode 100644
index 071d6d453fe7..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-software-artifacts.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="telco-core-ref-software-artifacts"]
-= Telco core reference configuration software specifications
-:context: core-ref-design-validation
-include::_attributes/common-attributes.adoc[]
-
-toc::[]
-
-The following information describes the telco core reference design specification (RDS) validated software versions.
-
-include::modules/telco-core-software-stack.adoc[leveloffset=+1]
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc b/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
deleted file mode 100644
index 81b9eb9219c0..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-du-overview.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-ran:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-du-overview"]
-= {rds-caps} use model overview
-:context: ran-ref-design-overview
-
-toc::[]
-
-Use the following information to plan {rds} workloads, cluster resources, and hardware specifications for the hub cluster and managed {sno} clusters.
-
-include::modules/telco-ran-du-application-workloads.adoc[leveloffset=+1]
-
-include::modules/telco-reference-application-workload-characteristics.adoc[leveloffset=+1]
-
-include::modules/telco-ran-managed-cluster-resources.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.adoc#ztp-telco-ran-software-versions_ran-ref-design-validation[Telco RAN DU {product-version} validated software components]
-
-include::modules/telco-ran-hub-cluster-management.adoc[leveloffset=+1]
-
-include::modules/telco-ran-du-reference-components.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For details of the telco RAN RDS KPI test results, see link:https://access.redhat.com/articles/7089662[Telco RAN DU 4.17 reference design specification KPI test results].
-This information is only available to customers and partners.
-
-:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc b/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
deleted file mode 100644
index f7232abd07f4..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-ran:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-ref-design-spec"]
-= {rds-caps} {product-version} reference design overview
-:context: ran-ref-design-spec
-
-toc::[]
-
-The {rds-first} {product-version} reference design configures an {product-title} {product-version} cluster running on commodity hardware to host {rds} workloads.
-It captures the recommended, tested, and supported configurations to get reliable and repeatable performance for a cluster running the {rds} profile.
-
-// Removing this because we already highlight what is new in the components section.
-//include::modules/telco-ran-ref-design-features.adoc[leveloffset=+1]
-
-include::modules/telco-ran-architecture-overview.adoc[leveloffset=+1]
-
-:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc b/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
deleted file mode 100644
index 8249fb024704..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
+++ /dev/null
@@ -1,131 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-ran:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-ref-du-components"]
-= {rds-caps} {product-version} reference design components
-:context: ran-ref-design-components
-
-toc::[]
-
-The following sections describe the various {product-title} components and configurations that you use to configure and deploy clusters to run RAN DU workloads.
-
-include::modules/telco-ran-bios-tuning.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-deploying-far-edge-sites.adoc#ztp-configuring-host-firmware-with-gitops-ztp_ztp-deploying-far-edge-sites[Managing host firmware settings with {ztp}]
-
-* xref:../../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
-
-* xref:../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-create-performance-profiles[Creating a performance profile]
-
-include::modules/telco-ran-node-tuning-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#about_irq_affinity_setting_cnf-low-latency-perf-profile[Finding the effective IRQ affinity setting for a node]
-
-include::modules/telco-ran-ptp-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-du-configuring-ptp_sno-configure-for-vdu[Recommended PTP {sno} cluster configuration for vDU application workloads]
-
-include::modules/telco-ran-sr-iov-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
-
-* xref:../../../networking/hardware_networks/configuring-sriov-qinq-support.adoc#configuring-qinq-support[Configuring QinQ support for SR-IOV enabled workloads]
-
-include::modules/telco-ran-logging.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../observability/logging/logging-6.0/log6x-about.adoc#log6x-about[About logging]
-
-include::modules/telco-ran-sriov-fec-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* link:https://catalog.redhat.com/software/containers/intel/sriov-fec-operator/6017de1669aea3122e6fa15f[SRIOV-FEC Operator for Intel® vRAN Dedicated Accelerator manager container]
-
-include::modules/telco-ran-lca-operator.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/image_based_upgrade/cnf-understanding-image-based-upgrade.adoc#cnf-understanding-image-based-upgrade[Understanding the image-based upgrade for {sno} clusters]
-
-* xref:../../../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition.adoc#ztp-image-based-upgrade-shared-container-partition_shared-container-partition[Configuring a shared container directory between ostree stateroots when using {ztp}]
-
-include::modules/telco-ran-local-storage-operator.adoc[leveloffset=+1]
-
-include::modules/telco-ran-lvms-operator.adoc[leveloffset=+1]
-
-include::modules/telco-ran-workload-partitioning.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../scalability_and_performance/enabling-workload-partitioning.adoc#enabling-workload-partitioning[Workload partitioning]
-
-include::modules/telco-ran-cluster-tuning.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities]
-
-include::modules/telco-ran-machine-configuration.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-install-time-cluster-config[Recommended {sno} cluster configuration for vDU application workloads].
-
-[id="telco-reference-ran-du-deployment-components_{context}"]
-== {rds-caps} deployment components
-
-The following sections describe the various {product-title} components and configurations that you use to configure the hub cluster with {rh-rhacm-first}.
-
-include::modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-deploying-far-edge-clusters-at-scale.adoc#about-ztp_ztp-deploying-far-edge-clusters-at-scale[Using {ztp} to provision clusters at the network far edge]
-
-* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes[Red Hat Advanced Cluster Management for Kubernetes]
-
-include::modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/cnf-talm-for-cluster-upgrades.adoc#cnf-talm-for-cluster-updates[Updating managed clusters with the {cgu-operator-full}]
-
-include::modules/telco-ran-gitops-operator-and-ztp-plugins.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
-
-* xref:../../../edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
-
-include::modules/telco-ran-agent-based-installer-abi.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc#installing-with-agent-based-installer[Installing an {product-title} cluster with the Agent-based Installer]
-
-:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc b/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
deleted file mode 100644
index 19e99ddf7aeb..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-ran:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-ref-du-crs"]
-= {rds-first} reference configuration CRs
-:context: ran-ref-design-crs
-
-toc::[]
-
-Use the following custom resources (CRs) to configure and deploy {product-title} clusters with the {rds} profile.
-Some of the CRs are optional depending on your requirements.
-CR fields you can change are annotated in the CR with YAML comments.
-
-[NOTE]
-====
-You can extract the complete set of RAN DU CRs from the `ztp-site-generate` container image.
-See xref:../../../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository] for more information.
-====
-
-include::modules/using-cluster-compare-telco-ref.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-* xref:../../../scalability_and_performance/cluster-compare/understanding-the-cluster-compare-plugin.adoc#understanding-the-cluster-compare-plugin[Understanding the cluster-compare plugin]
-
-include::modules/telco-ran-crs-day-2-operators.adoc[leveloffset=+1]
-
-include::modules/telco-ran-crs-cluster-tuning.adoc[leveloffset=+1]
-
-include::modules/telco-ran-crs-machine-configuration.adoc[leveloffset=+1]
-
-[id="telco-reference-ran-du-use-case-yaml_{context}"]
-== YAML reference
-
-The following is a complete reference for all the custom resources (CRs) that make up the {rds} {product-version} reference configuration.
-
-include::modules/telco-ran-yaml-ref-day-2-operators.adoc[leveloffset=+2]
-
-include::modules/telco-ran-yaml-ref-cluster-tuning.adoc[leveloffset=+2]
-
-include::modules/telco-ran-yaml-ref-machine-configuration.adoc[leveloffset=+2]
-
-:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.adoc b/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.adoc
deleted file mode 100644
index 4ebf1477d7fb..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/ran/telco-ran-ref-software-artifacts.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-:telco-ran:
-include::_attributes/common-attributes.adoc[]
-[id="telco-ran-ref-software-artifacts"]
-= {rds-caps} reference configuration software specifications
-:context: ran-ref-design-validation
-
-toc::[]
-
-The following information describes the telco RAN DU reference design specification (RDS) validated software versions.
-
-include::modules/ztp-telco-ran-software-versions.adoc[leveloffset=+1]
-
-:!telco-ran:
diff --git a/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc b/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc
deleted file mode 100644
index 7fff8bfaeeb3..000000000000
--- a/scalability_and_performance/telco_ref_design_specs/telco-ref-design-specs-overview.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="telco-ref-design-specs-overview"]
-= Telco core and RAN DU reference design specifications
-:context: telco_ref_design_specs
-include::_attributes/common-attributes.adoc[]
-
-toc::[]
-
-The telco core reference design specification (RDS) describes {product-title} {product-version} clusters running on commodity hardware that can support large scale telco applications including control plane and some centralized data plane functions.
-
-The telco RAN RDS describes the configuration for clusters running on commodity hardware to host 5G workloads in the Radio Access Network (RAN).
-
-include::modules/telco-ref-design-overview.adoc[leveloffset=+1]
-
-include::modules/telco-ran-core-ref-design-spec.adoc[leveloffset=+1]
-
-include::modules/telco-deviations-from-the-ref-design.adoc[leveloffset=+1]
diff --git a/scalability_and_performance/using-node-tuning-operator.adoc b/scalability_and_performance/using-node-tuning-operator.adoc
index 538cf4881d4c..4bbfc510336b 100644
--- a/scalability_and_performance/using-node-tuning-operator.adoc
+++ b/scalability_and_performance/using-node-tuning-operator.adoc
@@ -21,6 +21,10 @@ include::modules/custom-tuning-specification.adoc[leveloffset=+1]
 
 include::modules/custom-tuning-example.adoc[leveloffset=+1]
 
+include::modules/defer-applicaton-tuning-example.adoc[leveloffset=+1]
+
+include::modules/defer-application-tuning-proc.adoc[leveloffset=+2]
+
 include::modules/node-tuning-operator-supported-tuned-daemon-plug-ins.adoc[leveloffset=+1]
 
 include::modules/node-tuning-hosted-cluster.adoc[leveloffset=+1]
diff --git a/security/audit-log-view.adoc b/security/audit-log-view.adoc
index 4a29965d3ba4..5d79176fe799 100644
--- a/security/audit-log-view.adoc
+++ b/security/audit-log-view.adoc
@@ -22,7 +22,8 @@ include::modules/security-audit-log-filtering.adoc[leveloffset=+1]
 
 // Gathering audit logs
 include::modules/gathering-data-audit-logs.adoc[leveloffset=+1]
-
+//removed xrefs for hcp migration local test builds. Will update conditionals once hcp docs can be tested with live builds.
+ifndef::openshift-rosa-hcp[]
 [id="viewing-audit-logs-additional-resources"]
 [role="_additional-resources"]
 == Additional resources
@@ -32,5 +33,3 @@ ifndef::openshift-rosa,openshift-dedicated[]
 * link:https://github.com/kubernetes/apiserver/blob/master/pkg/apis/audit/v1/types.go#L72[API audit log event structure]
 * xref:../security/audit-log-policy-config.adoc#audit-log-policy-config[Configuring the audit log policy]
 endif::[]
-* xref:../observability/logging/log_collection_forwarding/log-forwarding.adoc#log-forwarding[About log forwarding]
-
diff --git a/security/cert_manager_operator/cert-manager-monitoring.adoc b/security/cert_manager_operator/cert-manager-monitoring.adoc
index 753cbb66ba48..f5779982f0ac 100644
--- a/security/cert_manager_operator/cert-manager-monitoring.adoc
+++ b/security/cert_manager_operator/cert-manager-monitoring.adoc
@@ -14,7 +14,7 @@ include::modules/cert-manager-enable-metrics.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../observability/monitoring/managing-metrics.adoc#setting-up-metrics-collection-for-user-defined-projects_managing-metrics[Setting up metrics collection for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#setting-up-metrics-collection-for-user-defined-projects_configuring-metrics-uwm[Setting up metrics collection for user-defined projects]
 
 // Querying metrics for the {cert-manager-operator}
 include::modules/cert-manager-query-metrics.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc b/security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
new file mode 100644
index 000000000000..cfaf8bc15c03
--- /dev/null
+++ b/security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
@@ -0,0 +1,37 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="cert-manager-operator-integrating-istio"]
+= Integrating the {cert-manager-operator} with Istio-CSR
+include::_attributes/common-attributes.adoc[]
+:context: cert-manager-operator-integrating-istio
+
+toc::[]
+
+:FeatureName: Istio-CSR integration for {cert-manager-operator}
+include::snippets/technology-preview.adoc[]
+
+The {cert-manager-operator} provides enhanced support for securing workloads and control plane components in {SMProductName} or Istio. This includes support for certificates enabling mutual TLS (mTLS), which are signed, delivered, and renewed using cert-manager issuers. You can secure Istio workloads and control plane components by using the {cert-manager-operator} managed Istio-CSR agent.
+
+With this Istio-CSR integration, Istio can now obtain certificates from the {cert-manager-operator}, simplifying security and certificate management.
+
+[id="cert-manager-operator-istio-csr-installing_{context}"]
+== Installing the Istio-CSR agent through {cert-manager-operator}
+
+// Enabling Istio-CSR
+include::modules/cert-manager-enabling-istio.adoc[leveloffset=+2]
+
+// Creating issuer
+include::modules/cert-manager-istio-creating-issuer.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../security/cert_manager_operator/index.adoc#cert-manager-issuer-types_cert-manager-operator-about[{cert-manager-operator} issuer providers]
+
+// Installing using Istio-CSR
+include::modules/cert-manager-istio-csr-installing.adoc[leveloffset=+2]
+
+// Uninstalling cert-manager Operator with Istio-CSR
+include::modules/cert-manager-istio-csr-uninstalling.adoc[leveloffset=+1]
+
+// Updating Istio-CSR 
+include::modules/cert-manager-istio-csr-updating.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/security/cert_manager_operator/cert-manager-operator-release-notes.adoc b/security/cert_manager_operator/cert-manager-operator-release-notes.adoc
index 4864ede59e9e..590e2e6499a7 100644
--- a/security/cert_manager_operator/cert-manager-operator-release-notes.adoc
+++ b/security/cert_manager_operator/cert-manager-operator-release-notes.adoc
@@ -12,6 +12,36 @@ These release notes track the development of {cert-manager-operator}.
 
 For more information, see xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[About the {cert-manager-operator}].
 
+[id="cert-manager-operator-release-notes-1-15-1_{context}"]
+== {cert-manager-operator} 1.15.1
+
+Issued: 2025-03-13
+
+The following advisories are available for the {cert-manager-operator} 1.15.1:
+
+* link:https://access.redhat.com/errata/RHBA-2025:2733[RHEA-2025-2733]
+* link:https://access.redhat.com/errata/RHBA-2025:2780[RHEA-2025-2780]
+* link:https://access.redhat.com/errata/RHBA-2025:2821[RHEA-2025-2821]
+* link:https://access.redhat.com/errata/RHBA-2025:2828[RHEA-2025-2828]
+
+Version `1.15.1` of the {cert-manager-operator} is based on the upstream cert-manager version `v1.15.5`. For more information, see the link:https://cert-manager.io/docs/releases/release-notes/release-notes-1.15/#v1155[cert-manager project release notes for v1.15.5].
+
+[id="cert-manager-operator-1-15-1-features-enhancements_{context}"]
+=== New features and enhancements
+
+*Integrating the {cert-manager-operator} with Istio-CSR* (Technology Preview)
+
+The {cert-manager-operator} now supports the Istio-CSR. With this integration, cert-manager Operator's issuers can issue, sign, and renew certificates for mutual TLS (mTLS) communication. {SMProductName} and `Istio` can now request these certificates directly from the cert-manager Operator.
+
+For more information, see xref:../../security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc#cert-manager-operator-istio-csr-installing_cert-manager-operator-integrating-istio[Integrating the cert-manager Operator with Istio-CSR].
+
+[id="cert-manager-operator-1-15-1-CVEs_{context}"]
+=== CVEs
+
+* link:https://access.redhat.com/security/cve/CVE-2024-9287[CVE-2024-9287]
+* link:https://github.com/advisories/GHSA-7wrw-r4p8-38rx[CVE-2024-45336]
+* link:https://github.com/advisories/GHSA-3f6r-qh9c-x6mm[CVE-2024-45341]
+
 [id="cert-manager-operator-release-notes-1-15-0_{context}"]
 == {cert-manager-operator} 1.15.0
 
diff --git a/security/cert_manager_operator/cert-manager-operator-uninstall.adoc b/security/cert_manager_operator/cert-manager-operator-uninstall.adoc
index 7b41223b021d..8e5976ddaa7c 100644
--- a/security/cert_manager_operator/cert-manager-operator-uninstall.adoc
+++ b/security/cert_manager_operator/cert-manager-operator-uninstall.adoc
@@ -12,4 +12,4 @@ You can remove the {cert-manager-operator} from {product-title} by uninstalling
 include::modules/cert-manager-uninstall-console.adoc[leveloffset=+1]
 
 // Removing {cert-manager-operator} resources
-include::modules/cert-manager-remove-resources-console.adoc[leveloffset=+1]
+include::modules/cert-manager-remove-resources-console.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/security/certificate_types_descriptions/olm-certificates.adoc b/security/certificate_types_descriptions/olm-certificates.adoc
index 4397037684c3..72524ee6034d 100644
--- a/security/certificate_types_descriptions/olm-certificates.adoc
+++ b/security/certificate_types_descriptions/olm-certificates.adoc
@@ -13,3 +13,18 @@ All certificates for Operator Lifecycle Manager (OLM) components (`olm-operator`
 When installing Operators that include webhooks or API services in their `ClusterServiceVersion` (CSV) object, OLM creates and rotates the certificates for these resources. Certificates for resources in the `openshift-operator-lifecycle-manager` namespace are managed by OLM.
 
 OLM will not update the certificates of Operators that it manages in proxy environments. These certificates must be managed by the user using the subscription config.
+
+[role="_additional-resources"]
+.Next steps
+
+* xref:../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[Configuring proxy support in Operator Lifecycle Manager]
+
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* xref:../../security/certificate_types_descriptions/proxy-certificates.adoc#cert-types-proxy-certificates[Proxy certificates]
+* xref:../../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Replacing the default ingress certificate]
+* xref:../../security/certificates/updating-ca-bundle.adoc#updating-ca-bundle[Updating the CA bundle]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/security/certificates/api-server.adoc b/security/certificates/api-server.adoc
index 425fd4347aab..890539b762f3 100644
--- a/security/certificates/api-server.adoc
+++ b/security/certificates/api-server.adoc
@@ -11,4 +11,9 @@ cluster CA. Clients outside of the cluster will not be able to verify the
 API server's certificate by default. This certificate can be replaced
 by one that is issued by a CA that clients trust.
 
-include::modules/customize-certificates-api-add-named.adoc[leveloffset=+1]
+[NOTE]
+====
+In hosted control plane clusters, you cannot replace self-signed certificates from the API.
+====
+
+include::modules/customize-certificates-api-add-named.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/security/compliance_operator/compliance-operator-release-notes.adoc b/security/compliance_operator/compliance-operator-release-notes.adoc
index 694ceb217aa4..f1b0e41fc3eb 100644
--- a/security/compliance_operator/compliance-operator-release-notes.adoc
+++ b/security/compliance_operator/compliance-operator-release-notes.adoc
@@ -17,6 +17,15 @@ To access the latest release, see xref:../../security/compliance_operator/co-man
 
 For more information on compliance support for all Red{nbsp}Hat products, see link:https://access.redhat.com/compliance[Product Compliance].
 
+[id="compliance-operator-release-notes-1-6-2_{context}"]
+== OpenShift Compliance Operator 1.6.2
+
+The following advisory is available for the OpenShift Compliance Operator 1.6.2:
+
+* link:https://access.redhat.com/errata/RHBA-2025:2659[RHBA-2025:2659 - OpenShift Compliance Operator 1.6.2 update]
+
+CVE-2024-45338 is resolved in the Compliance Operator 1.6.2 release. (link:https://access.redhat.com/security/cve/cve-2024-45338[*CVE-2024-45338*])
+
 [id="compliance-operator-release-notes-1-6-1_{context}"]
 == OpenShift Compliance Operator 1.6.1
 
diff --git a/security/container_security/security-monitoring.adoc b/security/container_security/security-monitoring.adoc
index d0e32f473c2b..019864a17d3b 100644
--- a/security/container_security/security-monitoring.adoc
+++ b/security/container_security/security-monitoring.adoc
@@ -25,5 +25,5 @@ include::modules/security-monitoring-audit-logging.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../nodes/clusters/nodes-containers-events.adoc#nodes-containers-events[List of system events]
-* xref:../../observability/logging/cluster-logging.adoc#cluster-logging[Understanding OpenShift Logging]
+//* xref :../../observability/logging/cluster-logging.adoc#cluster-logging[Understanding OpenShift Logging]
 * xref:../../security/audit-log-view.adoc#audit-log-view[Viewing audit logs]
diff --git a/security/nbde_tang_server_operator/nbde-tang-server-operator-release-notes.adoc b/security/nbde_tang_server_operator/nbde-tang-server-operator-release-notes.adoc
index 3000d81d3649..beeadec416cc 100644
--- a/security/nbde_tang_server_operator/nbde-tang-server-operator-release-notes.adoc
+++ b/security/nbde_tang_server_operator/nbde-tang-server-operator-release-notes.adoc
@@ -14,4 +14,4 @@ link:https://access.redhat.com/errata/RHEA-2023:7491[RHEA-2023:7491]:: The NBDE
 link:https://access.redhat.com/errata/RHEA-2024:0854[RHEA-2024:0854]:: The NBDE Tang Server Operator 1.0.1 has been moved from the `alpha` channel to the `stable` channel.
 link:https://access.redhat.com/errata/RHBA-2024:8681[RHBA-2024:8681]:: The 1.0.2 update contains fixes that increase the Container Health Index of containers deployed with the NBDE Tang Server Operator to the highest grade.
 link:https://access.redhat.com/errata/RHEA-2024:10970[RHEA-2024:10970]:: The 1.0.3 update contains changes that re-increase the Container Health Index to the highest grade.
-link:https://access.redhat.com/errata/RHBA-2025:0533[RHBA-2025:0533]:: With the NBDE Tang Server Operator 1.1, the `golang` package is provided in version 1.23.2 and the `golang.org/x/net/html` package has been updated to version 0.33.0. The updates increase the Container Health Index.
+link:https://access.redhat.com/errata/RHBA-2025:0663[RHBA-2025:0663]:: With the NBDE Tang Server Operator 1.1, the `golang` package is provided in version 1.23.2 and the `golang.org/x/net/html` package has been updated to version 0.33.0. The updates increase the Container Health Index.
diff --git a/serverless/observability/admin-metrics/serverless-admin-metrics.adoc b/serverless/observability/admin-metrics/serverless-admin-metrics.adoc
index d5b8bc8eb40a..ccf48f34a8a7 100644
--- a/serverless/observability/admin-metrics/serverless-admin-metrics.adoc
+++ b/serverless/observability/admin-metrics/serverless-admin-metrics.adoc
@@ -20,7 +20,7 @@ endif::[]
 == Prerequisites
 
 ifdef::openshift-enterprise[]
-* See the {product-title} documentation on xref:../../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics] for information about enabling metrics for your cluster.
+* See the {product-title} documentation on xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[Accessing metrics as an administrator] for information about enabling metrics for your cluster.
 
 * You have access to an {product-title} account with cluster administrator access.
 endif::[]
diff --git a/serverless/observability/developer-metrics/serverless-developer-metrics.adoc b/serverless/observability/developer-metrics/serverless-developer-metrics.adoc
index 53998b954f38..65f165738744 100644
--- a/serverless/observability/developer-metrics/serverless-developer-metrics.adoc
+++ b/serverless/observability/developer-metrics/serverless-developer-metrics.adoc
@@ -32,7 +32,7 @@ ifdef::openshift-enterprise[]
 [id="additional-resources_serverless-service-monitoring"]
 [role="_additional-resources"]
 == Additional resources
-* xref:../../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
-* xref:../../../observability/monitoring/managing-metrics.adoc#specifying-how-a-service-is-monitored[Enabling monitoring for user-defined projects]
-* xref:../../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Specifying how a service is monitored]
+* xref:../../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* xref:../../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#specifying-how-a-service-is-monitored_configuring-metrics-uwm[Specifying how a service is monitored]
 endif::[]
diff --git a/service_mesh/v1x/ossm-custom-resources.adoc b/service_mesh/v1x/ossm-custom-resources.adoc
index 0f6fb51a9a13..4dc446b1c1f2 100644
--- a/service_mesh/v1x/ossm-custom-resources.adoc
+++ b/service_mesh/v1x/ossm-custom-resources.adoc
@@ -41,8 +41,4 @@ include::modules/ossm-jaeger-config-elasticsearch-v1x.adoc[leveloffset=+2]
 
 include::modules/ossm-jaeger-config-es-cleaner-v1x.adoc[leveloffset=+2]
 
-ifdef::openshift-enterprise[]
-For more information about configuring Elasticsearch with {product-title}, see  xref:../../observability/logging/log_storage/logging-config-es-store.adoc#logging-config-es-store[Configuring the Elasticsearch log store].
-endif::[]
-
 include::modules/ossm-cr-threescale.adoc[leveloffset=+1]
diff --git a/service_mesh/v1x/preparing-ossm-installation.adoc b/service_mesh/v1x/preparing-ossm-installation.adoc
index 522edcb112c6..4db22173d887 100644
--- a/service_mesh/v1x/preparing-ossm-installation.adoc
+++ b/service_mesh/v1x/preparing-ossm-installation.adoc
@@ -40,10 +40,6 @@ include::modules/ossm-supported-configurations-v1x.adoc[leveloffset=+1]
 include::modules/ossm-installation-activities.adoc[leveloffset=+1]
 
 ifdef::openshift-enterprise[]
-[WARNING]
-====
-See xref:../../observability/logging/log_storage/logging-config-es-store.adoc#logging-config-es-store[Configuring the Elasticsearch log store] for details on configuring the default Jaeger parameters for Elasticsearch in a production environment.
-====
 
 == Next steps
 
diff --git a/service_mesh/v2x/installing-ossm.adoc b/service_mesh/v2x/installing-ossm.adoc
index 4aae47fe95fc..e43ac5b1401a 100644
--- a/service_mesh/v2x/installing-ossm.adoc
+++ b/service_mesh/v2x/installing-ossm.adoc
@@ -15,12 +15,12 @@ This basic installation is configured based on the default OpenShift settings an
 
 .Prerequisites
 * Read the xref:../../service_mesh/v2x/preparing-ossm-installation.adoc#preparing-ossm-installation[Preparing to install {SMProductName}] process.
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 * An account with the `cluster-admin` role.
-endif::openshift-rosa[]
-ifndef::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 * An account with the `cluster-admin` role. If you use {product-dedicated}, you must have an account with the `dedicated-admin` role.
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 The following steps show how to install a basic instance of {SMProductName} on {product-title}.
 
@@ -33,13 +33,13 @@ include::modules/ossm-installation-activities.adoc[leveloffset=+1]
 
 include::modules/ossm-install-ossm-operator.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/ossm-config-operator-infrastructure-node.adoc[leveloffset=+1]
 
 include::modules/ossm-confirm-operator-infrastructure-node.adoc[leveloffset=+1]
 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 == Next steps
 
diff --git a/service_mesh/v2x/ossm-create-smcp.adoc b/service_mesh/v2x/ossm-create-smcp.adoc
index ad6aab2c7c4d..03ca06fafd18 100644
--- a/service_mesh/v2x/ossm-create-smcp.adoc
+++ b/service_mesh/v2x/ossm-create-smcp.adoc
@@ -14,7 +14,7 @@ include::modules/ossm-control-plane-cli.adoc[leveloffset=+2]
 
 include::modules/ossm-validate-smcp-cli.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-about-control-plane-components-and-infrastructure-nodes.adoc[leveloffset=+1]
 
@@ -28,7 +28,7 @@ include::modules/ossm-config-individual-control-plane-infrastructure-node-cli.ad
 
 include::modules/ossm-confirm-smcp-infrastructure-node.adoc[leveloffset=+2]
 
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-about-control-plane-and-cluster-wide-deployment.adoc[leveloffset=+1]
 
diff --git a/service_mesh/v2x/ossm-extensions.adoc b/service_mesh/v2x/ossm-extensions.adoc
index f2facd5a2201..138abbe54c65 100644
--- a/service_mesh/v2x/ossm-extensions.adoc
+++ b/service_mesh/v2x/ossm-extensions.adoc
@@ -8,13 +8,13 @@ toc::[]
 
 You can use WebAssembly extensions to add new features directly into the {SMProductName} proxies. This lets you move even more common functionality out of your applications, and implement them in a single language that compiles to WebAssembly bytecode.
 
-ifndef::openshift-rosa[]
+ifndef::openshift-rosa,openshift-rosa-hcp[]
 [NOTE]
 ====
 WebAssembly extensions are not supported on {ibm-z-name} and {ibm-power-name}.
 ====
 
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 include::modules/ossm-extensions-overview.adoc[leveloffset=+1]
 
diff --git a/service_mesh/v2x/ossm-observability.adoc b/service_mesh/v2x/ossm-observability.adoc
index a85fc8a286e6..241502ca7fbf 100644
--- a/service_mesh/v2x/ossm-observability.adoc
+++ b/service_mesh/v2x/ossm-observability.adoc
@@ -39,12 +39,12 @@ include::modules/ossm-access-prometheus.adoc[leveloffset=+1]
 include::modules/ossm-integrating-with-user-workload-monitoring.adoc[leveloffset=+1]
 
 // Hiding as these assemblies not in ROSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 [id="additional-resources_user-workload-monitoring"]
 == Additional resources
 
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
 * xref:../../observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc[Installing the distributed tracing platform (Tempo)]
 * xref:../../observability/otel/otel-installing.adoc[Installing the Red Hat build of OpenTelemetry]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/service_mesh/v2x/ossm-performance-scalability.adoc b/service_mesh/v2x/ossm-performance-scalability.adoc
index 697c384f8049..cd6bf7031a8a 100644
--- a/service_mesh/v2x/ossm-performance-scalability.adoc
+++ b/service_mesh/v2x/ossm-performance-scalability.adoc
@@ -14,7 +14,7 @@ include::modules/ossm-recommended-resources.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc#distr-tracing-deploy-default_deploying-distributed-tracing-platform[Configuring and deploying the distributed tracing platform Jaeger].
 endif::[]
 
diff --git a/service_mesh/v2x/ossm-reference-jaeger.adoc b/service_mesh/v2x/ossm-reference-jaeger.adoc
index 2a0866f8bf45..7091951a4966 100644
--- a/service_mesh/v2x/ossm-reference-jaeger.adoc
+++ b/service_mesh/v2x/ossm-reference-jaeger.adoc
@@ -44,7 +44,7 @@ include::modules/distr-tracing-config-sampling.adoc[leveloffset=+2]
 include::modules/distr-tracing-config-storage.adoc[leveloffset=+2]
 
 ifdef::openshift-enterprise[]
-For more information about configuring Elasticsearch with {product-title}, see xref:../../observability/logging/log_storage/logging-config-es-store.adoc#logging-config-es-store[Configuring the Elasticsearch log store] or xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc#distr-tracing-jaeger-configuring[Configuring and deploying distributed tracing].
+For more information about configuring Elasticsearch with {product-title}, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc#distr-tracing-jaeger-configuring[Configuring and deploying {DTShortName}].
 
 //TO DO For information about connecting to an external Elasticsearch instance, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-configuring.adoc#jaeger-config-external-es_jaeger-deploying[Connecting to an existing Elasticsearch instance].
 endif::[]
diff --git a/service_mesh/v2x/ossm-reference-smcp.adoc b/service_mesh/v2x/ossm-reference-smcp.adoc
index b00ac21943bf..e7ebca0a7d7d 100644
--- a/service_mesh/v2x/ossm-reference-smcp.adoc
+++ b/service_mesh/v2x/ossm-reference-smcp.adoc
@@ -21,9 +21,9 @@ For information about creating profiles, see the xref:../../service_mesh/v2x/oss
 For more detailed examples of security configuration, see xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[Mutual Transport Layer Security (mTLS)].
 
 // No tech preview in ROSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/ossm-cr-techPreview.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-cr-tracing.adoc[leveloffset=+2]
 
diff --git a/service_mesh/v2x/ossm-route-migration.adoc b/service_mesh/v2x/ossm-route-migration.adoc
index 8d4d9b2bce84..1f8657937fe6 100644
--- a/service_mesh/v2x/ossm-route-migration.adoc
+++ b/service_mesh/v2x/ossm-route-migration.adoc
@@ -15,4 +15,4 @@ include::modules/ossm-migrating-from-ior-to-explicitly-managed-routes.adoc[level
 == Additional resources
 
 * xref:../../networking/routes/route-configuration.adoc#nw-creating-a-route_route-configuration[Creating an HTTP-based Route]
-* xref:../../service_mesh/v2x/ossm-traffic-manage.adoc#ossm-auto-route_traffic-management[Understanding automatic routes]
\ No newline at end of file
+* xref:../../service_mesh/v2x/ossm-traffic-manage.adoc#ossm-auto-route_traffic-management[Understanding automatic routes]
diff --git a/service_mesh/v2x/ossm-security.adoc b/service_mesh/v2x/ossm-security.adoc
index 2afefc60ab1f..47128c55b8f5 100644
--- a/service_mesh/v2x/ossm-security.adoc
+++ b/service_mesh/v2x/ossm-security.adoc
@@ -49,9 +49,9 @@ include::modules/ossm-cert-manager-installation.adoc[leveloffset=+2]
 == Additional resources
 
 For information about how to install the cert-manager Operator for {product-title}, see:
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 xref:../../security/cert_manager_operator/cert-manager-operator-install.adoc[Installing the cert-manager Operator for Red Hat OpenShift].
 endif::[]
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/security_and_compliance/index#cert-manager-operator-install[Installing the cert-manager Operator for Red Hat OpenShift].
-endif::[]
\ No newline at end of file
+endif::[]
diff --git a/service_mesh/v2x/ossm-threescale-webassembly-module.adoc b/service_mesh/v2x/ossm-threescale-webassembly-module.adoc
index f9fb7d76893f..b68995e6f7fa 100644
--- a/service_mesh/v2x/ossm-threescale-webassembly-module.adoc
+++ b/service_mesh/v2x/ossm-threescale-webassembly-module.adoc
@@ -73,4 +73,4 @@ include::modules/ossm-threescale-webassembly-module-mapping-rule-object.adoc[lev
 
 include::modules/ossm-threescale-webassembly-module-examples-for-credentials-use-cases.adoc[leveloffset=+1]
 
-include::modules/ossm-threescale-webassembly-module-minimal-working-configuration.adoc[leveloffset=+1]
\ No newline at end of file
+include::modules/ossm-threescale-webassembly-module-minimal-working-configuration.adoc[leveloffset=+1]
diff --git a/service_mesh/v2x/ossm-traffic-manage.adoc b/service_mesh/v2x/ossm-traffic-manage.adoc
index b90a4baa2ad3..e1a2c4cf326e 100644
--- a/service_mesh/v2x/ossm-traffic-manage.adoc
+++ b/service_mesh/v2x/ossm-traffic-manage.adoc
@@ -11,12 +11,12 @@ Using {SMProductName}, you can control the flow of traffic and API calls between
 include::modules/ossm-gateways.adoc[leveloffset=+1]
 
 // Hiding in ROSA/OSD, dedicated-admin cannot create "services" or "deployments"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-automatic-gateway-injection.adoc[leveloffset=+2]
 
 include::modules/ossm-deploying-automatic-gateway-injection.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-routing-ingress.adoc[leveloffset=+2]
 
diff --git a/service_mesh/v2x/ossm-troubleshooting-istio.adoc b/service_mesh/v2x/ossm-troubleshooting-istio.adoc
index 3f86a809c029..11740bf59e4e 100644
--- a/service_mesh/v2x/ossm-troubleshooting-istio.adoc
+++ b/service_mesh/v2x/ossm-troubleshooting-istio.adoc
@@ -64,10 +64,10 @@ include::modules/support-knowledgebase-about.adoc[leveloffset=+2]
 
 include::modules/support-knowledgebase-search.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/ossm-about-collecting-ossm-data.adoc[leveloffset=+2]
 
 For prompt support, supply diagnostic information for both {product-title} and {SMProductName}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/support-submitting-a-case.adoc[leveloffset=+2]
diff --git a/service_mesh/v2x/servicemesh-release-notes.adoc b/service_mesh/v2x/servicemesh-release-notes.adoc
index be7399783349..abdd904bc5fe 100644
--- a/service_mesh/v2x/servicemesh-release-notes.adoc
+++ b/service_mesh/v2x/servicemesh-release-notes.adoc
@@ -10,6 +10,18 @@ toc::[]
 
 include::modules/making-open-source-more-inclusive.adoc[leveloffset=+1]
 
+include::modules/ossm-release-2-6-6.adoc[leveloffset=+1]
+
+include::modules/ossm-release-2-5-9.adoc[leveloffset=+1]
+
+include::modules/ossm-release-2-4-15.adoc[leveloffset=+1]
+
+include::modules/ossm-release-2-6-5.adoc[leveloffset=+1]
+
+include::modules/ossm-release-2-5-8.adoc[leveloffset=+1]
+
+include::modules/ossm-release-2-4-14.adoc[leveloffset=+1]
+
 include::modules/ossm-release-2-6-4.adoc[leveloffset=+1]
 
 include::modules/ossm-release-2-5-7.adoc[leveloffset=+1]
@@ -48,9 +60,9 @@ include::modules/ossm-release-2-3-12.adoc[leveloffset=+1]
 include::modules/ossm-rn-new-features.adoc[leveloffset=+1]
 
 // Tech preview not supported in ROSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/ossm-rn-technology-preview.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/ossm-rn-deprecated-features.adoc[leveloffset=+1]
 
diff --git a/snippets/ccoctl-provider-permissions-requirements.adoc b/snippets/ccoctl-provider-permissions-requirements.adoc
new file mode 100644
index 000000000000..9eec3238e4e8
--- /dev/null
+++ b/snippets/ccoctl-provider-permissions-requirements.adoc
@@ -0,0 +1,182 @@
+// Text snippet included in the following modules:
+//
+// * modules/cco-ccoctl-configuring.adoc (ifevals for aws-sts, azure-workload-id, google-cloud-platform)
+// * modules/rotating-bound-service-keys.adoc (ifevals for rotate-aws, rotate-azure, rotate-gcp)
+//
+
+// There is almost certainly a better reuse strategy for the rotation perms but the content needs to go in and this is functional.
+
+//AWS permissions needed when running ccoctl during installation and key rotation.
+ifdef::aws-sts[]
+* You have created an {aws-short} account for the `ccoctl` utility to use with the following permissions:
++
+--
+**Required `iam` permissions**
+
+* `iam:CreateOpenIDConnectProvider`
+* `iam:CreateRole`
+* `iam:DeleteOpenIDConnectProvider`
+* `iam:DeleteRole`
+* `iam:DeleteRolePolicy`
+* `iam:GetOpenIDConnectProvider`
+* `iam:GetRole`
+* `iam:GetUser`
+* `iam:ListOpenIDConnectProviders`
+* `iam:ListRolePolicies`
+* `iam:ListRoles`
+* `iam:PutRolePolicy`
+* `iam:TagOpenIDConnectProvider`
+* `iam:TagRole`
+
+**Required `s3` permissions**
+
+* `s3:CreateBucket`
+* `s3:DeleteBucket`
+* `s3:DeleteObject`
+* `s3:GetBucketAcl`
+* `s3:GetBucketTagging`
+* `s3:GetObject`
+* `s3:GetObjectAcl`
+* `s3:GetObjectTagging`
+* `s3:ListBucket`
+* `s3:PutBucketAcl`
+* `s3:PutBucketPolicy`
+* `s3:PutBucketPublicAccessBlock`
+* `s3:PutBucketTagging`
+* `s3:PutObject`
+* `s3:PutObjectAcl`
+* `s3:PutObjectTagging`
+
+**Required `cloudfront` permissions**
+
+* `cloudfront:ListCloudFrontOriginAccessIdentities`
+* `cloudfront:ListDistributions`
+* `cloudfront:ListTagsForResource`
+--
+
+* If you plan to store the OIDC configuration in a private S3 bucket that is accessed by the IAM identity provider through a public CloudFront distribution URL, the {aws-short} account that runs the `ccoctl` utility requires the following additional permissions:
++
+--
+* `cloudfront:CreateCloudFrontOriginAccessIdentity`
+* `cloudfront:CreateDistribution`
+* `cloudfront:DeleteCloudFrontOriginAccessIdentity`
+* `cloudfront:DeleteDistribution`
+* `cloudfront:GetCloudFrontOriginAccessIdentity`
+* `cloudfront:GetCloudFrontOriginAccessIdentityConfig`
+* `cloudfront:GetDistribution`
+* `cloudfront:TagResource`
+* `cloudfront:UpdateDistribution`
+--
++
+[NOTE]
+====
+These additional permissions support the use of the `--create-private-s3-bucket` option when processing credentials requests with the `ccoctl aws create-all` command.
+====
+endif::aws-sts[]
+ifdef::rotate-aws[]
+* You have created an {aws-short} account for the `ccoctl` utility to use with the following permissions:
++
+--
+* `s3:GetObject`
+* `s3:PutObject`
+* `s3:PutObjectTagging`
+* For clusters that store the OIDC configuration in a private S3 bucket that is accessed by the IAM identity provider through a public CloudFront distribution URL, the {aws-short} account that runs the `ccoctl` utility requires the `cloudfront:ListDistributions` permission.
+--
+endif::rotate-aws[]
+
+//Azure permissions needed when running ccoctl during installation and key rotation.
+ifdef::azure-workload-id[]
+* You have created a global {azure-short} account for the `ccoctl` utility to use with the following permissions:
++
+--
+* `Microsoft.Resources/subscriptions/resourceGroups/read`
+* `Microsoft.Resources/subscriptions/resourceGroups/write`
+* `Microsoft.Resources/subscriptions/resourceGroups/delete`
+* `Microsoft.Authorization/roleAssignments/read`
+* `Microsoft.Authorization/roleAssignments/delete`
+* `Microsoft.Authorization/roleAssignments/write`
+* `Microsoft.Authorization/roleDefinitions/read`
+* `Microsoft.Authorization/roleDefinitions/write`
+* `Microsoft.Authorization/roleDefinitions/delete`
+* `Microsoft.Storage/storageAccounts/listkeys/action`
+* `Microsoft.Storage/storageAccounts/delete`
+* `Microsoft.Storage/storageAccounts/read`
+* `Microsoft.Storage/storageAccounts/write`
+* `Microsoft.Storage/storageAccounts/blobServices/containers/delete`
+* `Microsoft.Storage/storageAccounts/blobServices/containers/read`
+* `Microsoft.Storage/storageAccounts/blobServices/containers/write`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/delete`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/read`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/write`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write`
+* `Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/delete`
+* `Microsoft.Storage/register/action`
+* `Microsoft.ManagedIdentity/register/action`
+--
+endif::azure-workload-id[]
+ifdef::rotate-azure[]
+* You have created a global {azure-short} account for the `ccoctl` utility to use with the following permissions:
++
+--
+* `Microsoft.Storage/storageAccounts/listkeys/action`
+* `Microsoft.Storage/storageAccounts/read`
+* `Microsoft.Storage/storageAccounts/write`
+* `Microsoft.Storage/storageAccounts/blobServices/containers/read`
+* `Microsoft.Storage/storageAccounts/blobServices/containers/write`
+--
+endif::rotate-azure[]
+
+//GCP permissions needed when running ccoctl during installation and key rotation.
+ifdef::google-cloud-platform[]
+* You have added one of the following authentication options to the {gcp-short} account that the `ccoctl` utility uses:
+
+** The **IAM Workload Identity Pool Admin** role
+
+** The following granular permissions:
++
+--
+* `compute.projects.get`
+* `iam.googleapis.com/workloadIdentityPoolProviders.create`
+* `iam.googleapis.com/workloadIdentityPoolProviders.get`
+* `iam.googleapis.com/workloadIdentityPools.create`
+* `iam.googleapis.com/workloadIdentityPools.delete`
+* `iam.googleapis.com/workloadIdentityPools.get`
+* `iam.googleapis.com/workloadIdentityPools.undelete`
+* `iam.roles.create`
+* `iam.roles.delete`
+* `iam.roles.list`
+* `iam.roles.undelete`
+* `iam.roles.update`
+* `iam.serviceAccounts.create`
+* `iam.serviceAccounts.delete`
+* `iam.serviceAccounts.getIamPolicy`
+* `iam.serviceAccounts.list`
+* `iam.serviceAccounts.setIamPolicy`
+* `iam.workloadIdentityPoolProviders.get`
+* `iam.workloadIdentityPools.delete`
+* `resourcemanager.projects.get`
+* `resourcemanager.projects.getIamPolicy`
+* `resourcemanager.projects.setIamPolicy`
+* `storage.buckets.create`
+* `storage.buckets.delete`
+* `storage.buckets.get`
+* `storage.buckets.getIamPolicy`
+* `storage.buckets.setIamPolicy`
+* `storage.objects.create`
+* `storage.objects.delete`
+* `storage.objects.list`
+--
+endif::google-cloud-platform[]
+ifdef::rotate-gcp[]
+* You have added one of the following authentication options to the {gcp-short} account that the `ccoctl` utility uses:
+
+** The **IAM Workload Identity Pool Admin** role
+
+** The following granular permissions:
++
+--
+* `storage.objects.create`
+* `storage.objects.delete`
+--
+endif::rotate-gcp[]
\ No newline at end of file
diff --git a/snippets/coreos-layering-configuring-on-pause.adoc b/snippets/coreos-layering-configuring-on-pause.adoc
new file mode 100644
index 000000000000..2a3b3683930e
--- /dev/null
+++ b/snippets/coreos-layering-configuring-on-pause.adoc
@@ -0,0 +1,21 @@
+// Text snippet included in the following modules:
+//
+// * modules/coreos-layering-configuring-on.adoc
+// * modules/coreos-layering-configuring-on-modifying.adoc
+
+:_mod-docs-content-type: SNIPPET
+
+Making certain changes to a `MachineOSConfig` object triggers an automatic rebuild of the associated custom layered image. You can mitigate the effects of the rebuild by pausing the machine config pool where the custom layered image is applied as described in "Pausing the machine config pools." While the pools are paused, the MCO does not roll out the newly built image to the nodes after the build is complete. However, the build will still run regardless of whether the pool is paused or not. For example, if you want to remove and replace a `MachineOSCOnfig` object, pausing the machine config pools before making the change prevents the MCO from reverting the associated nodes to the base image, reducing the number of reboots needed. 
+
+When a machine config pool is paused, the `oc get machineconfigpools` reports the following status:
+
+.Example output
+[source,terminal]
+----
+NAME      CONFIG                                              UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
+master    rendered-master-a0b404d061a6183cc36d302363422aba    True      False      False      3              3                   3                     0                      4h14m
+worker    rendered-worker-221507009cbcdec0eec8ab3ccd789d18    False     False      False      2              2                   2                     0                      4h14m <1>
+----
+<1> The `worker` machine config pool is paused, as indicated by the three `False` statuses and the `READYMACHINECOUNT` at `0`.
+
+After the changes have been rolled out, you can unpause the machine config pool.
diff --git a/snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc b/snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc
new file mode 100644
index 000000000000..7c0416bc0f95
--- /dev/null
+++ b/snippets/distr-tracing-assembly-tip-for-jaeger-replacements.adoc
@@ -0,0 +1,29 @@
+// Text snippet included in the following assemblies:
+//
+// * distr-tracing-jaeger-configuring.adoc
+// * distr-tracing-jaeger-installing.adoc
+// * distr-tracing-jaeger-removing.adoc
+// * distr-tracing-jaeger-updating.adoc
+// This text is also added inline in one more assembly due to its different xref level:
+// * distr-tracing-rn.adoc
+//   * [id="distr-tracing_3-4_jaeger-release-notes_deprecated-functionality_{context}"]
+//   * [id="distr-tracing_3-3-1_jaeger-release-notes_deprecated-functionality_{context}"]
+//   * [id="distr-tracing_3-3_jaeger-release-notes_support-for-elasticsearch-operator_{context}"]
+// This text is also added inline in one module without xrefs:
+// * modules/distr-tracing-architecture.adoc
+
+:_mod-docs-content-type: SNIPPET
+
+[WARNING]
+====
+[subs="attributes+"]
+The {JaegerName} 3.5 is the last release of the {JaegerName} that Red Hat plans to support.
+
+In the {DTProductName} 3.5, Jaeger and support for Elasticsearch remain deprecated.
+
+Support for the {JaegerName} ends on November 3, 2025.
+
+The {JaegerOperator} Operator (Jaeger) will be removed from the `redhat-operators` catalog on November 3, 2025. For more information, see the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/7083722[Jaeger Deprecation and Removal in OpenShift].
+
+You must migrate to the {OTELName} Operator and the {TempoOperator} for distributed tracing collection and storage. For more information, see "Migrating" in the {OTELShortName} documentation, "Installing" in the {OTELName} documentation, and "Installing" in the {TempoShortName} documentation.
+====
diff --git a/snippets/example-pipelines-installer-clusterrole.yaml b/snippets/example-pipelines-installer-clusterrole.yaml
new file mode 100644
index 000000000000..0b7b2dda35c3
--- /dev/null
+++ b/snippets/example-pipelines-installer-clusterrole.yaml
@@ -0,0 +1,550 @@
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pipelines-installer-clusterrole
+rules:
+- apiGroups:
+  - olm.operatorframework.io
+  resources:
+  - clusterextensions/finalizers
+  verbs:
+  - update
+  # Scoped to the name of the ClusterExtension
+  resourceNames:
+  - pipes # the value from <metadata.name> from the extension's custom resource (CR)
+# ClusterRoles and ClusterRoleBindings for the controllers of the extension
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterroles
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterroles
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames:
+  - "*"
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterrolebindings
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterrolebindings
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames:
+  - "*"
+# Extension's custom resource definitions
+- apiGroups:
+  - apiextensions.k8s.io
+  resources:
+  - customresourcedefinitions
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - apiextensions.k8s.io
+  resources:
+  - customresourcedefinitions
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  resourceNames:
+  - manualapprovalgates.operator.tekton.dev
+  - openshiftpipelinesascodes.operator.tekton.dev
+  - tektonaddons.operator.tekton.dev
+  - tektonchains.operator.tekton.dev
+  - tektonconfigs.operator.tekton.dev
+  - tektonhubs.operator.tekton.dev
+  - tektoninstallersets.operator.tekton.dev
+  - tektonpipelines.operator.tekton.dev
+  - tektonresults.operator.tekton.dev
+  - tektontriggers.operator.tekton.dev
+- apiGroups:
+  - ''
+  resources:
+  - nodes
+  - pods
+  - services
+  - endpoints
+  - persistentvolumeclaims
+  - events
+  - configmaps
+  - secrets
+  - pods/log
+  - limitranges
+  verbs:
+  - create
+  - list
+  - watch
+  - delete
+  - deletecollection
+  - patch
+  - get
+  - update
+- apiGroups:
+  - extensions
+  - apps
+  resources:
+  - ingresses
+  - ingresses/status
+  verbs:
+  - create
+  - list
+  - watch
+  - delete
+  - patch
+  - get
+  - update
+- apiGroups:
+  - ''
+  resources:
+  - namespaces
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - apps
+  resources:
+  - deployments
+  - daemonsets
+  - replicasets
+  - statefulsets
+  - deployments/finalizers
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - monitoring.coreos.com
+  resources:
+  - servicemonitors
+  verbs:
+  - get
+  - create
+  - delete
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterroles
+  - roles
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+  - bind
+  - escalate
+- apiGroups:
+  - ''
+  resources:
+  - serviceaccounts
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+  - impersonate
+- apiGroups:
+  - rbac.authorization.k8s.io
+  resources:
+  - clusterrolebindings
+  - rolebindings
+  verbs:
+  - get
+  - update
+  - delete
+  - patch
+  - create
+  - list
+  - watch
+- apiGroups:
+  - apiextensions.k8s.io
+  resources:
+  - customresourcedefinitions
+  - customresourcedefinitions/status
+  verbs:
+  - get
+  - create
+  - update
+  - delete
+  - list
+  - patch
+  - watch
+- apiGroups:
+  - admissionregistration.k8s.io
+  resources:
+  - mutatingwebhookconfigurations
+  - validatingwebhookconfigurations
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - build.knative.dev
+  resources:
+  - builds
+  - buildtemplates
+  - clusterbuildtemplates
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - extensions
+  resources:
+  - deployments
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - extensions
+  resources:
+  - deployments/finalizers
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - operator.tekton.dev
+  resources:
+  - '*'
+  - tektonaddons
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - tekton.dev
+  - triggers.tekton.dev
+  - operator.tekton.dev
+  - pipelinesascode.tekton.dev
+  resources:
+  - '*'
+  verbs:
+  - add
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - dashboard.tekton.dev
+  resources:
+  - '*'
+  - tektonaddons
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - security.openshift.io
+  resources:
+  - securitycontextconstraints
+  verbs:
+  - use
+  - get
+  - list
+  - create
+  - update
+  - delete
+- apiGroups:
+  - events.k8s.io
+  resources:
+  - events
+  verbs:
+  - create
+- apiGroups:
+  - route.openshift.io
+  resources:
+  - routes
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - coordination.k8s.io
+  resources:
+  - leases
+  verbs:
+  - get
+  - list
+  - create
+  - update
+  - delete
+  - patch
+  - watch
+- apiGroups:
+  - console.openshift.io
+  resources:
+  - consoleyamlsamples
+  - consoleclidownloads
+  - consolequickstarts
+  - consolelinks
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - autoscaling
+  resources:
+  - horizontalpodautoscalers
+  verbs:
+  - delete
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - policy
+  resources:
+  - poddisruptionbudgets
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - monitoring.coreos.com
+  resources:
+  - servicemonitors
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - batch
+  resources:
+  - jobs
+  - cronjobs
+  verbs:
+  - delete
+  - deletecollection
+  - create
+  - patch
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - ''
+  resources:
+  - namespaces/finalizers
+  verbs:
+  - update
+- apiGroups:
+  - resolution.tekton.dev
+  resources:
+  - resolutionrequests
+  - resolutionrequests/status
+  verbs:
+  - get
+  - list
+  - watch
+  - create
+  - delete
+  - update
+  - patch
+- apiGroups:
+  - console.openshift.io
+  resources:
+  - consoleplugins
+  verbs:
+  - get
+  - list
+  - watch
+  - create
+  - delete
+  - update
+  - patch
+# Deployments specified in install.spec.deployments
+- apiGroups:
+  - apps
+  resources:
+  - deployments
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - apps
+  resources:
+  - deployments
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  # scoped to the extension controller deployment name
+  resourceNames:
+  - openshift-pipelines-operator
+  - tekton-operator-webhook
+# Service accounts in the CSV
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts
+  verbs:
+  - create
+  - list
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts
+  verbs:
+  - get
+  - update
+  - patch
+  - delete
+  # scoped to the extension controller's deployment service account
+  resourceNames:
+  - openshift-pipelines-operator
+# Services
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - get
+  - list
+  - watch
+  - update
+  - patch
+  - delete
+  # scoped to the service name
+  resourceNames:
+  - openshift-pipelines-operator-monitor
+  - tekton-operator
+  - tekton-operator-webhook
+# configmaps
+- apiGroups:
+  - ""
+  resources:
+  - configmaps
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - configmaps
+  verbs:
+  - get
+  - list
+  - watch
+  - update
+  - patch
+  - delete
+  # scoped to the configmap name
+  resourceNames:
+  - config-logging
+  - tekton-config-defaults
+  - tekton-config-observability
+  - tekton-operator-controller-config-leader-election
+  - tekton-operator-info
+  - tekton-operator-webhook-config-leader-election
+- apiGroups:
+  - operator.tekton.dev
+  resources:
+  - tekton-config-read-role
+  - tekton-result-read-role
+  verbs:
+  - get
+  - watch
+  - list
+---
diff --git a/snippets/ibu-ImageBasedGroupUpgrade.adoc b/snippets/ibu-ImageBasedGroupUpgrade.adoc
index 57325cad6d57..7ff07b47dab1 100644
--- a/snippets/ibu-ImageBasedGroupUpgrade.adoc
+++ b/snippets/ibu-ImageBasedGroupUpgrade.adoc
@@ -16,8 +16,8 @@ spec:
         - spoke6
   ibuSpec:
     seedImageRef: # <2>
-      image: quay.io/seed/image:4.17.0-rc.1
-      version: 4.17.0-rc.1
+      image: quay.io/seed/image:4.18.0-rc.1
+      version: 4.18.0-rc.1
       pullSecretRef:
         name: "<seed_pull_secret>"
     extraManifests: # <3>
@@ -34,6 +34,12 @@ spec:
 ----
 <1> Clusters to upgrade.
 <2> Target platform version, the seed image to be used, and the secret required to access the image.
++
+[NOTE]
+====
+If you add the seed image pull secret in the hub cluster, in the same namespace as the `ImageBasedGroupUpgrade` resource, the secret is added to the manifest list for the `Prep` stage. The secret is recreated in each spoke cluster in the `openshift-lifecycle-agent` namespace.
+====
++
 <3> Optional: Applies additional manifests, which are not in the seed image, to the target cluster. Also applies `ConfigMap` objects for custom catalog sources.
 <4> `ConfigMap` resources that contain the OADP `Backup` and `Restore` CRs.
 <5> Upgrade plan details.
diff --git a/snippets/kopia-repo-config.adoc b/snippets/kopia-repo-config.adoc
new file mode 100644
index 000000000000..825540900c77
--- /dev/null
+++ b/snippets/kopia-repo-config.adoc
@@ -0,0 +1,12 @@
+//This snippet appears in the following modules:
+//
+// * modules/oadp-kopia-algorithms-benchmarking.adoc
+// * modules/oadp-kopia-configuring-algorithms.adoc
+
+:_mod-docs-content-type: SNIPPET
+[NOTE]
+====
+The configuration of the Kopia algorithms for splitting, hashing, and encryption in the Data Protection Application (DPA) apply only during the initial Kopia repository creation, and cannot be changed later.
+
+To use different Kopia algorithms, ensure that the object storage does not contain any previous Kopia repositories of backups. Configure a new object storage in the Backup Storage Location (BSL) or specify a unique prefix for the object storage in the BSL configuration.
+====
diff --git a/snippets/logging-kibana-dep-snip.adoc b/snippets/logging-kibana-dep-snip.adoc
index c1aa6614d17a..a4b98d8308b3 100644
--- a/snippets/logging-kibana-dep-snip.adoc
+++ b/snippets/logging-kibana-dep-snip.adoc
@@ -10,5 +10,5 @@
 
 [NOTE]
 ====
-The Kibana web console is now deprecated is planned to be removed in a future logging release.
+The Kibana web console is now deprecated and is planned to be removed in a future logging release.
 ====
diff --git a/snippets/microshift-healthy-pods-snip.adoc b/snippets/microshift-healthy-pods-snip.adoc
index 05d284597b45..d6664d84625d 100644
--- a/snippets/microshift-healthy-pods-snip.adoc
+++ b/snippets/microshift-healthy-pods-snip.adoc
@@ -14,7 +14,6 @@ $ oc get pods -A
 NAMESPACE                   NAME                                                     READY   STATUS   RESTARTS  AGE
 default                     i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr  1/1     Running  0		    46m
 kube-system                 csi-snapshot-controller-5c6586d546-lprv4                 1/1     Running  0		    51m
-kube-system                 csi-snapshot-webhook-6bf8ddc7f5-kz6k9                    1/1     Running  0		    51m
 openshift-dns               dns-default-45jl7                                        2/2     Running  0		    50m
 openshift-dns               node-resolver-7wmzf                                      1/1     Running  0		    51m
 openshift-ingress           router-default-78b86fbf9d-qvj9s                          1/1     Running  0		    51m
diff --git a/snippets/microshift-rhde-compatibility-table-snip.adoc b/snippets/microshift-rhde-compatibility-table-snip.adoc
index 28dd832764b2..e457d7b74916 100644
--- a/snippets/microshift-rhde-compatibility-table-snip.adoc
+++ b/snippets/microshift-rhde-compatibility-table-snip.adoc
@@ -7,7 +7,7 @@
 
 .{op-system-bundle} release compatibility matrix
 
-{op-system-base-full} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. Supported configurations of {op-system-bundle} use verified releases for each together as listed in the following table:
+{op-system-base-full} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of {microshift-short} from 4.14 to 4.16 or an update from 4.18 to 4.19 requires a {op-system-base-full} update. Supported configurations of {op-system-bundle} use verified releases for each together as listed in the following table:
 
 [%header,cols="3",cols="1,1,2"]
 |===
@@ -15,9 +15,13 @@
 ^|*{microshift-short} Version*
 ^|*Supported {microshift-short} Version{nbsp}&#8594;{nbsp}Version Updates*
 
+^|9.6
+^|4.19
+^|4.19.0{nbsp}&#8594;{nbsp}4.19.z
+
 ^|9.4
 ^|4.18
-^|4.18.0{nbsp}&#8594;{nbsp}4.18.z
+^|4.18.0{nbsp}&#8594;{nbsp}4.18.z, 4.18{nbsp}&#8594;{nbsp}4.19 on {op-system-base} 9.6
 
 ^|9.4
 ^|4.17
diff --git a/snippets/microshift-tls-ciphers.adoc b/snippets/microshift-tls-ciphers.adoc
new file mode 100644
index 000000000000..60de1a91d0f1
--- /dev/null
+++ b/snippets/microshift-tls-ciphers.adoc
@@ -0,0 +1,28 @@
+// Text snippet included in the following modules and assemblies:
+//
+// * microshift_configuring/microshift-tls-config.adoc
+// *
+
+:_mod-docs-content-type: SNIPPET
+
+.Default cipher suites for TLS 1.2
+
+The following list specifies the default cipher suites for TLS 1.2:
+
+* `TLS_AES_128_GCM_SHA256`
+* `TLS_AES_256_GCM_SHA384`
+* `TLS_CHACHA20_POLY1305_SHA256`
+* `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`
+* `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+* `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
+* `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+* `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`
+* `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`
+
+.Default cipher suites for TLS 1.3
+
+The following list specifies the default cipher suites for TLS 1.3:
+
+* `TLS_AES_128_GCM_SHA256`
+* `TLS_AES_256_GCM_SHA384`
+* `TLS_CHACHA20_POLY1305_SHA256`
\ No newline at end of file
diff --git a/snippets/microshift-unsupported-config-warn.adoc b/snippets/microshift-unsupported-config-warn.adoc
new file mode 100644
index 000000000000..07c1d440dff7
--- /dev/null
+++ b/snippets/microshift-unsupported-config-warn.adoc
@@ -0,0 +1,12 @@
+// Text snippet included in the following modules:
+//
+// * modules/microshift-updating-rpms-y.adoc
+// * modules/microshift-embed-ostree-enable-eus-repos.adoc
+// * assemblies/microshift-update-options.adoc
+
+:_mod-docs-content-type: SNIPPET
+
+[WARNING]
+====
+Keeping component versions in a supported configuration of {op-system-bundle} can require updating {microshift-short} and {op-system-base} at the same time. Ensure that your version of {op-system-base} is compatible with the version of {microshift-short} you are updating to, especially if you are updating {microshift-short} across two minor versions. Otherwise, you can create an unsupported configuration, break your cluster, or both. For more information, see the link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/getting_ready_to_install_microshift/microshift-install-get-ready#get-ready-install-rhde-compatibility-table_microshift-install-get-ready[Red Hat Device Edge release compatibility matrix].
+====
\ No newline at end of file
diff --git a/modules/olm-terms.adoc b/snippets/of-terms-snippet.adoc
similarity index 79%
rename from modules/olm-terms.adoc
rename to snippets/of-terms-snippet.adoc
index 0bb6c1a317f3..5a49212e39b8 100644
--- a/modules/olm-terms.adoc
+++ b/snippets/of-terms-snippet.adoc
@@ -1,10 +1,9 @@
-// Module included in the following assemblies:
+// Text snippet included in the following assemblies:
 //
-// * operators/understanding/olm/olm-common-terms.adoc
+// * extensions/of-terms.adoc
+// * operators/understanding/olm-common-terms.adoc
 
-:_mod-docs-content-type: CONCEPT
-[id="olm-common-terms-glossary_{context}"]
-= Common Operator Framework terms
+:_mod-docs-content-type: SNIPPET
 
 [id="olm-common-terms-bundle_{context}"]
 == Bundle
@@ -43,6 +42,13 @@ An Operator may have a _dependency_ on another Operator being present in the clu
 
 OLM resolves dependencies by ensuring that all specified versions of Operators and CRDs are installed on the cluster during the installation phase. This dependency is resolved by finding and installing an Operator in a catalog that satisfies the required CRD API, and is not related to packages or bundles.
 
+[id="olm-common-terms-extension_{context}"]
+== Extension
+
+Extensions enable cluster administrators to extend capabilities for users on their {product-title} cluster. Extensions are managed by {olmv1-first}.
+
+The `ClusterExtension` API streamlines management of installed extensions, which includes Operators via the `registry+v1` bundle format, by consolidating user-facing APIs into a single object. Administrators and SREs can use the API to automate processes and define desired states by using GitOps principles.
+
 [id="olm-common-terms-index-image_{context}"]
 == Index image
 In the bundle format, an _index image_ refers to an image of a database (a database snapshot) that contains information about Operator bundles including CSVs and CRDs of all versions. This index can host a history of Operators on a cluster and be maintained by adding or removing Operators using the `opm` CLI tool.
@@ -57,6 +63,13 @@ A _tenant_ in {product-title} is a user or group of users that share common acce
 
 When a cluster is shared by multiple users or groups, it is considered a _multitenant_ cluster.
 
+[id="olm-common-terms-operator_{context}"]
+== Operator
+
+Operators are a method of packaging, deploying, and managing a Kubernetes application. A Kubernetes application is an app that is both deployed on Kubernetes and managed using the Kubernetes APIs and `kubectl` or `oc` tooling.
+
+In {olmv1-first}, the `ClusterExtension` API streamlines management of installed extensions, which includes Operators via the `registry+v1` bundle format.
+
 [id="olm-common-terms-operatorgroup_{context}"]
 == Operator group
 
@@ -77,3 +90,5 @@ A _subscription_ keeps CSVs up to date by tracking a channel in a package.
 [id="olm-common-terms-update-graph_{context}"]
 == Update graph
 An _update graph_ links versions of CSVs together, similar to the update graph of any other packaged software. Operators can be installed sequentially, or certain versions can be skipped. The update graph is expected to grow only at the head with newer versions being added.
+
+Also known as _update edges_ or _update paths_.
diff --git a/snippets/olmv1-known-issue-private-registries.adoc b/snippets/olmv1-known-issue-private-registries.adoc
index 3c370874a754..4785c426c58e 100644
--- a/snippets/olmv1-known-issue-private-registries.adoc
+++ b/snippets/olmv1-known-issue-private-registries.adoc
@@ -7,7 +7,7 @@
 // * extensions/catalogs/managing-catalogs.adoc
 // * extensions/catalogs/rh-catalogs.adoc
 // * extensions/ce/managing-ce.adoc
-// * extensions/ce/upgrade-edges.adoc
+// * extensions/ce/update-paths.adoc
 // * extensions/index.adoc
 
 :_mod-docs-content-type: SNIPPET
diff --git a/snippets/olmv1-manual-rbac-scoping-admonition.adoc b/snippets/olmv1-manual-rbac-scoping-admonition.adoc
new file mode 100644
index 000000000000..09e40d7cb6f9
--- /dev/null
+++ b/snippets/olmv1-manual-rbac-scoping-admonition.adoc
@@ -0,0 +1,11 @@
+// Text snippet included in the following modules:
+//
+// * modules/olmv1-cluster-extension-permissions.adoc
+// * modules/olmv1-creating-a-cluster-role.adoc
+
+:_mod-docs-content-type: SNIPPET
+
+[IMPORTANT]
+====
+To simply the following procedure and improve readability, the following example manifest uses permissions that are scoped to the cluster. You can further restrict some of the permissions by scoping them to the namespace of the extension instead of the cluster.
+====
diff --git a/snippets/olmv1-multi-catalog-admon.adoc b/snippets/olmv1-multi-catalog-admon.adoc
deleted file mode 100644
index df1a395680c2..000000000000
--- a/snippets/olmv1-multi-catalog-admon.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// Text snippet included in the following modules:
-//
-// * modules/olmv1-about-catalogs.adoc
-
-:_mod-docs-content-type: SNIPPET
-
-[IMPORTANT]
-====
-If you try to install an Operator or extension that does not have unique name, the installation might fail or lead to an unpredictable result. This occurs for the following reasons:
-
-* If mulitple catalogs are installed on a cluster, {olmv1-first} does not include a mechanism to specify a catalog when you install an Operator or extension.
-* {olmv1} requires that all of the Operators and extensions that are available to install on a cluster use a unique name for their bundles and packages.
-====
diff --git a/snippets/osdk-deprecation.adoc b/snippets/osdk-deprecation.adoc
index 32fa5a15f5ff..bdd1c0f2e776 100644
--- a/snippets/osdk-deprecation.adoc
+++ b/snippets/osdk-deprecation.adoc
@@ -18,12 +18,6 @@
 // * operators/operator_sdk/helm/osdk-helm-support.adoc
 // * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
 // * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
-// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
-// * operators/operator_sdk/java/osdk-java-project-layout.adoc
-// * operators/operator_sdk/java/osdk-java-quickstart.adoc
-// * operators/operator_sdk/java/osdk-java-tutorial.adoc
-// * operators/operator_sdk/java/osdk-java-updating-projects.adoc
 // * operators/operator_sdk/osdk-about.adoc
 // * operators/operator_sdk/osdk-bundle-validate.adoc
 // * operators/operator_sdk/osdk-cli-ref.adoc
diff --git a/snippets/otel-collector-custom-resource.adoc b/snippets/otel-collector-custom-resource.adoc
index 46e980664b0a..44b8b8113c5d 100644
--- a/snippets/otel-collector-custom-resource.adoc
+++ b/snippets/otel-collector-custom-resource.adoc
@@ -8,14 +8,14 @@
 .Example `OpenTelemetryCollector` CR
 [source,yaml]
 ----
-apiVersion: opentelemetry.io/v1alpha1
+apiVersion: opentelemetry.io/v1beta1
 kind: OpenTelemetryCollector
 metadata:
   name: otel
   namespace: <project_of_opentelemetry_collector_instance>
 spec:
   mode: deployment
-  config: |
+  config:
     receivers: # <1>
       otlp:
         protocols:
diff --git a/snippets/ptp-event-config-api-v2.adoc b/snippets/ptp-event-config-api-v2.adoc
index b37703328116..c7e6acdc24eb 100644
--- a/snippets/ptp-event-config-api-v2.adoc
+++ b/snippets/ptp-event-config-api-v2.adoc
@@ -10,9 +10,6 @@ spec:
   daemonNodeSelector:
     node-role.kubernetes.io/worker: ""
   ptpEventConfig:
-    apiVersion: 2.0 <1>
-    enableEventPublisher: true <2>
+    enableEventPublisher: true <1>
 ----
-<1> Enable the PTP events REST API v2 for the PTP event producer by setting the `ptpEventConfig.apiVersion` to 2.0.
-The default value is 1.0.
-<2> Enable PTP fast event notifications by setting `enableEventPublisher` to `true`.
+<1> Enable PTP fast event notifications by setting `enableEventPublisher` to `true`.
diff --git a/snippets/rosa-existing-vpc-requirements.adoc b/snippets/rosa-existing-vpc-requirements.adoc
new file mode 100644
index 000000000000..bc37f78551af
--- /dev/null
+++ b/snippets/rosa-existing-vpc-requirements.adoc
@@ -0,0 +1,28 @@
+//Included in:
+// * modules/rosa-hcp-vpc-manual.adoc
+// * rosa_planning/rosa-cloud-expert-prereq-checklist.adoc
+
+:_mod-docs-content-type: SNIPPET
+
+Your VPC must meet the requirements shown in the following table.
+
+.Requirements for your VPC
+[options="header",cols="50,50"]
+|===
+| Requirement | Details
+
+| VPC name
+| You need to have the specific VPC name and ID when creating your cluster.
+
+| CIDR range
+| Your VPC CIDR range should match your machine CIDR.
+
+| Availability zone
+| You need one availability zone for a single zone, and you need three for availability zones for multi-zone.
+
+| Public subnet
+| You must have one public subnet with a NAT gateway for public clusters. Private clusters do not need a public subnet.
+
+| DNS hostname and resolution
+| You must ensure that the DNS hostname and resolution are enabled.
+|===
\ No newline at end of file
diff --git a/snippets/rosa-hcp-rn.adoc b/snippets/rosa-hcp-rn.adoc
index 7bd29c9930e5..023c229696e9 100644
--- a/snippets/rosa-hcp-rn.adoc
+++ b/snippets/rosa-hcp-rn.adoc
@@ -3,4 +3,4 @@
 // * rosa_release_notes/rosa-release-notes.adoc
 
 :_mod-docs-content-type: SNIPPET
-* **Hosted control planes.** {hcp-title-first} clusters are now available as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] feature. This new architecture provides a lower-cost, more resilient ROSA architecture. For more information, see xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc[Creating {hcp-title} clusters using the default options].
\ No newline at end of file
+* **Hosted control planes.** {hcp-title-first} clusters are now available as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] feature. This new architecture provides a lower-cost, more resilient ROSA architecture. For more information, see xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Creating {hcp-title} clusters using the default options].
\ No newline at end of file
diff --git a/snippets/rosa-sts.adoc b/snippets/rosa-sts.adoc
index 22abfb5af77d..2ce7395abcc7 100644
--- a/snippets/rosa-sts.adoc
+++ b/snippets/rosa-sts.adoc
@@ -2,5 +2,5 @@
 
 [TIP]
 ====
-AWS Security Token Service (STS) is the recommended credential mode for installing and interacting with clusters on Red Hat OpenShift Service on AWS (ROSA) because it provides enhanced security.
+AWS Security Token Service (STS) is the recommended credential mode for installing and interacting with clusters on {product-title} because it provides enhanced security.
 ====
diff --git a/snippets/siteconfig-deprecation-notice.adoc b/snippets/siteconfig-deprecation-notice.adoc
new file mode 100644
index 000000000000..bd1352eff21f
--- /dev/null
+++ b/snippets/siteconfig-deprecation-notice.adoc
@@ -0,0 +1,7 @@
+:_mod-docs-content-type: SNIPPET
+[IMPORTANT]
+====
+SiteConfig v1 is deprecated starting with {product-title} version 4.18. Equivalent and improved functionality is now available through the SiteConfig Operator using the `ClusterInstance` custom resource. For more information, see link:https://access.redhat.com/articles/7105238[Procedure to transition from SiteConfig CRs to the ClusterInstance API].
+
+For more information about the SiteConfig Operator, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html-single/multicluster_engine_operator_with_red_hat_advanced_cluster_management/index#siteconfig-intro[SiteConfig].
+====
diff --git a/snippets/update-image-stream-to-multi-arch.adoc b/snippets/update-image-stream-to-multi-arch.adoc
new file mode 100644
index 000000000000..9ecd5b82dc5c
--- /dev/null
+++ b/snippets/update-image-stream-to-multi-arch.adoc
@@ -0,0 +1,11 @@
+// Snippet included in the following assemblies:
+//
+// * updating/updating_a_cluster/migrating-from-x86-to-arm64-cp.adoc
+// * openshift_images/images-imagestream-specify-architecture.adoc
+
+:_mod-docs-content-type: SNIPPET
+[source,terminal]
+----
+$ oc import-image <multiarch_image_stream_tag>  --from=<registry>/<project_name>/<image_name> \
+--import-mode='PreserveOriginal'
+----
diff --git a/snippets/virt-dynamic-key.yaml b/snippets/virt-dynamic-key.yaml
index cd5b8eae9eb2..2caf565d526f 100644
--- a/snippets/virt-dynamic-key.yaml
+++ b/snippets/virt-dynamic-key.yaml
@@ -18,7 +18,7 @@ spec:
     name: u1.medium
   preference:
     name: rhel.9
-  running: true
+  runStrategy: Always
   template:
     spec:
       domain:
diff --git a/snippets/virt-static-key.yaml b/snippets/virt-static-key.yaml
index 14d2bf1e7a59..b80495a807a9 100644
--- a/snippets/virt-static-key.yaml
+++ b/snippets/virt-static-key.yaml
@@ -18,7 +18,7 @@ spec:
     name: u1.medium
   preference:
     name: rhel.9
-  running: true
+  runStrategy: Always
   template:
     spec:
       domain:
diff --git a/snippets/ztp-patch-argocd-hub-cluster.adoc b/snippets/ztp-patch-argocd-hub-cluster.adoc
index a75f8fa72174..4602d1a27892 100644
--- a/snippets/ztp-patch-argocd-hub-cluster.adoc
+++ b/snippets/ztp-patch-argocd-hub-cluster.adoc
@@ -5,38 +5,19 @@ Customize the patch file that you previously extracted into the `out/argocd/depl
 .. Select the `multicluster-operators-subscription` image that matches your {rh-rhacm} version.
 +
 --
-.`multicluster-operators-subscription` image versions
-[cols="1,1,1,1,3", options="header"]
-|====
-|{product-title} version
-|{rh-rhacm} version
-|MCE version
-|MCE RHEL version
-|MCE image
-
-|4.14, 4.15, 4.16
-|2.8, 2.9
-|2.8, 2.9
-|RHEL 8
-|`registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8`
-
-`registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9`
-
-|4.14, 4.15, 4.16
-|2.10
-|2.10
-|RHEL 9
-|`registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10`
-|====
+* For {rh-rhacm} 2.8 and 2.9, use the `registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version>` image.
+* For {rh-rhacm} 2.10 and later, use the `registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version>` image.
 
 [IMPORTANT]
 ====
-The version of the `multicluster-operators-subscription` image should match the {rh-rhacm} version.
-Beginning with the MCE 2.10 release, RHEL 9 is the base image for `multicluster-operators-subscription` images.
+The version of the `multicluster-operators-subscription` image must match the {rh-rhacm} version.
+Beginning with the MCE 2.10 release, {op-system-base} 9 is the base image for `multicluster-operators-subscription` images.
+
+Click `[Expand for Operator list]` in the "Platform Aligned Operators" table in link:https://access.redhat.com/support/policy/updates/openshift_operators[OpenShift Operator Life Cycles] to view the complete supported Operators matrix for {product-title}.
 ====
 --
 
-.. Add the following configuration to the `out/argocd/deployment/argocd-openshift-gitops-patch.json` file:
+.. Modify the `out/argocd/deployment/argocd-openshift-gitops-patch.json` file with the `multicluster-operators-subscription` image that matches your {rh-rhacm} version:
 +
 --
 [source,json]
diff --git a/snippets/ztp_example-sno.yaml b/snippets/ztp_example-sno.yaml
index 252eba507204..79dce7cb533c 100644
--- a/snippets/ztp_example-sno.yaml
+++ b/snippets/ztp_example-sno.yaml
@@ -9,7 +9,7 @@ spec:
   baseDomain: "example.com"
   pullSecretRef:
     name: "assisted-deployment-pull-secret"
-  clusterImageSetNameRef: "openshift-4.16"
+  clusterImageSetNameRef: "openshift-4.18"
   sshPublicKey: "ssh-rsa AAAA..."
   clusters:
     - clusterName: "example-sno"
diff --git a/storage/container_storage_interface/ephemeral-storage-csi-inline.adoc b/storage/container_storage_interface/ephemeral-storage-csi-inline.adoc
index 1ab952de8df0..e7a9c2f76ffb 100644
--- a/storage/container_storage_interface/ephemeral-storage-csi-inline.adoc
+++ b/storage/container_storage_interface/ephemeral-storage-csi-inline.adoc
@@ -12,7 +12,6 @@ Container Storage Interface (CSI) inline ephemeral volumes allow you to define a
 
 This feature is only available with supported Container Storage Interface (CSI) drivers:
 
-* Shared Resource CSI driver
 * Azure File CSI driver
 * {secrets-store-driver}
 
diff --git a/storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc b/storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc
index ed1458c8dbd7..7fe747cf2701 100644
--- a/storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc
+++ b/storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc
@@ -16,7 +16,7 @@ This procedure is specific to the link:https://github.com/openshift/aws-efs-csi-
 
 {product-title} is capable of provisioning persistent volumes (PVs) using the link:https://github.com/openshift/aws-efs-csi-driver[AWS EFS CSI driver].
 
-Familiarity with link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-overview_understanding-persistent-storage[persistent storage] and link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
+Familiarity with link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-overview_understanding-persistent-storage[persistent storage] and link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
 
 After installing the AWS EFS CSI Driver Operator, {product-title} installs the AWS EFS CSI Operator and the AWS EFS CSI driver by default in the `openshift-cluster-csi-drivers` namespace. This allows the AWS EFS CSI Driver Operator to create CSI-provisioned PVs that mount to AWS EFS assets.
 
@@ -87,5 +87,5 @@ include::modules/persistent-storage-csi-olm-operator-uninstall.adoc[leveloffset=
 [role="_additional-resources"]
 == Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-csi[Configuring CSI volumes]
+* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-csi[Configuring CSI volumes]
 
diff --git a/storage/container_storage_interface/persistent-storage-csi-azure-stack-hub.adoc b/storage/container_storage_interface/persistent-storage-csi-azure-stack-hub.adoc
index 390298dd3d7e..4de4185797c3 100644
--- a/storage/container_storage_interface/persistent-storage-csi-azure-stack-hub.adoc
+++ b/storage/container_storage_interface/persistent-storage-csi-azure-stack-hub.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 == Overview
 
-{product-title} is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for Azure Stack Hub Storage. Azure Stack Hub, which is part of the Azure Stack portfolio, allows you to run apps in an on-premises environment and deliver Azure services in your datacenter.
+{product-title} is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for Azure Stack Hub Storage. Azure Stack Hub, which is part of the Azure Stack portfolio, allows you to run apps in an on-premise environment and deliver Azure services in your datacenter.
 
 Familiarity with xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[persistent storage] and xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
 
diff --git a/storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc b/storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
index 60670a5edd0c..58b3ab5831c8 100644
--- a/storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
+++ b/storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc
@@ -18,7 +18,9 @@ To create CSI-provisioned persistent volumes (PVs) that mount to GCP PD storage
 
 * *GCP PD CSI Driver Operator*: By default, the Operator provides a storage class that you can use to create PVCs. You can disable this default storage class if desired (see xref:../../storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc#persistent-storage-csi-sc-manage[Managing the default storage class]). You also have the option to create the GCP PD storage class as described in xref:../../storage/persistent_storage/persistent-storage-gce.adoc#persistent-storage-using-gce[Persistent storage using GCE Persistent Disk].
 
-* *GCP PD driver*: The driver enables you to create and mount GCP PD PVs.
+* *GCP PD driver*: The driver enables you to create and mount GCP PD PVs. 
++
+GCP PD CSI driver supports the C3 instance type for bare metal and N4 machine series. The C3 instance type and N4 machine series support the hyperdisk-balanced disks.
 
 ifndef::openshift-dedicated[]
 [NOTE]
@@ -27,6 +29,24 @@ ifndef::openshift-dedicated[]
 ====
 endif::openshift-dedicated[]
 
+[id="c3-instance-type-for-bare-metal-and-n4-machine-series"]
+== C3 instance type for bare metal and N4 machine series
+
+include::modules/persistent-storage-csi-gcp-hyperdisk-limitations.adoc[leveloffset=+2]
+
+include::modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-overview.adoc[leveloffset=+2]
+
+To set up storage pools, see xref:../../storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc#persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure_persistent-storage-csi-gcp-pd[Setting up hyperdisk-balanced disks].
+
+include::modules/persistent-storage-csi-gcp-hyperdisk-storage-pools-procedure.adoc[leveloffset=+2]
+
+ifndef::openshift-dedicated[]
+[id="resources-for-gcp-c3-n4-instances"]
+[role="_additional-resources"]
+=== Additional resources
+* xref:../../installing/installing_gcp/installing-gcp-customizations.adoc#installing-gcp-customizations[Installing a cluster on GCP with customizations]
+endif::openshift-dedicated[]
+
 include::modules/persistent-storage-csi-about.adoc[leveloffset=+1]
 
 include::modules/persistent-storage-csi-gcp-pd-storage-class-ref.adoc[leveloffset=+1]
@@ -39,6 +59,7 @@ include::modules/persistent-storage-byok.adoc[leveloffset=+1]
 For information about installing with user-managed encryption for GCP PD, see xref:../../installing/installing_gcp/installing-gcp-customizations.adoc#installation-configuration-parameters_installing-gcp-customizations[Installation configuration parameters].
 endif::openshift-rosa,openshift-dedicated[]
 
+[id="resources-for-gcp"]
 [role="_additional-resources"]
 == Additional resources
 * xref:../../storage/persistent_storage/persistent-storage-gce.adoc#persistent-storage-using-gce[Persistent storage using GCE Persistent Disk]
diff --git a/storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc b/storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc
index a8c2a88363fa..ae0db18f6661 100644
--- a/storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc
+++ b/storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc
@@ -14,15 +14,27 @@ toc::[]
 
 Familiarity with xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[persistent storage] and xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
 
-To create CSI-provisioned PVs that mount to GCP Filestore Storage assets, you install the GCP Filestore CSI Driver Operator and the GCP Filestore CSI driver in the `openshift-cluster-csi-drivers` namespace.
+To create CSI-provisioned PVs that mount to {gcp-short} Filestore Storage assets, you install the {gcp-short} Filestore CSI Driver Operator and the {gcp-short} Filestore CSI driver in the `openshift-cluster-csi-drivers` namespace.
 
-* The _GCP Filestore CSI Driver Operator_ does not provide a storage class by default, but xref:../../storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc#persistent-storage-csi-google-cloud-file-create-sc_persistent-storage-csi-google-cloud-file[you can create one if needed]. The GCP Filestore CSI Driver Operator supports dynamic volume provisioning by allowing storage volumes to be created on demand, eliminating the need for cluster administrators to pre-provision storage.
+* The _{gcp-short} Filestore CSI Driver Operator_ does not provide a storage class by default, but xref:../../storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc#persistent-storage-csi-google-cloud-file-create-sc_persistent-storage-csi-google-cloud-file[you can create one if needed]. The {gcp-short} Filestore CSI Driver Operator supports dynamic volume provisioning by allowing storage volumes to be created on demand, eliminating the need for cluster administrators to pre-provision storage.
 
-* The _GCP Filestore CSI driver_ enables you to create and mount GCP Filestore PVs.
+* The _{gcp-short} Filestore CSI driver_ enables you to create and mount {gcp-short} Filestore PVs.
+
+{product-title} {gcp-short} Filestore supports Workload Identity. This allows users to access Google Cloud resources using federated identities instead of a service account key. {gcp-wid-short} must be enabled globally during installation, and then configured for the {gcp-short} Filestore CSI Driver Operator. For more information, see xref:../../storage/container_storage_interface/persistent-storage-csi-google-cloud-file.adoc#installing-the-gcp-filestore-csi-driver-operator[Installing the {gcp-short} Filestore CSI Driver Operator].
 
 include::modules/persistent-storage-csi-about.adoc[leveloffset=+1]
 
-include::modules/persistent-storage-csi-gcp-file-install.adoc[leveloffset=+1]
+== Installing the {gcp-short} Filestore CSI Driver Operator
+
+include::modules/persistent-storage-csi-gcp-filestore-wif.adoc[leveloffset=+2]
+
+ifndef::openshift-dedicated[]
+[role="_additional-resources"]
+.Additional resources
+* xref:../../installing/installing_gcp/installing-gcp-customizations.adoc#cco-ccoctl-creating-at-once_installing-gcp-customizations[Creating {gcp-short} resources with the Cloud Credential Operator utility]
+endif::[]
+
+include::modules/persistent-storage-csi-gcp-file-install.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
@@ -36,3 +48,7 @@ include::modules/persistent-storage-csi-google-cloud-file-delete-instances.adoc[
 [role="_additional-resources"]
 == Additional resources
 * xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-csi[Configuring CSI volumes]
+ifndef::openshift-dedicated[]
+[id="osdk-cco-gpc_{context}"]
+* xref:../../operators/operator_sdk/token_auth/osdk-cco-gcp.adoc[CCO-based workflow for OLM-managed Operators with {gcp-short} Workload Identity].
+endif::openshift-dedicated[]
diff --git a/storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc b/storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
new file mode 100644
index 000000000000..329e1645b693
--- /dev/null
+++ b/storage/container_storage_interface/persistent-storage-csi-group-snapshots.adoc
@@ -0,0 +1,29 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="persistent-storage-csi-group-snapshots"]
+= CSI volume group snapshots
+include::_attributes/common-attributes.adoc[]
+:context: persistent-storage-csi-group-snapshots
+
+toc::[]
+
+This document describes how to use volume group snapshots with supported Container Storage Interface (CSI) drivers to help protect against data loss in {product-title}. Familiarity with xref:../../storage/understanding-persistent-storage.adoc#persistent-volumes_understanding-persistent-storage[persistent volumes] is suggested.
+
+:FeatureName: CSI volume group snapshots
+include::snippets/technology-preview.adoc[leveloffset=+1]
+
+To use this Technology Preview feature, you must xref:../../hosted_control_planes/hcp-using-feature-gates.adoc#hcp-enable-feature-sets_hcp-using-feature-gates[enable it using feature gates].
+
+include::modules/persistent-storage-csi-group-snapshots-overview.adoc[leveloffset=+1]
+
+include::modules/persistent-storage-csi-group-snapshots-limitations.adoc[leveloffset=+1]
+
+include::modules/persistent-storage-csi-group-snapshot-create-admin.adoc[leveloffset=+1]
+
+include::modules/persistent-storage-csi-group-snapshots-create.adoc[leveloffset=+1]
+
+include::modules/persistent-storage-csi-group-snapshots-restore.adoc[leveloffset=+1]
+
+== Additional resources
+* xref:../../storage/container_storage_interface/persistent-storage-csi-snapshots.adoc#persistent-storage-csi-snapshots[CSI volume snapshots]
+
+* xref:../../hosted_control_planes/hcp-using-feature-gates.adoc#hcp-enable-feature-sets_hcp-using-feature-gates[Enabling features sets by using feature gates]
\ No newline at end of file
diff --git a/storage/container_storage_interface/persistent-storage-csi-vsphere.adoc b/storage/container_storage_interface/persistent-storage-csi-vsphere.adoc
index 4492ba386c58..f0997ea91fbb 100644
--- a/storage/container_storage_interface/persistent-storage-csi-vsphere.adoc
+++ b/storage/container_storage_interface/persistent-storage-csi-vsphere.adoc
@@ -16,7 +16,7 @@ To create CSI-provisioned persistent volumes (PVs) that mount to vSphere storage
 
 * *vSphere CSI Driver Operator*: The Operator provides a storage class, called `thin-csi`, that you can use to create persistent volumes claims (PVCs). The vSphere CSI Driver Operator supports dynamic volume provisioning by allowing storage volumes to be created on-demand, eliminating the need for cluster administrators to pre-provision storage. You can disable this default storage class if desired (see xref:../../storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc#persistent-storage-csi-sc-manage[Managing the default storage class]).
 
-* *vSphere CSI driver*: The driver enables you to create and mount vSphere PVs. In {product-title} 4.17, the driver version is 3.2.0 The vSphere CSI driver supports all of the file systems supported by the underlying Red Hat Core operating system release, including XFS and Ext4. For more information about supported file systems, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/overview-of-available-file-systems_managing-file-systems[Overview of available file systems].
+* *vSphere CSI driver*: The driver enables you to create and mount vSphere PVs. In {product-title} 4.18, the driver version is 3.3.1 The vSphere CSI driver supports all of the file systems supported by the underlying Red Hat Core operating system release, including XFS and Ext4. For more information about supported file systems, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/overview-of-available-file-systems_managing-file-systems[Overview of available file systems].
 
 //Please update driver version as needed with each major OCP release starting with 4.13.
 
@@ -75,9 +75,6 @@ include::modules/persistent-storage-csi-vsphere-encryption-tag-based.adoc[levelo
 
 include::modules/persistent-storage-csi-vsphere-multi-vcenter-support-overview.adoc[leveloffset=+1]
 
-:FeatureName: Multiple vCenter support for vSphere CSI
-include::snippets/technology-preview.adoc[leveloffset=+1]
-
 include::modules/persistent-storage-csi-vsphere-multi-vcenter-support-procedure-install.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
diff --git a/storage/container_storage_interface/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc b/storage/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc
similarity index 69%
rename from storage/container_storage_interface/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc
rename to storage/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc
index a01e2e35ef7f..602b9ed5ed35 100644
--- a/storage/container_storage_interface/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc
+++ b/storage/persistent-storage-csi-vol-detach-non-graceful-shutdown.adoc
@@ -1,12 +1,12 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="ephemeral-storage-csi-vol-detach-non-graceful-shutdown"]
-= Detach CSI volumes after non-graceful node shutdown
+= Detach volumes after non-graceful node shutdown
 include::_attributes/common-attributes.adoc[]
 :context: ephemeral-storage-csi-vol-detach-non-graceful-shutdown
 
 toc::[]
 
-This feature allows Container Storage Interface (CSI) drivers to automatically detach volumes when a node goes down non-gracefully.
+This feature allows drivers to automatically detach volumes when a node goes down non-gracefully.
 
 include::modules/persistent-storage-csi-vol-detach-non-graceful-shutdown-overview.adoc[leveloffset=+1]
 
diff --git a/storage/persistent_storage/persistent_storage_local/persistent-storage-local.adoc b/storage/persistent_storage/persistent_storage_local/persistent-storage-local.adoc
index 5cc3cbf228ec..3104dd1f09aa 100644
--- a/storage/persistent_storage/persistent_storage_local/persistent-storage-local.adoc
+++ b/storage/persistent_storage/persistent_storage_local/persistent-storage-local.adoc
@@ -37,7 +37,7 @@ include::modules/persistent-storage-local-tolerations.adoc[leveloffset=+1]
 
 include::modules/persistent-storage-local-metrics.adoc[leveloffset=+1]
 
-For more information about metrics, see xref:../../../observability/monitoring/managing-metrics.adoc#managing-metric[Managing metrics].
+For more information about metrics, see xref:../../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#accessing-metrics-as-an-administrator[Accessing metrics as an administrator].
 
 == Deleting the Local Storage Operator resources
 
diff --git a/storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc b/storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc
index 34389b6950eb..1222155b284f 100644
--- a/storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc
+++ b/storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc
@@ -33,9 +33,9 @@ include::modules/lvms-installing-logical-volume-manager-operator-disconnected-en
 
 * xref:../../../disconnected/mirroring/installing-mirroring-installation-images.adoc#installation-mirror-repository_installing-mirroring-installation-images[Mirroring the OpenShift Container Platform image repository]
 
-* xref:../../../disconnected/mirroring/installing-mirroring-disconnected.adoc#oc-mirror-creating-image-set-config_installing-mirroring-disconnected[Creating the image set configuration]
+* xref:../../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#oc-mirror-building-image-set-config-v2_about-installing-oc-mirror-v2[Creating the image set configuration]
 
-* xref:../../../disconnected/mirroring/installing-mirroring-disconnected.adoc#mirroring-image-set[Mirroring an image set to a mirror registry]
+* xref:../../../disconnected/mirroring/about-installing-oc-mirror-v2.adoc#using-oc-mirror_about-installing-oc-mirror-v2[Mirroring an image set to a mirror registry]
 
 * xref:../../../openshift_images/image-configuration.adoc#images-configuration-registry-mirror_image-configuration[Configuring image registry repository mirroring]
 
diff --git a/storage/persistent_storage/rosa-persistent-storage-aws-efs-csi.adoc b/storage/persistent_storage/rosa-persistent-storage-aws-efs-csi.adoc
index 3a412c675521..7d063d48947a 100644
--- a/storage/persistent_storage/rosa-persistent-storage-aws-efs-csi.adoc
+++ b/storage/persistent_storage/rosa-persistent-storage-aws-efs-csi.adoc
@@ -16,7 +16,7 @@ This procedure is specific to the Amazon Web Services Elastic File System (AWS E
 
 {product-title} is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for AWS Elastic File Service (EFS).
 
-Familiarity with link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-overview_understanding-persistent-storage[persistent storage] and link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
+Familiarity with link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-overview_understanding-persistent-storage[persistent storage] and link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-csi[configuring CSI volumes] is recommended when working with a CSI Operator and driver.
 
 After installing the AWS EFS CSI Driver Operator, {product-title} installs the AWS EFS CSI Operator and the AWS EFS CSI driver by default in the `openshift-cluster-csi-drivers` namespace. This allows the AWS EFS CSI Driver Operator to create CSI-provisioned PVs that mount to AWS EFS assets.
 
@@ -51,7 +51,7 @@ include::modules/persistent-storage-csi-efs-sts.adoc[leveloffset=+1]
 * xref:../../storage/persistent_storage/rosa-persistent-storage-aws-efs-csi.adoc#persistent-storage-csi-olm-operator-install_rosa-persistent-storage-aws-efs-csi[Installing the AWS EFS CSI Driver Operator]
 
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/authentication_and_authorization/index#cco-ccoctl-configuring_cco-mode-sts[Configuring the Cloud Credential Operator utility]
+* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/authentication_and_authorization/index#cco-ccoctl-configuring_cco-mode-sts[Configuring the Cloud Credential Operator utility]
 
 :StorageClass: AWS EFS
 :Provisioner: efs.csi.aws.com
@@ -80,5 +80,5 @@ include::modules/persistent-storage-csi-olm-operator-uninstall.adoc[leveloffset=
 [role="_additional-resources"]
 == Additional resources
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.17/html-single/storage/index#persistent-storage-csi[Configuring CSI volumes]
+* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html-single/storage/index#persistent-storage-csi[Configuring CSI volumes]
 
diff --git a/support/approved-access.adoc b/support/approved-access.adoc
index 064819defd71..28437a09f0f6 100644
--- a/support/approved-access.adoc
+++ b/support/approved-access.adoc
@@ -9,7 +9,7 @@ endif::[]
 
 toc::[]
 
-Red{nbsp}Hat Site Reliability Engineering (SRE) typically does not require elevated access to systems as part of normal operations to manage and support {product-title} clusters. Elevated access gives SRE the access levels of a cluster-admin role. See link:https://docs.openshift.com/container-platform/4.17/authentication/using-rbac.html#default-roles_using-rbac[cluster roles] for more information.
+Red{nbsp}Hat Site Reliability Engineering (SRE) typically does not require elevated access to systems as part of normal operations to manage and support {product-title} clusters. Elevated access gives SRE the access levels of a cluster-admin role. See link:https://docs.openshift.com/container-platform/4.18/authentication/using-rbac.html#default-roles_using-rbac[cluster roles] for more information.
 
 In the unlikely event that SRE needs elevated access to systems, you can use the _Approved Access_ interface to review and _approve_ or _deny_ access to these systems.
 
@@ -17,7 +17,7 @@ Elevated access requests to clusters on {product-rosa} clusters and the correspo
 
 When _Approved Access_ is enabled and an SRE creates an access request, _cluster owners_ receive an email notification informing them of a new access request. The email notification contains a link allowing the cluster owner to quickly approve or deny the access request. You must respond in a timely manner otherwise there is a risk to your SLA for {product-rosa}.
 
-* If customers require additional users that are not the cluster owner to receive the email, they can link:https://docs.openshift.com/rosa/rosa_cluster_admin/rosa-cluster-notifications.html#add-notification-contact_rosa-cluster-notifications[add notification cluster contacts].
+* If customers require additional users that are not the cluster owner to receive the email, they can xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[add notification cluster contacts].
 * Pending access requests are available in the {hybrid-console-second} on the clusters list or *Access Requests* tab on the cluster overview for the specific cluster.
 
 [NOTE]
@@ -28,5 +28,3 @@ Denying an access request requires you to complete the *Justification* field. In
 include::modules/support-submitting-a-case-enable-approved-access.adoc[leveloffset=+1]
 include::modules/support-reviewing-an-access-request-from-an-email-notification.adoc[leveloffset=+1]
 include::modules/support-reviewing-an-access-request-from-the-hybrid-console.adoc[leveloffset=+1]
-
-
diff --git a/support/gathering-cluster-data.adoc b/support/gathering-cluster-data.adoc
index b099c20bad85..fb16a47f77f8 100644
--- a/support/gathering-cluster-data.adoc
+++ b/support/gathering-cluster-data.adoc
@@ -9,7 +9,7 @@ endif::[]
 
 toc::[]
 
-ifndef::openshift-origin,openshift-rosa,openshift-dedicated[]
+ifndef::openshift-origin[]
 When opening a support case, it is helpful to provide debugging
 information about your cluster to Red Hat Support.
 
@@ -17,11 +17,11 @@ It is recommended to provide:
 
 * xref:../support/gathering-cluster-data.adoc#support_gathering_data_gathering-cluster-data[Data gathered using the `oc adm must-gather` command]
 * The  xref:../support/gathering-cluster-data.adoc#support-get-cluster-id_gathering-cluster-data[unique cluster ID]
-endif::openshift-origin,openshift-rosa,openshift-dedicated[]
+endif::openshift-origin[]
 
-ifdef::openshift-origin,openshift-rosa,openshift-dedicated[]
+ifdef::openshift-origin[]
 You can use the following tools to get debugging information about your {product-title} cluster.
-endif::openshift-origin,openshift-rosa,openshift-dedicated[]
+endif::openshift-origin[]
 
 // About the must-gather tool
 include::modules/about-must-gather.adoc[leveloffset=+1]
@@ -31,6 +31,12 @@ ifndef::openshift-origin[]
 include::modules/support-gather-data.adoc[leveloffset=+2]
 endif::openshift-origin[]
 
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp-troubleshooting.adoc#hosted-control-planes-troubleshooting_hcp-troubleshooting[Gathering information to troubleshoot {hcp}]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+
 ifndef::openshift-origin[]
 // Table of must-gather flags
 include::modules/must-gather-flags.adoc[leveloffset=+2]
@@ -39,17 +45,22 @@ endif::openshift-origin[]
 // Gathering data about specific features
 include::modules/gathering-data-specific-features.adoc[leveloffset=+2]
 
-== Additional resources
+[role="_additional-resources"]
+.Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../nodes/cma/nodes-cma-autoscaling-custom.adoc#nodes-cma-autoscaling-custom-gather[Gathering debugging data] for the Custom Metrics Autoscaler.
 * link:https://access.redhat.com/support/policy/updates/openshift[Red Hat {product-title} Life Cycle Policy]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ifdef::openshift-rosa[]
 * xref:../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.html[{product-title} update life cycle]
 endif::openshift-rosa[]
 
+ifdef::openshift-rosa-hcp[]
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.html[{product-title} update life cycle]
+endif::openshift-rosa-hcp[]
+
 ifdef::openshift-dedicated[]
 * xref:../osd_architecture/osd_policy/osd-life-cycle.html[{product-title} update life cycle]
 endif::openshift-dedicated[]
@@ -65,18 +76,18 @@ ifndef::openshift-origin[]
 include::modules/support-get-cluster-id.adoc[leveloffset=+1]
 endif::openshift-origin[]
 
-ifndef::openshift-origin,openshift-rosa,openshift-dedicated[]
+ifndef::openshift-origin,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // About `sosreport`
 include::modules/about-sosreport.adoc[leveloffset=+1]
 
 // Generating a `sosreport` archive for an {product-title} cluster node
 include::modules/support-generating-a-sosreport-archive.adoc[leveloffset=+1]
-endif::openshift-origin,openshift-rosa,openshift-dedicated[]
+endif::openshift-origin,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // Querying bootstrap node journal logs
 include::modules/querying-bootstrap-node-journal-logs.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Querying cluster node journal logs
 include::modules/querying-cluster-node-journal-logs.adoc[leveloffset=+1]
diff --git a/support/index.adoc b/support/index.adoc
index 8d8b54c92ad2..9c7068dad66c 100644
--- a/support/index.adoc
+++ b/support/index.adoc
@@ -12,20 +12,20 @@ Red Hat offers cluster administrators tools for gathering data for your cluster,
 == Get support
 xref:../support/getting-support.adoc#getting-support[Get support]: Visit the Red Hat Customer Portal to review knowledge base articles, submit a support case, and review additional product documentation and resources.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [id='support-overview-remote-health-monitoring']
 == Remote health monitoring issues
 xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[Remote health monitoring issues]:
 {product-title} collects telemetry and configuration data about your cluster and reports it to Red Hat by using the Telemeter Client and the Insights Operator. Red Hat uses this data to understand and resolve issues in _connected cluster_. Similar to connected clusters, you can xref:../support/remote_health_monitoring/remote-health-reporting-from-restricted-network.adoc#remote-health-reporting-from-restricted-network[Use remote health monitoring in a restricted network]. {product-title} collects data and monitors health using the following:
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Removed sentence on restricted networks, not supported in ROSA/OSD
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [id='support-overview-remote-health-monitoring']
 == Remote health monitoring issues
 xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[Remote health monitoring issues]:
 {product-title} collects telemetry and configuration data about your cluster and reports it to Red Hat by using the Telemeter Client and the Insights Operator. Red Hat uses this data to understand and resolve issues in _connected cluster_. {product-title} collects data and monitors health using the following:
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * *Telemetry*: The Telemetry Client gathers and uploads the metrics values to Red Hat every four minutes and thirty seconds. Red Hat uses this data to:
 
@@ -42,8 +42,6 @@ You can xref:../support/remote_health_monitoring/showing-data-collected-by-remot
 
 If you have enabled remote health reporting, xref:../support/remote_health_monitoring/using-insights-to-identify-issues-with-your-cluster.adoc#using-insights-to-identify-issues-with-your-cluster[Use Insights to identify issues]. You can optionally disable remote health reporting.
 
-// must-gather not supported for customers, per Dustin Row, cannot create resource "namespaces"
-ifndef::openshift-rosa,openshift-dedicated[]
 [id='support-overview-gather-data-cluster']
 == Gather data about your cluster
 xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gather data about your cluster]: Red Hat recommends gathering your debugging information when opening a support case. This helps Red Hat Support to perform a root cause analysis. A cluster administrator can use the following to gather data about your cluster:
@@ -51,32 +49,32 @@ xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gather data a
 * *The must-gather tool*: Use the `must-gather` tool to collect information about your cluster and to debug the issues.
 * *sosreport*:  Use the `sosreport` tool to collect configuration details, system information, and diagnostic data for debugging purposes.
 * *Cluster ID*: Obtain the unique identifier for your cluster, when providing information to Red Hat Support.
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * *Bootstrap node journal logs*: Gather `bootkube.service` `journald` unit logs and container logs from the bootstrap node to troubleshoot bootstrap-related issues.
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * *Cluster node journal logs*: Gather `journald` unit logs and logs within `/var/log` on individual cluster nodes to troubleshoot node-related issues.
 * *A network trace*: Provide a network packet trace from a specific {product-title} cluster node or a container to Red Hat Support to help troubleshoot network-related issues.
-* *Diagnostic data*: Use the `redhat-support-tool` command to gather(?) diagnostic data about your cluster.
-endif::openshift-rosa,openshift-dedicated[]
 
 [id='support-overview-troubleshooting-issues']
 == Troubleshooting issues
 
 A cluster administrator can monitor and troubleshoot the following {product-title} component issues:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../support/troubleshooting/troubleshooting-installations.adoc#troubleshooting-installations[Installation issues]: {product-title} installation proceeds through various stages. You can perform the following:
 
 ** Monitor the installation stages.
 ** Determine at which stage installation issues occur.
 ** Investigate multiple installation issues.
 ** Gather logs from a failed installation.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * xref:../support/troubleshooting/verifying-node-health.adoc#verifying-node-health[Node issues]: A cluster administrator can verify and troubleshoot node-related issues by reviewing the status, resource usage, and configuration of a node. You can query the following:
 
-** Kubelet’s status on a node.
+** Kubelet's status on a node.
 ** Cluster node journal logs.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../support/troubleshooting/troubleshooting-crio-issues.adoc#troubleshooting-crio-issues[Crio issues]: A cluster administrator can verify CRI-O container runtime engine status on each cluster node. If you experience container runtime issues, perform the following:
 
 ** Gather CRI-O journald unit logs.
@@ -87,15 +85,15 @@ ifndef::openshift-rosa,openshift-dedicated[]
 ** Enable kdump.
 ** Test the kdump configuration.
 ** Analyze a core dump.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../support/troubleshooting/troubleshooting-network-issues.adoc#troubleshooting-network-issues[Network issues]: To troubleshoot Open vSwitch issues, a cluster administrator can perform the following:
 
 ** Configure the Open vSwitch log level temporarily.
 ** Configure the Open vSwitch log level permanently.
 ** Display Open vSwitch logs.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-operator-issues[Operator issues]: A cluster administrator can do the following to resolve Operator issues:
 
@@ -108,12 +106,10 @@ endif::openshift-rosa,openshift-dedicated[]
 ** Review pod and container logs.
 ** Start debug pods with root access.
 
-ifndef::openshift-rosa,openshift-dedicated[]
 * xref:../support/troubleshooting/troubleshooting-s2i.adoc#troubleshooting-s2i[Source-to-image issues]: A cluster administrator can observe the S2I stages to determine where in the S2I process a failure occurred. Gather the following to resolve Source-to-Image (S2I) issues:
 
 ** Source-to-Image diagnostic data.
 ** Application diagnostic data to investigate application failure.
-endif::openshift-rosa,openshift-dedicated[]
 
 * xref:../support/troubleshooting/troubleshooting-storage-issues.adoc#troubleshooting-storage-issues[Storage issues]: A multi-attach storage error occurs when the mounting volume on a new node is not possible because the failed node cannot unmount the attached volume. A cluster administrator can do the following to resolve multi-attach storage issues:
 
@@ -125,11 +121,15 @@ endif::openshift-rosa,openshift-dedicated[]
 ** Investigate why user-defined metrics are unavailable.
 ** Determine why Prometheus is consuming a lot of disk space.
 
-* xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging issues]: A cluster administrator can follow the procedures in the "Support" and "Troubleshooting logging" sections to resolve logging issues:
+////
+----
+* xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging issues]: A cluster administrator can follow the procedures in the "Support" and "Troubleshooting logging" sections to resolve logging issues:
 
-** xref:../observability/logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-clo-status_cluster-logging-cluster-status[Viewing the status of the {clo}]
-** xref:../observability/logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-clo-status-comp_cluster-logging-cluster-status[Viewing the status of {logging} components]
-** xref:../observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc#troubleshooting-logging-alerts[Troubleshooting logging alerts]
-** xref:../observability/logging/cluster-logging-support.adoc#cluster-logging-must-gather-collecting_cluster-logging-support[Collecting information about your logging environment by using the `oc adm must-gather` command]
+** xref :../observability/logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-clo-status_cluster-logging-cluster-status[Viewing the status of the {clo}]
+** xref :../observability/logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-clo-status-comp_cluster-logging-cluster-status[Viewing the status of {logging} components]
+** xref :../observability/logging/troubleshooting/troubleshooting-logging-alerts.adoc#troubleshooting-logging-alerts[Troubleshooting logging alerts]
+** xref :../observability/logging/cluster-logging-support.adoc#cluster-logging-must-gather-collecting_cluster-logging-support[Collecting information about your logging environment by using the `oc adm must-gather` command]
+----
+////
 
 * xref:../support/troubleshooting/diagnosing-oc-issues.adoc#diagnosing-oc-issues[{oc-first} issues]: Investigate {oc-first} issues by increasing the log level.
diff --git a/support/remote_health_monitoring/about-remote-health-monitoring.adoc b/support/remote_health_monitoring/about-remote-health-monitoring.adoc
index c464e50b9d37..291569bbe3cb 100644
--- a/support/remote_health_monitoring/about-remote-health-monitoring.adoc
+++ b/support/remote_health_monitoring/about-remote-health-monitoring.adoc
@@ -33,9 +33,9 @@ Telemetry and the Insights Operator enable the following benefits for end-users:
 
 * *Predictive analytics*. The insights displayed for your cluster on {cluster-manager-url} are enabled by the information collected from connected clusters. Red Hat is investing in applying deep learning, machine learning, and artificial intelligence automation to help identify issues that {product-title} clusters are exposed to.
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 On {product-title}, remote health reporting is always enabled. You cannot opt out of it.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 ifdef::openshift-origin[]
 {product-title} may be installed without a pull secret received at console.redhat.com. In this case default imagestreams will not be imported and telemetry data will not be sent.
@@ -43,19 +43,28 @@ endif::[]
 
 include::modules/telemetry-about-telemetry.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
-
 [role="_additional-resources"]
 .Additional resources
 
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * See the xref:../../updating/updating_a_cluster/updating-cluster-web-console.adoc#updating-cluster-web-console[{product-title} update documentation] for more information about updating or upgrading a cluster.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ifdef::openshift-rosa[]
+* See the xref:../../upgrading/rosa-upgrading-sts.adoc#rosa-upgrading-sts[{product-title} upgrade documentation] for more information about upgrading a cluster.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+* See the xref:../../upgrading/rosa-hcp-upgrading.adoc#rosa-hcp-upgrading[{product-title} upgrade documentation] for more information about upgrading a cluster.
+endif::openshift-rosa-hcp[]
+ifdef::openshift-dedicated[]
+* See the xref:../../upgrading/osd-upgrades.adoc#osd-upgrades[{product-title} upgrade documentation] for more information about upgrading a cluster.
+endif::openshift-dedicated[]
 
 include::modules/telemetry-what-information-is-collected.adoc[leveloffset=+2]
+
 // Module is not in OCP
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/telemetry-user-telemetry.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 [role="_additional-resources"]
 .Additional resources
@@ -64,46 +73,51 @@ endif::openshift-rosa,openshift-dedicated[]
 
 * See the link:https://github.com/openshift/cluster-monitoring-operator/blob/master/manifests/0000_50_cluster-monitoring-operator_04-config.yaml[upstream cluster-monitoring-operator source code] for a list of the attributes that Telemetry gathers from Prometheus.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * Telemetry is installed and enabled by default. If you need to opt out of remote health reporting, see xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting[Opting out of remote health reporting].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/insights-operator-about.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * The Insights Operator is installed and enabled by default. If you need to opt out of remote health reporting, see xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting[Opting out of remote health reporting].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/insights-operator-what-information-is-collected.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * See xref:../../support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc#insights-operator-showing-data-collected-from-the-cluster_showing-data-collected-by-remote-health-monitoring[Showing data collected by the Insights Operator] for details about how to review the data that is collected by the Insights Operator.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * link:https://access.redhat.com/solutions/7066188[What data is being collected by the Insights Operator in OpenShift?]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * The Insights Operator source code is available for review and contribution. See the link:https://github.com/openshift/insights-operator/blob/master/docs/gathered-data.md[Insights Operator upstream project] for a list of the items collected by the Insights Operator.
 
 include::modules/understanding-telemetry-and-insights-operator-data-flow.adoc[leveloffset=+1]
 
+// TODO: Add the first xref to ROSA HCP when the monitoring book is migrated.
+ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
-
-* See xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview_monitoring-overview[Monitoring overview] for more information about the {product-title} monitoring stack.
+ifdef::openshift-rosa,openshift-dedicated[]
+* See xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+endif::openshift-rosa,openshift-dedicated[]
 
 ifndef::openshift-rosa,openshift-dedicated[]
+* See xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring] for more information about the {product-title} monitoring stack.
 * See xref:../../installing/install_config/configuring-firewall.adoc#configuring-firewall[Configuring your firewall] for details about configuring a firewall and enabling endpoints for Telemetry and Insights
 endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp[]
 
 [id="additional-details-about-how-remote-health-monitoring-data-is-used"]
 == Additional details about how remote health monitoring data is used
@@ -118,7 +132,7 @@ Red Hat employs technical and organizational measures designed to protect the te
 
 .Sharing
 
-Red Hat may share the data collected through Telemetry and the Insights Operator internally within Red Hat to improve your user experience. Red Hat may share telemetry and configuration data with its business partners in an aggregated form that does not identify customers to help the partners better understand their markets and their customers’ use of Red Hat offerings or to ensure the successful integration of products jointly supported by those partners.
+Red Hat may share the data collected through Telemetry and the Insights Operator internally within Red Hat to improve your user experience. Red Hat may share telemetry and configuration data with its business partners in an aggregated form that does not identify customers to help the partners better understand their markets and their customers' use of Red Hat offerings or to ensure the successful integration of products jointly supported by those partners.
 
 .Third parties
 
@@ -126,6 +140,6 @@ Red Hat may engage certain third parties to assist in the collection, analysis,
 
 .User control / enabling and disabling telemetry and configuration data collection
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 You may disable {product-title} Telemetry and the Insights Operator by following the instructions in xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting[Opting out of remote health reporting].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc b/support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc
index 2844c800ae1a..af97adfc1e32 100644
--- a/support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc
+++ b/support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc
@@ -14,6 +14,6 @@ As an administrator, you can review the metrics collected by Telemetry and the I
 include::modules/telemetry-showing-data-collected-from-the-cluster.adoc[leveloffset=+1]
 
 // cannot create resource "pods/exec" in API group "" in the namespace "openshift-insights"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/insights-operator-showing-data-collected-from-the-cluster.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/support/remote_health_monitoring/using-insights-operator.adoc b/support/remote_health_monitoring/using-insights-operator.adoc
index 3dd0b0253898..15208afd8ac5 100644
--- a/support/remote_health_monitoring/using-insights-operator.adoc
+++ b/support/remote_health_monitoring/using-insights-operator.adoc
@@ -14,32 +14,32 @@ The Insights Operator periodically gathers configuration and component failure s
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * The Insights Operator is installed and enabled by default. If you need to opt out of remote health reporting, see xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting[Opting out of remote health reporting].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 * For more information on using Insights Advisor to identify issues with your cluster, see xref:../../support/remote_health_monitoring/using-insights-to-identify-issues-with-your-cluster.adoc#using-insights-to-identify-issues-with-your-cluster[Using Insights to identify issues with your cluster].
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/insights-operator-configuring.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/understanding-insights-operator-alerts.adoc[leveloffset=+1]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/disabling-insights-operator-alerts.adoc[leveloffset=+2]
 include::modules/enabling-insights-operator-alerts.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // cannot create resource "pods/exec" in API group "" in the namespace "openshift-insights"
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/insights-operator-downloading-archive.adoc[leveloffset=+1]
 // cannot download archive using previous module
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // InsightsDataGather is a Tech Preview feature. When the feature goes GA, verify if it can be added to ROSA/OSD.
 
 // tech preview feature
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [id="running-insights-operator-gather_using-insights-operator"]
 == Running an Insights Operator gather operation
 
@@ -61,11 +61,11 @@ include::modules/running-insights-operator-gather-cli.adoc[leveloffset=+2]
 .Additional resources
 * link:https://github.com/openshift/insights-operator/blob/master/docs/gathered-data.md[Insights Operator Gathered Data GitHub repository]
 
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // cannot list resource "secrets" in API group "" in the namespace "openshift-config"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/disabling-insights-operator-gather.adoc[leveloffset=+2]
 include::modules/enabling-insights-operator-gather.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/obfuscating-dvo-data.adoc[leveloffset=+1]
diff --git a/support/troubleshooting/investigating-monitoring-issues.adoc b/support/troubleshooting/investigating-monitoring-issues.adoc
index b3496d34621f..a86277744cd6 100644
--- a/support/troubleshooting/investigating-monitoring-issues.adoc
+++ b/support/troubleshooting/investigating-monitoring-issues.adoc
@@ -18,20 +18,39 @@ Use these procedures if the following issues occur:
 // Investigating why user-defined metrics are unavailable
 include::modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc[leveloffset=+1]
 
+// TODO: Add the additional resources for ROSA HCP when the Observability book is added.
+ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
-
+ifdef::openshift-rosa,openshift-dedicated[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#creating-user-defined-workload-monitoring-configmap_configuring-the-monitoring-stack[Creating a user-defined workload monitoring config map]
 * See xref:../../observability/monitoring/managing-metrics.adoc#specifying-how-a-service-is-monitored_managing-metrics[Specifying how a service is monitored] for details on how to create a service monitor or pod monitor
 * See xref:../../observability/monitoring/managing-metrics.adoc#getting-detailed-information-about-a-target_managing-metrics[Getting detailed information about a metrics target]
+endif::openshift-rosa,openshift-dedicated[]
+
+ifndef::openshift-rosa,openshift-dedicated[]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
+* See xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#specifying-how-a-service-is-monitored_configuring-metrics-uwm[Specifying how a service is monitored] for details on how to create a service monitor or pod monitor
+* See xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#getting-detailed-information-about-a-target_accessing-metrics-as-an-administrator[Getting detailed information about a metrics target]
+endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp[]
 
 // Determining why Prometheus is consuming a lot of disk space
 include::modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc[leveloffset=+1]
 
+// TODO: Add the additional resources for ROSA HCP when the Observability book is added.
+ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
-
+ifdef::openshift-rosa,openshift-dedicated[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_configuring-the-monitoring-stack[Setting scrape and evaluation intervals and enforced limits for user-defined projects]
+endif::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated[]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-performance-and-scalability-uwm.adoc#setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_configuring-performance-and-scalability-uwm[Setting scrape intervals, evaluation intervals, and enforced limits for user-defined projects]
+endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp[]
 
 // Resolving the KubePersistentVolumeFillingUp alert firing for Prometheus
-include::modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc[leveloffset=+1]
\ No newline at end of file
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+include::modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc[leveloffset=+1]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/support/troubleshooting/investigating-pod-issues.adoc b/support/troubleshooting/investigating-pod-issues.adoc
index 67860e98e0af..f768a51a788e 100644
--- a/support/troubleshooting/investigating-pod-issues.adoc
+++ b/support/troubleshooting/investigating-pod-issues.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 {product-title} leverages the Kubernetes concept of a pod, which is one or more containers deployed together on one host. A pod is the smallest compute unit that can be defined, deployed, and managed on {product-title} {product-version}.
 
-After a pod is defined, it is assigned to run on a node until its containers exit, or until it is removed. Depending on policy and exit code, Pods are either removed after exiting or retained so that their logs can be accessed.
+After a pod is defined, it is assigned to run on a node until its containers exit, or until it is removed. Depending on policy and exit code, pods are either removed after exiting or retained so that their logs can be accessed.
 
 The first thing to check when pod issues arise is the pod's status. If an explicit pod failure has occurred, observe the pod's error state to identify specific image, container, or pod network issues. Focus diagnostic data collection according to the error state. Review pod event messages, as well as pod and container log information. Diagnose issues dynamically by accessing running Pods on the command line, or start a debug pod with root access based on a problematic pod's deployment configuration.
 
diff --git a/support/troubleshooting/rosa-troubleshooting-iam-resources.adoc b/support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
index 8c8521c5a30a..1e8628911388 100644
--- a/support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
+++ b/support/troubleshooting/rosa-troubleshooting-iam-resources.adoc
@@ -8,6 +8,25 @@ toc::[]
 
 include::modules/rosa-sts-ocm-and-user-role-troubleshooting.adoc[leveloffset=+1]
 include::modules/rosa-sts-ocm-role-creation.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_ocm-role-creation_{context}"]
+.Additional resources
+* xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
+
 include::modules/rosa-sts-user-role-creation.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_user-role-creation_{context}"]
+.Additional resources
+* xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation]
+
 include::modules/rosa-sts-aws-requirements-creating-association.adoc[leveloffset=+2]
 include::modules/rosa-sts-aws-requirements-creating-multi-association.adoc[leveloffset=+2]
+
+// TODO: Add the additional resource to ROSA HCP when the Architecture book is added.
+ifndef::openshift-rosa-hcp[]
+[role="_additional-resources"]
+== Additional resources
+* See xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference] for a list of IAM roles needed for cluster creation.
+endif::openshift-rosa-hcp[]
diff --git a/support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc b/support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc
new file mode 100644
index 000000000000..ab58feead347
--- /dev/null
+++ b/support/troubleshooting/rosa-troubleshooting-installations-hcp.adoc
@@ -0,0 +1,42 @@
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/attributes-openshift-dedicated.adoc[]
+[id="rosa-troubleshooting-installations-hcp"]
+= Troubleshooting ROSA with HCP cluster installations
+:context: rosa-troubleshooting-installations-hcp
+//Remove this adoc from rosa-classic docs and add xrefs back in once HCP migration occurs.
+toc::[]
+
+For help with the installation of {hcp-title} clusters, refer to the following sections.
+
+include::modules/rosa-verify-hcp-install.adoc[leveloffset=+1]
+
+ifndef::openshift-rosa-hcp[]
+[role="_additional-resources"]
+.Additional resources
+* For information about the prerequisites to installing {hcp-title} clusters, see xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[AWS prerequisites for ROSA with STS].
+endif::openshift-rosa-hcp[]
+
+include::modules/rosa-hcp-no-console-access.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+ifndef::openshift-rosa-hcp[]
+* For more information about the {product-title} OAuth server, see xref:../../authentication/understanding-authentication.adoc#oauth-server-overview[ROSA OAuth server].
+* For more information about the {product-title} ingress operator, xref:../../networking/networking_operators/ingress-operator.adoc#configuring-ingress-controller[Configuring the Ingress Controller].
+endif::openshift-rosa-hcp[]
+* For more information about the web console, see xref:../../web_console/web-console-overview.adoc#web-console-overview[Web Console Overview].
+
+include::modules/rosa-hcp-ready-no-console-access.adoc[leveloffset=+1]
+
+ifndef::openshift-rosa-hcp[]
+[role="_additional-resources"]
+.Additional resources
+* For more information about the `rosa describe machinepool` command, see xref:../../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-list-objects[List and describe objects].
+endif::openshift-rosa-hcp[]
+
+include::modules/rosa-hcp-private-ready-no-console-access.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* For more information about connecting the cluster VPC to other networks, see https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html[AWS VPC Documentation].
+
diff --git a/support/troubleshooting/sd-managed-resources.adoc b/support/troubleshooting/sd-managed-resources.adoc
index e2dd475f3b5e..8fc90cfcde4c 100644
--- a/support/troubleshooting/sd-managed-resources.adoc
+++ b/support/troubleshooting/sd-managed-resources.adoc
@@ -9,7 +9,7 @@ toc::[]
 [id="sd-managed-resources-overview_{context}"]
 == Overview
 
-The following covers all {product-title} resources that are managed or protected by the Service Reliability Engineering Platform (SRE-P) Team.  Customers should not attempt to modify these resources because doing so can lead to cluster instability.
+The following covers all {product-title} resources that are managed or protected by the Service Reliability Engineering Platform (SRE-P) Team. Customers should not try to change these resources because doing so can lead to cluster instability.
 
 [id="sd-managed-resources-all_{context}"]
 == Hive managed resources
diff --git a/support/troubleshooting/troubleshooting-operator-issues.adoc b/support/troubleshooting/troubleshooting-operator-issues.adoc
index d96ec389f167..0e969a9127f7 100644
--- a/support/troubleshooting/troubleshooting-operator-issues.adoc
+++ b/support/troubleshooting/troubleshooting-operator-issues.adoc
@@ -18,10 +18,14 @@ If you experience Operator issues, verify Operator subscription status. Check Op
 
 // Operator subscription condition types
 include::modules/olm-status-conditions.adoc[leveloffset=+1]
+
+// TODO: Add this xref when the Operators book is added to ROSA HCP.
+ifndef::openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-cs-health_olm-understanding-olm[Catalog health requirements]
+endif::openshift-rosa-hcp[]
 
 // Viewing Operator subscription status by using the CLI
 include::modules/olm-status-viewing-cli.adoc[leveloffset=+1]
@@ -32,46 +36,45 @@ include::modules/olm-cs-status-cli.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+// TODO: Add this xref when the Operators book is added to ROSA HCP.
+ifndef::openshift-rosa-hcp[]
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource_olm-understanding-olm[Operator Lifecycle Manager concepts and resources -> Catalog source]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa-hcp[]
 * gRPC documentation: link:https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html[States of Connectivity]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 * xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Querying Operator Pod status
 include::modules/querying-operator-pod-status.adoc[leveloffset=+1]
 
 // Gathering Operator logs
+ifndef::openshift-rosa-hcp[]
 include::modules/gathering-operator-logs.adoc[leveloffset=+1]
+endif::openshift-rosa-hcp[]
 
 // cannot patch resource "machineconfigpools"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // Disabling Machine Config Operator from autorebooting
 include::modules/troubleshooting-disabling-autoreboot-mco.adoc[leveloffset=+1]
 include::modules/troubleshooting-disabling-autoreboot-mco-console.adoc[leveloffset=+2]
 include::modules/troubleshooting-disabling-autoreboot-mco-cli.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Refreshing failing subscriptions
 // cannot delete resource "clusterserviceversions", "jobs" in API group "operators.coreos.com" in the namespace "openshift-apiserver"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/olm-refresh-subs.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 // Reinstalling Operators after failed uninstallation
 // cannot delete resource "customresourcedefinitions"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 include::modules/olm-reinstall.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster]
 * xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding Operators to a cluster]
-endif::openshift-rosa,openshift-dedicated[]
-
-
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
diff --git a/support/troubleshooting/verifying-node-health.adoc b/support/troubleshooting/verifying-node-health.adoc
index ea0503438e17..83b1b818402a 100644
--- a/support/troubleshooting/verifying-node-health.adoc
+++ b/support/troubleshooting/verifying-node-health.adoc
@@ -10,12 +10,12 @@ toc::[]
 include::modules/reviewing-node-status-usage-and-configuration.adoc[leveloffset=+1]
 
 // cannot create resource "namespaces"
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 // Querying the kubelet's status on a node
 include::modules/querying-kubelet-status-on-a-node.adoc[leveloffset=+1]
 
 // cannot get resource "nodes/proxy"
 // Querying node journal logs
 include::modules/querying-cluster-node-journal-logs.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
diff --git a/updating/preparing_for_updates/updating-cluster-prepare.adoc b/updating/preparing_for_updates/updating-cluster-prepare.adoc
index 5b45c662ca43..5686afc36a52 100644
--- a/updating/preparing_for_updates/updating-cluster-prepare.adoc
+++ b/updating/preparing_for_updates/updating-cluster-prepare.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="updating-cluster-prepare"]
-= Preparing to update to {product-title} 4.17
+= Preparing to update to {product-title} 4.18
 include::_attributes/common-attributes.adoc[]
 :context: updating-cluster-prepare
 
@@ -14,20 +14,10 @@ To do: Remove this comment once 4.13 docs are EOL.
 
 Learn more about administrative tasks that cluster admins must perform to successfully initialize an update, as well as optional guidelines for ensuring a successful update.
 
-[id="rhel-micro-architecture-update-requirements"]
-== {op-system-base} 9.2 micro-architecture requirement change
-
-{product-title} is now based on the {op-system-base} 9.2 host operating system. The micro-architecture requirements are now increased to x86_64-v2, Power9, and Z14. See the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.0_release_notes/index#architectures[RHEL micro-architecture requirements documentation]. You can verify compatibility before updating by following the procedures outlined in this link:https://access.redhat.com/solutions/7052996[KCS article].
-
-[IMPORTANT]
-====
-Without the correct micro-architecture requirements, the update process will fail. Make sure you purchase the appropriate subscription for each architecture. For more information, see link:https://access.redhat.com/products/red-hat-enterprise-linux#addl-arch[Get Started with Red Hat Enterprise Linux - additional architectures]
-====
-
 [id="kube-api-removals_{context}"]
 == Kubernetes API removals
 
-There are no Kubernetes API removals in {product-title} 4.17.
+There are no Kubernetes API removals in {product-title} 4.18.
 
 // Commenting out this section because there are no APIs being removed in OCP 4.17 / Kube 1.30. But we'll need this section again for OCP 4.19 / Kube 1.32
 ////
diff --git a/updating/updating_a_cluster/control-plane-only-update.adoc b/updating/updating_a_cluster/control-plane-only-update.adoc
index faaae0735d5f..86b8671c3d41 100644
--- a/updating/updating_a_cluster/control-plane-only-update.adoc
+++ b/updating/updating_a_cluster/control-plane-only-update.adoc
@@ -14,7 +14,7 @@ To do: Remove this comment once 4.13 docs are EOL.
 
 Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized.
 You must update from {product-title} <4.y> to <4.y+1>, and then to <4.y+2>. You cannot update from {product-title} <4.y> to <4.y+2> directly.
-However, administrators who want to update between two even-numbered minor versions can do so incurring only a single reboot of non-control plane hosts. 
+However, administrators who want to update between two even-numbered minor versions can do so incurring only a single reboot of non-control plane hosts.
 
 [IMPORTANT]
 ====
@@ -64,3 +64,4 @@ include::modules/updating-control-plane-only-layered-products.adoc[leveloffset=+
 * xref:../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators]
 * xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#updating-control-plane-only-update-console_control-plane-only-update[Performing a Control Plane Only update using the web console]
 * xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#updating-control-plane-only-update-cli_control-plane-only-update[Performing a Control Plane Only update using the CLI]
+* xref:../../virt/updating/upgrading-virt.adoc#virt-preventing-workload-updates-during-control-plane-only-update_upgrading-virt[Preventing workload updates during a Control Plane Only update]
diff --git a/updating/updating_a_cluster/migrating-to-multi-payload.adoc b/updating/updating_a_cluster/migrating-to-multi-payload.adoc
index 981e55b3f8b9..e4095132e734 100644
--- a/updating/updating_a_cluster/migrating-to-multi-payload.adoc
+++ b/updating/updating_a_cluster/migrating-to-multi-payload.adoc
@@ -36,3 +36,16 @@ include::modules/migrating-to-multi-arch-cli.adoc[leveloffset=+1]
 * xref:../../updating/understanding_updates/understanding-update-channels-release.adoc#understanding-update-channels-releases[Understanding update channels and releases]
 * xref:../../installing/overview/installing-preparing.adoc#installing-preparing-selecting-cluster-type[Selecting a cluster installation type]
 * xref:../../machine_management/deploying-machine-health-checks.adoc#machine-health-checks-about_deploying-machine-health-checks[About machine health checks]
+* xref:../../updating/updating_a_cluster/updating-cluster-cli.adoc#update-upgrading-oc-adm-upgrade-status_updating-cluster-cli[Gathering cluster update status using oc adm upgrade status (Technology Preview)]
+
+//  Migrating the x86 control plane to the arm64 architecture on AWS
+include::modules/migrating-from-x86-to-arm-cp.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc#cpmso-config-options-aws[Control plane configuration options for {aws-full}]
+
+* xref:../../installing/installing_aws/upi/upi-aws-installation-reqs.adoc#installation-aws-arm-tested-machine-types_upi-aws-installation-reqs[Tested instance types for AWS on 64-bit ARM infrastructures]
+
+* xref:../../updating/updating_a_cluster/migrating-to-multi-payload.adoc#migrating-to-multi-arch-cli_updating-clusters-overview[Migrating to a cluster with multi-architecture compute machines using the CLI]
diff --git a/upgrading/osd-upgrades.adoc b/upgrading/osd-upgrades.adoc
index 46a2e34d9132..bc3e07500600 100644
--- a/upgrading/osd-upgrades.adoc
+++ b/upgrading/osd-upgrades.adoc
@@ -11,6 +11,12 @@ You can schedule automatic or manual upgrade policies to update the version of y
 
 Red Hat Site Reliability Engineers (SREs) monitor upgrade progress and remedy any issues encountered.
 
+include::modules/osd-lifecycle-policy.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* For more information about the {product-title} life cycle policy, see xref:../osd_architecture/osd_policy/osd-life-cycle.adoc#osd-life-cycle_life-cycle-overview[{product-title} update life cycle].
+
 include::modules/upgrade.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
@@ -18,5 +24,7 @@ include::modules/upgrade.adoc[leveloffset=+1]
 
 * For more information about the service log and adding cluster notification contacts, see xref:../osd_cluster_admin/osd-cluster-notifications.adoc#managed-cluster-notification-view-hcc_osd-cluster-notifications[Accessing cluster notifications in {hybrid-console}].
 
+* For more information on how to update a WIF configuration, see xref:../osd_gcp_clusters/creating-a-gcp-cluster-with-workload-identity-federation.adoc#wif-configuration-update_osd-creating-a-cluster-on-gcp-with-workload-identity-federation[Updating a WIF configuration].
+
 include::modules/upgrade-auto.adoc[leveloffset=+1]
 include::modules/upgrade-manual.adoc[leveloffset=+1]
diff --git a/upgrading/rosa-hcp-upgrading.adoc b/upgrading/rosa-hcp-upgrading.adoc
index 0d1a222b591e..603a5202ca7b 100644
--- a/upgrading/rosa-hcp-upgrading.adoc
+++ b/upgrading/rosa-hcp-upgrading.adoc
@@ -8,8 +8,13 @@ toc::[]
 
 include::modules/rosa-hcp-upgrade-options.adoc[leveloffset=+1]
 
-// .Additional resources
-// * ../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-edit-machinepool_rosa-managing-objects-cli[ROSA CLI reference: `rosa edit machinepool`]
+.Additional resources
+ifdef::openshift-rosa-hcp[]
+* link:https://docs.openshift.com/rosa/cli_reference/rosa_cli/rosa-manage-objects-cli.html#rosa-edit-machinepool_rosa-managing-objects-cli[ROSA CLI reference: `rosa edit machinepool`]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+* xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-edit-machinepool_rosa-managing-objects-cli[ROSA CLI reference: `rosa edit machinepool`]
+endif::openshift-rosa-hcp[]
 
 //This cannot be a module if we want to use the xrefs
 [id="rosa-lifecycle-policy_{context}"]
@@ -37,36 +42,3 @@ include::modules/rosa-hcp-upgrading-cli-control-plane.adoc[leveloffset=+1]
 
 include::modules/rosa-hcp-upgrading-cli-machinepool.adoc[leveloffset=+1]
 
-[id="rosa-hcp-upgrading-cli-cluster_{context}"]
-== Upgrading the whole cluster with the ROSA CLI
-
-Upgrading the entire cluster involves upgrading both the hosted control plane and nodes in the machine pools. However, these components cannot be upgraded at the same time. They must be upgraded in sequence. This can be done in any order. However, to maintain compatibility between nodes in the cluster, nodes in machine pools cannot use a newer version than the hosted control plane. Therefore, if both the hosted control plane and the nodes in your machine pools require upgrade to the same OpenShift version, you must upgrade the hosted control plane first, followed by the machine pools.
-
-[discrete]
-=== Prerequisites
-* You have installed and configured the latest version of the ROSA CLI.
-* No other upgrades are in progress or scheduled to take place at the same time as this upgrade.
-
-
-ifdef::context[:prevcontext: {context}]
-:context: rosa-hcp-upgrading-whole-cluster
-
-include::modules/rosa-hcp-upgrading-cli-control-plane.adoc[leveloffset=+2]
-
-ifdef::prevcontext[:context: {prevcontext}]
-ifdef::context[:prevcontext: {context}]
-
-:context: rosa-hcp-upgrading-whole-cluster
-
-include::modules/rosa-hcp-upgrading-cli-machinepool.adoc[leveloffset=+2]
-
-ifdef::prevcontext[:context: {prevcontext}]
-ifndef::prevcontext[:!context:]
-//LB: Remove until here if we don't want the "whole cluster" upgrade section
-
-include::modules/rosa-hcp-upgrading-cli-tutorial.adoc[leveloffset=+1]
-
-include::modules/rosa-upgrading-manual-ocm.adoc[leveloffset=+1]
-
-include::modules/rosa-deleting-cluster-upgrade-ocm.adoc[leveloffset=+1]
-
diff --git a/virt/about_virt/about-virt.adoc b/virt/about_virt/about-virt.adoc
index 759989d3b22f..061b8d8f1e32 100644
--- a/virt/about_virt/about-virt.adoc
+++ b/virt/about_virt/about-virt.adoc
@@ -13,40 +13,42 @@ include::modules/virt-what-you-can-do-with-virt.adoc[leveloffset=+1]
 // This line is attached to the above `virt-what-you-can-do-with-virt` module.
 // It is included here in the assembly because of the xref ban.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can use {VirtProductName} with xref:../../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[OVN-Kubernetes] or one of the other certified network plugins listed in link:https://access.redhat.com/articles/5436171[Certified OpenShift CNI Plug-ins].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can use {VirtProductName} with OVN-Kubernetes.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Hiding links in ROSA/OSD until PR 62384 merges
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can check your {VirtProductName} cluster for compliance issues by installing the xref:../../security/compliance_operator/co-concepts/compliance-operator-understanding.adoc#understanding-compliance[Compliance Operator] and running a scan with the `ocp4-moderate` and `ocp4-moderate-node` xref:../../security/compliance_operator/co-scans/compliance-operator-supported-profiles.adoc#compliance-operator-supported-profiles[profiles]. The Compliance Operator uses OpenSCAP, a link:https://www.nist.gov/[NIST-certified tool], to scan and enforce security policies.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can check your {VirtProductName} cluster for compliance issues by installing the Compliance Operator and running a scan with the `ocp4-moderate` and `ocp4-moderate-node` profiles. The Compliance Operator uses OpenSCAP, a link:https://www.nist.gov/[NIST-certified tool], to scan and enforce security policies.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-include::modules/virt-supported-cluster-version.adoc[leveloffset=+2]
+include::modules/virt-vmware-comparison.adoc[leveloffset=+1]
+
+include::modules/virt-supported-cluster-version.adoc[leveloffset=+1]
 
 include::modules/virt-about-storage-volumes-for-vm-disks.adoc[leveloffset=+1]
 
 // removing from OSD/ROSA, as SNO is not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-sno-differences.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [role="_additional-resources"]
 [id="additional-resources_about-virt"]
 == Additional resources
 
 * xref:../../storage/index.adoc#openshift-storage-common-terms_storage-overview[Glossary of common terms for {product-title} storage]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../installing/installing_sno/install-sno-preparing-to-install-sno.adoc#install-sno-about-installing-on-a-single-node_install-sno-preparing[About {sno}]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * link:https://cloud.redhat.com/blog/using-the-openshift-assisted-installer-service-to-deploy-an-openshift-cluster-on-metal-and-vsphere[Assisted installer]
 * xref:../../nodes/pods/nodes-pods-priority.adoc#priority-preemption-other_nodes-pods-priority[Pod disruption budgets]
 * xref:../../virt/live_migration/virt-about-live-migration.adoc#virt-about-live-migration[About live migration]
diff --git a/virt/backup_restore/virt-backup-restore-overview.adoc b/virt/backup_restore/virt-backup-restore-overview.adoc
index 0f4be61335b5..8e0f0c6496c7 100644
--- a/virt/backup_restore/virt-backup-restore-overview.adoc
+++ b/virt/backup_restore/virt-backup-restore-overview.adoc
@@ -16,13 +16,13 @@ Red Hat supports using {VirtProductName} 4.14 or later with {oadp-short} 1.3.x o
 {oadp-short} versions earlier than 1.3.0 are not supported for back up and restore of {VirtProductName}.
 ====
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 Back up and restore virtual machines by using the xref:../../backup_and_restore/index.adoc#application-backup-restore-operations-overview[{oadp-full}].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 Back up and restore virtual machines by using the {oadp-full}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 You can install the {oadp-first} with {VirtProductName} by installing the {oadp-short} Operator and configuring a backup location. You can then install the Data Protection Application.
 
@@ -41,20 +41,20 @@ The following storage options are excluded:
 
 * Volume snapshot backup and restore
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 For more information, see xref:../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-backing-up-applications-restic-doc.adoc#oadp-backing-up-applications-restic-doc[Backing up applications with File System Backup: Kopia or Restic].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 ====
 
 To install the {oadp-short} Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 See xref:../../disconnected/using-olm.adoc#olm-restricted-networks[Using Operator Lifecycle Manager in disconnected environments] for details.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/install-and-configure-oadp-kubevirt.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
@@ -62,7 +62,7 @@ ifndef::openshift-rosa,openshift-dedicated[]
 * xref:../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/backing-up-applications.adoc#backing-up-applications[`Backup` custom resource (CR)]
 * xref:../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/restoring-applications.adoc#restoring-applications[`Restore` CR]
 * xref:../../disconnected/using-olm.adoc#olm-restricted-networks[Using Operator Lifecycle Manager in disconnected environments]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/oadp-installing-dpa-1-3.adoc[leveloffset=+1]
 
diff --git a/virt/backup_restore/virt-backup-restore-snapshots.adoc b/virt/backup_restore/virt-backup-restore-snapshots.adoc
index 374bda40eece..f2c5c58780ec 100644
--- a/virt/backup_restore/virt-backup-restore-snapshots.adoc
+++ b/virt/backup_restore/virt-backup-restore-snapshots.adoc
@@ -9,24 +9,24 @@ toc::[]
 You can back up and restore virtual machines (VMs) by using snapshots. Snapshots are supported by the following storage providers:
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * {rh-storage-first}
 * Any other cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Any cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-Online snapshots have a default time deadline of five minutes (`5m`) that can be changed, if needed.
+To create snapshots of a VM in the `Running` state with the highest integrity, install the QEMU guest agent if it is not included with your operating system. The QEMU guest agent is included with the default Red{nbsp}Hat templates.
 
 [IMPORTANT]
 ====
 Online snapshots are supported for virtual machines that have hot plugged virtual disks. However, hot plugged disks that are not in the virtual machine specification are not included in the snapshot.
 ====
 
-To create snapshots of an online (Running state) VM with the highest integrity, install the QEMU guest agent if it is not included with your operating system. The QEMU guest agent is included with the default Red Hat templates.
+The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. 
 
-The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system as much as possible, depending on the system workload. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. The conditions under which the snapshot was taken are reflected in the snapshot indications that are displayed in the web console or CLI.
+The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again or use an offline snapshot
 
 include::modules/virt-about-vm-snapshots.adoc[leveloffset=+1]
 
@@ -62,9 +62,9 @@ include::modules/virt-deleting-vm-snapshot-web.adoc[leveloffset=+2]
 include::modules/virt-deleting-vm-snapshot-cli.adoc[leveloffset=+2]
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources-snapshots"]
 == Additional resources
 
 * xref:../../storage/container_storage_interface/persistent-storage-csi-snapshots.adoc#persistent-storage-csi-snapshots[CSI Volume Snapshots]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/backup_restore/virt-disaster-recovery.adoc b/virt/backup_restore/virt-disaster-recovery.adoc
index 9152f0befddf..bc0f26e536ba 100644
--- a/virt/backup_restore/virt-disaster-recovery.adoc
+++ b/virt/backup_restore/virt-disaster-recovery.adoc
@@ -23,6 +23,6 @@ include::modules/virt-regional-dr-odf.adoc[leveloffset=+2]
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources
-* link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index[Configuring {rh-storage} Disaster Recovery for OpenShift Workloads]
+* link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.18/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index[Configuring {rh-storage} Disaster Recovery for OpenShift Workloads]
 * link:https://access.redhat.com/articles/7053115[Use {rh-storage} Disaster Recovery to Protect Virtual Machines] in the Red{nbsp}Hat Knowledgebase
 * link:https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10[Red{nbsp}Hat Advanced Cluster Management for Kubernetes 2.10]
\ No newline at end of file
diff --git a/virt/creating_vm/virt-creating-vms-from-instance-types.adoc b/virt/creating_vm/virt-creating-vms-from-instance-types.adoc
index 3f60c74fb7a7..f4f5f9d94e7f 100644
--- a/virt/creating_vm/virt-creating-vms-from-instance-types.adoc
+++ b/virt/creating_vm/virt-creating-vms-from-instance-types.adoc
@@ -9,12 +9,12 @@ toc::[]
 You can simplify virtual machine (VM) creation by using instance types, whether you use the {product-title} web console or the CLI to create VMs.
 
 // special TP note for ROSA only:
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [NOTE]
 ====
 Creating a VM from an instance type in {VirtProductName} 4.15 and higher is supported on {product-title} clusters. In {VirtProductName} 4.14, creating a VM from an instance type is a Technology Preview feature and is not supported on {product-title} clusters.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-about-instance-types.adoc[leveloffset=+1]
 
@@ -33,3 +33,4 @@ include::modules/virt-inferfromvolume-labels.adoc[leveloffset=+2]
 
 include::modules/virt-creating-vm-instancetype.adoc[leveloffset=+1]
 
+include::modules/virt-change-vm-instance-type.adoc[leveloffset=+1]
diff --git a/virt/creating_vm/virt-creating-vms-from-templates.adoc b/virt/creating_vm/virt-creating-vms-from-templates.adoc
index 218a3fbc9114..a74df7e9c552 100644
--- a/virt/creating_vm/virt-creating-vms-from-templates.adoc
+++ b/virt/creating_vm/virt-creating-vms-from-templates.adoc
@@ -11,20 +11,20 @@ You can create virtual machines (VMs) from Red Hat templates by using the {produ
 [id="virt-about-templates"]
 == About VM templates
 
-Boot sources::
+You can use VM templates to help you easily create VMs.
+
+Expedite creation with boot sources::
 You can expedite VM creation by using templates that have an available boot source. Templates with a boot source are labeled *Available boot source* if they do not have a custom label.
 +
 Templates without a boot source are labeled *Boot source required*. See xref:../../virt/storage/virt-automatic-bootsource-updates.adoc#virt-automatic-bootsource-updates[Managing automatic boot source updates] for details.
 
-Customization::
+Customize before starting the VM::
 You can customize the disk source and VM parameters before you start the VM.
 
-See xref:../../virt/creating_vm/virt-creating-vms-from-templates.adoc#virt-vm-storage-volume-types_virt-creating-vms-from-templates[storage volume types] and xref:../../virt/creating_vm/virt-creating-vms-from-templates.adoc#virt-storage-wizard-fields-web_virt-creating-vms-from-templates[storage fields] for details about disk source settings.
-
-
++
 [NOTE]
 ====
-If you copy a VM template with all its labels and annotations, your version of the template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed. You can remove this designation. See xref:../../virt/creating_vm/virt-creating-vms-from-templates.adoc#virt-customizing-vm-template-web_virt-creating-vms-from-templates[Customizing a VM template by using the web console].
+If you copy a VM template with all its labels and annotations, your version of the template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed. You can remove this designation. See xref:../../virt/creating_vm/virt-creating-vms-from-templates.adoc#virt-customizing-vm-template-web_virt-creating-vms-from-templates[Removing a deprecated designation from a customized VM template by using the web console].
 ====
 
 {sno-caps}::
@@ -32,10 +32,6 @@ Due to differences in storage behavior, some templates are incompatible with {sn
 
 include::modules/virt-creating-vm-from-template.adoc[leveloffset=+1]
 
-include::modules/virt-vm-storage-volume-types.adoc[leveloffset=+2]
-
-include::modules/virt-storage-wizard-fields-web.adoc[leveloffset=+2]
-
 include::modules/virt-customizing-vm-template-web.adoc[leveloffset=+2]
 
 include::modules/virt-creating-template.adoc[leveloffset=+2]
diff --git a/virt/creating_vms_advanced/advanced-vm-creation-overview.adoc b/virt/creating_vms_advanced/advanced-vm-creation-overview.adoc
new file mode 100644
index 000000000000..c8d35387ba30
--- /dev/null
+++ b/virt/creating_vms_advanced/advanced-vm-creation-overview.adoc
@@ -0,0 +1,33 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="advanced-vm-creation-overview"]
+= Advanced virtual machine creation overview 
+include::_attributes/common-attributes.adoc[]
+:context: advanced-vm-creation-overview
+
+toc::[]
+
+Advanced virtual machine (VM) creation offers flexibility for cloud administrators, developers, security teams, and platform engineering teams to ensure consistency, optimize performance, enforce policies, and integrate with automated deployment pipelines. This helps to streamline provisioning and scalability, whether using the command-line interface (CLI) or web console.
+
+[id="adv-creating-vms-in-web-console"]
+== Creating VMs in the web console
+
+Use the following advanced methods for creating VMs in the web console:
+
+* xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-from-rh-images-overview.adoc#virt-creating-vms-from-rh-images-overview[Creating virtual machines from Red Hat images overview]
+
+* xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-from-web-images.adoc#virt-creating-vms-from-web-images[Creating VMs by importing images from web pages]
+
+* xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-uploading-images.adoc#virt-creating-vms-uploading-images[Creating VMs by uploading images]
+
+* xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-cloning-vms.adoc#virt-cloning-vms[Cloning VMs]
+
+[id="adv-creating-vms-using-cli"]
+== Creating VMs using the CLI
+
+Use the following advanced methods for creating VMs with the CLI:
+
+* xref:../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-cli.adoc#virt-creating-vms-from-cli[Creating VMs from the command line]
+
+* xref:../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-container-disks.adoc#virt-creating-vms-from-container-disks[Creating VMs by using container disks]
+
+* xref:../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-by-cloning-pvcs.adoc#virt-creating-vms-by-cloning-pvcs[Creating VMs by cloning PVCs]
\ No newline at end of file
diff --git a/virt/creating_vms_advanced/creating_vms_advanced_web/virt-cloning-vms.adoc b/virt/creating_vms_advanced/creating_vms_advanced_web/virt-cloning-vms.adoc
index 095458da75f7..6afd2f6f0c71 100644
--- a/virt/creating_vms_advanced/creating_vms_advanced_web/virt-cloning-vms.adoc
+++ b/virt/creating_vms_advanced/creating_vms_advanced_web/virt-cloning-vms.adoc
@@ -8,6 +8,11 @@ toc::[]
 
 You can clone virtual machines (VMs) or create new VMs from snapshots.
 
+[IMPORTANT]
+====
+Cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
+====
+
 include::modules/virt-cloning-vm-web.adoc[leveloffset=+1]
 
 include::modules/virt-creating-vm-from-snapshot-web.adoc[leveloffset=+1]
@@ -16,4 +21,4 @@ include::modules/virt-creating-vm-from-snapshot-web.adoc[leveloffset=+1]
 [id="additional-resources_{context}"]
 == Additional resources
 
-* xref:../../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-by-cloning-pvcs.adoc#virt-creating-vms-by-cloning-pvcs[Creating VMs by cloning PVCs]
\ No newline at end of file
+* xref:../../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-by-cloning-pvcs.adoc#virt-creating-vms-by-cloning-pvcs[Creating VMs by cloning PVCs]
diff --git a/virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-container-disks.adoc b/virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-container-disks.adoc
index 73b8b6a38a7d..4d3939916d79 100644
--- a/virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-container-disks.adoc
+++ b/virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-from-container-disks.adoc
@@ -11,7 +11,7 @@ You can create virtual machines (VMs) by using container disks built from operat
 You can enable auto updates for your container disks. See xref:../../../virt/storage/virt-automatic-bootsource-updates.adoc#virt-automatic-bootsource-updates[Managing automatic boot source updates] for details.
 
 // Hiding links in ROSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 If the container disks are large, the I/O traffic might increase and cause worker nodes to be unavailable. You can perform the following tasks to resolve this issue:
@@ -19,13 +19,13 @@ If the container disks are large, the I/O traffic might increase and cause worke
 * xref:../../../applications/pruning-objects.adoc#pruning-deployments_pruning-objects[Pruning `DeploymentConfig` objects].
 * xref:../../../nodes/nodes/nodes-nodes-garbage-collection.adoc#nodes-nodes-garbage-collection-configuring_nodes-nodes-configuring[Configuring garbage collection].
 ====
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 If the container disks are large, the I/O traffic might increase and cause worker nodes to be unavailable. You can prune `DeploymentConfig` objects to resolve this issue:
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 You create a VM from a container disk by performing the following steps:
 
diff --git a/virt/getting_started/virt-getting-started.adoc b/virt/getting_started/virt-getting-started.adoc
index 27acf7641ca6..9375640d9805 100644
--- a/virt/getting_started/virt-getting-started.adoc
+++ b/virt/getting_started/virt-getting-started.adoc
@@ -14,7 +14,7 @@ Cluster configuration procedures require `cluster-admin` privileges.
 ====
 
 // Hiding in ROSA/OSD for now - unsure if supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [id="tours-quick-starts_{context}"]
 == Tours and quick starts
 
@@ -38,8 +38,8 @@ Quick start tours are available for several {VirtProductName} features. To acces
 . Click the *Help* icon *?* in the menu bar on the header of the {product-title} web console.
 . Select *Quick Starts*.
 
-You can filter the available tours by entering the keyword `virtualization` in the *Filter* field.
-endif::openshift-rosa,openshift-dedicated[]
+You can filter the available tours by entering the keyword `virtual` in the *Filter* field.
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="planning-and-installing-virt_{context}"]
 == Planning and installing {VirtProductName}
@@ -47,9 +47,9 @@ endif::openshift-rosa,openshift-dedicated[]
 Plan and install {VirtProductName} on an {product-title} cluster:
 
 // Hiding in ROSA/OSD, not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../installing/installing_bare_metal/preparing-to-install-on-bare-metal.adoc#virt-planning-bare-metal-cluster-for-ocp-virt_preparing-to-install-on-bare-metal[Plan your bare metal cluster for {VirtProductName}].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/install/preparing-cluster-for-virt.adoc#preparing-cluster-for-virt[Prepare your cluster for {VirtProductName}].
 * xref:../../virt/install/installing-virt.adoc#virt-installing-virt-operator_installing-virt[Install the {VirtProductName} Operator].
 * xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#installing-virtctl_virt-using-the-cli-tools[Install the `virtctl` command line interface (CLI) tool].
@@ -64,9 +64,9 @@ endif::openshift-rosa,openshift-dedicated[]
 * xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-csi[Using a CSI-enabled storage provider].
 * xref:../../virt/storage/virt-configuring-local-storage-with-hpp.adoc#virt-configuring-local-storage-with-hpp[Configuring local storage for virtual machines].
 // Hiding in ROSA/OSD, as feature is TP
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#installing-the-kubernetes-nmstate-operator-cli[Installing the Kubernetes NMState Operator].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc#virt-specifying-nodes-for-vms[Specifying nodes for virtual machines].
 * xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#virt-virtctl-commands_virt-using-the-cli-tools[`Virtctl` commands].
 
@@ -76,21 +76,21 @@ endif::openshift-rosa,openshift-dedicated[]
 Create a virtual machine (VM):
 
 * xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-from-rh-images-overview.adoc#virt-creating-vms-from-rh-images-overview[Create a VM from a Red Hat image].
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 You can create a VM by using a Red Hat template or an xref:../../virt/creating_vm/virt-creating-vms-from-instance-types.adoc#virt-creating-vms-from-instance-types[instance type].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 You can create a VM by using a Red Hat template.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 * You can create a VM by xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-from-web-images.adoc#virt-creating-vms-from-web-images[importing a custom image from a container registry or a web page], by xref:../../virt/creating_vms_advanced/creating_vms_advanced_web/virt-creating-vms-uploading-images.adoc#virt-creating-vms-uploading-images[uploading an image from your local machine], or by xref:../../virt/creating_vms_advanced/creating_vms_cli/virt-creating-vms-by-cloning-pvcs.adoc#virt-creating-vms-by-cloning-pvcs[cloning a persistent volume claim (PVC)].
 
 Connect a VM to a secondary network:
 
 // Linux bridge and SR-IOV not supported in ROSA/OSD
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Linux bridge network].
 * xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Open Virtual Network (OVN)-Kubernetes secondary network].
 * xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[Single Root I/O Virtualization (SR-IOV) network].
@@ -99,15 +99,15 @@ ifndef::openshift-rosa,openshift-dedicated[]
 ====
 VMs are connected to the pod network by default.
 ====
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Open Virtual Network (OVN)-Kubernetes secondary network].
 +
 [NOTE]
 ====
 VMs are connected to the pod network by default.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 Connect to a VM:
 
@@ -121,6 +121,8 @@ Manage a VM:
 * xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#virt-virtctl-commands_virt-using-the-cli-tools[Manage a VM by using the `virtctl` CLI tool].
 * xref:../../virt/managing_vms/virt-exporting-vms.adoc#virt-accessing-exported-vm-manifests_virt-exporting-vms[Export a VM].
 
+include::modules/migrating-to-virt.adoc[leveloffset=+1]
+
 [id="next-steps_{context}"]
 == Next steps
 
@@ -128,7 +130,7 @@ Manage a VM:
 * xref:../../virt/storage/virt-storage-config-overview.adoc#virt-storage-config-overview[Configure storage options and automatic boot source updates].
 * xref:../../virt/monitoring/virt-monitoring-overview.adoc#virt-monitoring-overview[Learn about monitoring and health checks].
 * xref:../../virt/live_migration/virt-about-live-migration.adoc#virt-about-live-migration[Learn about live migration].
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../backup_and_restore/application_backup_and_restore/installing/installing-oadp-kubevirt.adoc#installing-oadp-kubevirt[Back up and restore VMs by using the {oadp-first}].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * link:https://access.redhat.com/articles/6994974[Tune and scale your cluster].
diff --git a/virt/install/installing-virt.adoc b/virt/install/installing-virt.adoc
index 179c1b61667e..6b751dd8669e 100644
--- a/virt/install/installing-virt.adoc
+++ b/virt/install/installing-virt.adoc
@@ -8,14 +8,14 @@ toc::[]
 
 Install {VirtProductName} to add virtualization functionality to your {product-title} cluster.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 If you install {VirtProductName} in a restricted environment with no internet connectivity, you must xref:../../disconnected/using-olm.adoc#olm-restricted-networks[configure Operator Lifecycle Manager for disconnected environments].
 
 If you have limited internet connectivity, you can xref:../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[configure proxy support in OLM] to access the OperatorHub.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="installing-virt-operator_installing-virt"]
 == Installing the {VirtProductName} Operator
@@ -24,12 +24,12 @@ Install the {VirtProductName} Operator by using the {product-title} web console
 
 include::modules/virt-installing-virt-operator.adoc[leveloffset=+2]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../rosa_cluster_admin/rosa_nodes/rosa-managing-worker-nodes.html#creating_a_machine_pool_rosa-managing-worker-nodes[Creating a machine pool]
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-dedicated[]
 [role="_additional-resources"]
@@ -52,12 +52,12 @@ You can xref:../../virt/post_installation_configuration/virt-configuring-certifi
 
 include::modules/virt-deploying-operator-cli.adoc[leveloffset=+3]
 
-ifdef::openshift-rosa[]
+ifdef::openshift-rosa,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../rosa_cluster_admin/rosa_nodes/rosa-managing-worker-nodes.html#creating_a_machine_pool_rosa-managing-worker-nodes[Creating a machine pool]
-endif::openshift-rosa[]
+endif::openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-dedicated[]
 [role="_additional-resources"]
diff --git a/virt/install/preparing-cluster-for-virt.adoc b/virt/install/preparing-cluster-for-virt.adoc
index 23dbd103cd44..bb5c86f17850 100644
--- a/virt/install/preparing-cluster-for-virt.adoc
+++ b/virt/install/preparing-cluster-for-virt.adoc
@@ -10,7 +10,7 @@ toc::[]
 Review this section before you install {VirtProductName} to ensure that your cluster meets the requirements.
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 Installation method considerations::
@@ -22,14 +22,14 @@ If you deploy {VirtProductName} with {rh-storage-first}, you must create a dedic
 IPv6::
 You cannot run {VirtProductName} on a single-stack IPv6 cluster.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Hiding in ROSA/OSD as FIPS not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 .FIPS mode
 
 If you install your cluster in xref:../../installing/overview/installing-fips.adoc#installing-fips-mode_installing-fips[FIPS mode], no additional setup is required for {VirtProductName}.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="supported-platforms_preparing-cluster-for-virt"]
 == Supported platforms
@@ -37,7 +37,7 @@ endif::openshift-rosa,openshift-dedicated[]
 You can use the following platforms with {VirtProductName}:
 
 // Hiding in ROSA/OSD, as bare metal not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * On-premise bare metal servers. See xref:../../installing/installing_bare_metal/preparing-to-install-on-bare-metal.adoc#virt-planning-bare-metal-cluster-for-ocp-virt_preparing-to-install-on-bare-metal[Planning a bare metal cluster for {VirtProductName}].
 
 * Amazon Web Services bare metal instances. See xref:../../installing/installing_aws/ipi/installing-aws-customizations.adoc#installing-aws-customizations[Installing a cluster on AWS with customizations].
@@ -52,16 +52,26 @@ include::snippets/technology-preview.adoc[]
 :!FeatureName:
 endif::[]
 --
-endif::openshift-rosa,openshift-dedicated[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+* {ibm-z-name} or {ibm-linuxone-name} (s390x architecture) systems where an {product-title} cluster is installed in a logical partition (LPAR). See xref:../../installing/installing_ibm_z/preparing-to-install-on-ibm-z.adoc#preparing-to-install-on-ibm-z_preparing-to-install-on-ibm-z[Preparing to install on {ibm-z-title} and {ibm-linuxone-title}].
++
+--
+ifdef::openshift-enterprise[]
+:FeatureName: Using {VirtProductName} in a cluster deployed on s390x architecture
+include::snippets/technology-preview.adoc[]
+:!FeatureName:
+endif::[]
+--
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Amazon Web Services bare metal instances.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Hiding in ROSA/OSD, as bare metal not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 Bare metal instances or servers offered by other cloud providers are not supported.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-aws-bm.adoc[leveloffset=+2]
 
@@ -70,6 +80,61 @@ include::modules/virt-aws-bm.adoc[leveloffset=+2]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Connecting a virtual machine to an OVN-Kubernetes secondary network]
 * xref:../../virt/vm_networking/virt-exposing-vm-with-service.adoc#virt-exposing-vm-with-service[Exposing a virtual machine by using a service]
 
+// Hiding in ROSA/OSD - todo: double check this
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+[id="ibm-z-linuxone-compatibility_{context}"]
+=== {ibm-z-title} and {ibm-linuxone-title} compatibility
+
+You can use {VirtProductName} in an {product-title} cluster that is installed in a logical partition (LPAR) on an {ibm-z-name} or {ibm-linuxone-name} (s390x architecture) system.
+
+ifdef::openshift-enterprise[]
+:FeatureName: Using {VirtProductName} in a cluster deployed on s390x architecture
+include::snippets/technology-preview.adoc[]
+:!FeatureName:
+endif::[]
+
+Some features are not currently available on s390x architecture, while others require workarounds or procedural changes. These lists are subject to change.
+
+[discrete]
+[id="currently-unavailable-ibm-z_{context}"]
+==== Currently unavailable features
+
+The following features are not available or do not function on s390x architecture:
+
+* Memory hot plugging and hot unplugging
+* Watchdog devices
+* Node Health Check Operator
+* SR-IOV Operator
+* virtual Trusted Platform Module (vTPM) devices
+* {pipelines-title} tasks
+* UEFI mode for VMs
+* PCI passthrough
+* USB host passthrough
+* Configuring virtual GPUs
+* {VirtProductName} cluster checkup framework
+* Creating and managing Windows VMs
+
+[discrete]
+[id="functionality-differences_{context}"]
+==== Functionality differences
+
+The following features are available for use on s390x architecture but function differently or require procedural changes:
+
+* When xref:../../virt/managing_vms/virt-delete-vms.adoc#virt-delete-vm-web_virt-delete-vms[deleting a virtual machine by using the web console], the *grace period* option is ignored.
+
+* When xref:../../virt/managing_vms/advanced_vm_management/virt-configuring-default-cpu-model.adoc#virt-configuring-default-cpu-model_virt-configuring-default-cpu-model[configuring the default CPU model], the `spec.defaultCPUModel` value is `"gen15b"` for an {ibm-z-title} cluster.
+
+* When xref:../../virt/vm_networking/virt-hot-plugging-network-interfaces.adoc#virt-hot-unplugging-bridge-network-interface_virt-hot-plugging-network-interfaces[hot unplugging a secondary network interface], the `virtctl migrate <vm_name>` command does not migrate the VM. As a workaround, restart the VM by running the following command:
++
+[source,terminal]
+----
+$ virtctl restart <vm_name>
+----
+
+* When xref:../../virt/monitoring/virt-exposing-downward-metrics.adoc#virt-configuring-downward-metrics_virt-using-downward-metrics_virt-exposing-downward-metrics[configuring a downward metrics device], if you use a VM preference, the `spec.preference.name` value must be set to `rhel.9.s390x` or another available preference with the format `*.s390x`.
+
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
 // Section is in assembly so that we can use xrefs
 [id="virt-hardware-os-requirements_preparing-cluster-for-virt"]
 == Hardware and operating system requirements
@@ -99,7 +164,7 @@ See xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-schedul
 === Operating system requirements
 
 * {op-system-first} installed on worker nodes.
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 See xref:../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhcos[About RHCOS] for details.
 +
@@ -107,26 +172,26 @@ See xref:../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhc
 ====
 {op-system-base} worker nodes are not supported.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="storage-requirements_preparing-cluster-for-virt"]
 === Storage requirements
 
 // Hiding link until PR 65079 merges
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Supported by {product-title}. See xref:../../scalability_and_performance/optimization/optimizing-storage.adoc#_optimizing-storage[Optimizing storage].
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * Supported by {product-title}.
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * You must create a default {VirtProductName} or {product-title} storage class. The purpose of this is to address the unique storage needs of VM workloads and offer optimized performance, reliability, and user experience. If both {VirtProductName} and {product-title} default storage classes exist, the {VirtProductName} class takes precedence when creating VM disks.
 
 [NOTE]
 ====
 To mark a storage class as the default for virtualization workloads, set the annotation `storageclass.kubevirt.io/is-default-virt-class` to `"true"`.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 * If the storage provisioner supports snapshots, you must associate a `VolumeSnapshotClass` object with the default storage class.
 
@@ -155,16 +220,16 @@ The default xref:../../virt/live_migration/virt-configuring-live-migration.adoc#
 include::modules/virt-cluster-resource-requirements.adoc[leveloffset=+1]
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-sno-differences.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../storage/index.adoc#openshift-storage-common-terms_storage-overview[Glossary of common terms for {product-title} storage]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [id="object-maximums_preparing-cluster-for-virt"]
 == Object maximums
 
@@ -194,4 +259,4 @@ In {product-title} clusters installed using installer-provisioned infrastructure
 ====
 Without an external monitoring system or a qualified human monitoring node health, virtual machines lose high availability.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/live_migration/virt-about-live-migration.adoc b/virt/live_migration/virt-about-live-migration.adoc
index b93767ba10e7..57ee19c35499 100644
--- a/virt/live_migration/virt-about-live-migration.adoc
+++ b/virt/live_migration/virt-about-live-migration.adoc
@@ -42,7 +42,7 @@ You can perform the following live migration tasks:
 * xref:../../virt/live_migration/virt-configuring-live-migration.adoc#virt-configuring-live-migration[Configure live migration settings]
 * xref:../../virt/live_migration/virt-configuring-live-migration.adoc#virt-configuring-live-migration-heavy_virt-configuring-live-migration[Configure live migration for heavy workloads]
 * xref:../../virt/live_migration/virt-initiating-live-migration.adoc#virt-initiating-live-migration[Initiate and cancel live migration]
-* Monitor the progress of all live migrations in the *Migration* tab of the {virtproductname} web console.
+* Monitor the progress of all live migrations in the *Migration* tab of the {product-title} web console.
 * View VM migration metrics in the *Metrics* tab of the web console.
 
 
diff --git a/virt/live_migration/virt-configuring-live-migration.adoc b/virt/live_migration/virt-configuring-live-migration.adoc
index 49674206851a..2637a93e73af 100644
--- a/virt/live_migration/virt-configuring-live-migration.adoc
+++ b/virt/live_migration/virt-configuring-live-migration.adoc
@@ -26,7 +26,7 @@ You can create live migration policies to apply different migration configuratio
 
 [TIP]
 ====
-You can create live migration policies by using the {VirtProductName} web console.
+You can create live migration policies by using the {product-title} web console.
 ====
 
 include::modules/virt-configuring-a-live-migration-policy.adoc[leveloffset=+2]
diff --git a/virt/managing_vms/advanced_vm_management/virt-configuring-cluster-realtime-workloads.adoc b/virt/managing_vms/advanced_vm_management/virt-configuring-cluster-realtime-workloads.adoc
index 8b39cbb2997d..578bcdcd23fd 100644
--- a/virt/managing_vms/advanced_vm_management/virt-configuring-cluster-realtime-workloads.adoc
+++ b/virt/managing_vms/advanced_vm_management/virt-configuring-cluster-realtime-workloads.adoc
@@ -17,5 +17,5 @@ include::modules/virt-configuring-vm-real-time.adoc[leveloffset=+1]
 == Additional resources
 
 * xref:../../../../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator]
-* xref:../../../../scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc#cnf-provisioning-low-latency-workloads[Provisioning real-time and low latency workloads]
-* xref:../../../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-reducing-nic-queues-with-nto[Reducing NIC queues using the Node Tuning Operator]
+* xref:../../../../scalability_and_performance/cnf-provisioning-low-latency-workloads.adoc#cnf-provisioning-low-latency-workloads[Provisioning real-time and low latency workloads]
+* xref:../../../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-reducing-nic-queues-with-nto[Reducing NIC queues using the Node Tuning Operator]
diff --git a/virt/managing_vms/advanced_vm_management/virt-configuring-pxe-booting.adoc b/virt/managing_vms/advanced_vm_management/virt-configuring-pxe-booting.adoc
index 34bc967a97bb..c58563357f01 100644
--- a/virt/managing_vms/advanced_vm_management/virt-configuring-pxe-booting.adoc
+++ b/virt/managing_vms/advanced_vm_management/virt-configuring-pxe-booting.adoc
@@ -12,13 +12,13 @@ operating system or other program without requiring a locally attached
 storage device. For example, you can use it to choose your desired OS
 image from a PXE server when deploying a new host.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 == Prerequisites
 
 * A Linux bridge must be xref:../../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[connected].
 
 * The PXE server must be connected to the same VLAN as the bridge.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-pxe-booting-with-mac-address.adoc[leveloffset=+1]
 
diff --git a/virt/managing_vms/advanced_vm_management/virt-high-availability-for-vms.adoc b/virt/managing_vms/advanced_vm_management/virt-high-availability-for-vms.adoc
index 56654d1780e4..e12065df15fb 100644
--- a/virt/managing_vms/advanced_vm_management/virt-high-availability-for-vms.adoc
+++ b/virt/managing_vms/advanced_vm_management/virt-high-availability-for-vms.adoc
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 // Hiding manual delete item as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can enable high availability for virtual machines (VMs) by manually deleting a failed node to trigger VM failover or by configuring remediating nodes.
 
 .Manually deleting a failed node
@@ -17,10 +17,10 @@ If a node fails and machine health checks are not deployed on your cluster, virt
 See xref:../../../virt/nodes/virt-triggering-vm-failover-resolving-failed-node.adoc#virt-triggering-vm-failover-resolving-failed-node[Deleting a failed node to trigger virtual machine failover].
 
 .Configuring remediating nodes
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can enable high availability for virtual machines (VMs) by configuring remediating nodes.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 You can configure remediating nodes by installing the Self Node Remediation Operator or the Fence Agents Remediation Operator from the OperatorHub and enabling machine health checks or node remediation checks.
 
diff --git a/virt/managing_vms/advanced_vm_management/virt-managing-virtual-machines-by-using-openshift-gitops.adoc b/virt/managing_vms/advanced_vm_management/virt-managing-virtual-machines-by-using-openshift-gitops.adoc
new file mode 100644
index 000000000000..b2b347fb9237
--- /dev/null
+++ b/virt/managing_vms/advanced_vm_management/virt-managing-virtual-machines-by-using-openshift-gitops.adoc
@@ -0,0 +1,38 @@
+// Module included in the following assemblies:
+//
+// * virt/virtual_machines/advanced_vm_management
+
+:_newdoc-version: 2.18.3
+:_template-generated: 2025-01-24
+:_mod-docs-content-type: PROCEDURE
+
+[id="virt-managing-virtual-machines-by-using-openshift-gitops_{context}"]
+= Managing virtual machines by using OpenShift GitOps
+
+To automate and optimize virtual machine (VM) management in OpenShift Virtualization, you can use OpenShift GitOps.
+
+With GitOps, you can set up VM deployments based on configuration files stored in a Git repository. This also makes it easier to automate, update, or replicate these configurations, as well to use version control for tracking their changes.
+
+.Prerequisites
+
+* You have a GitHub account. For instructions to set up an account, see link:https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github[Creating an account on GitHub].
+
+* OpenShift Virtualuzation has been installed on your OpenShift cluster. For instructions, see xref:../../../virt/install/installing-virt.adoc#installing-virt[OpenShift Virtualization installation].
+
+* The OpenShift GitOps operator has been installed on your OpenShift cluster. For instructions, see link:https://docs.openshift.com/gitops/1.15/installing_gitops/preparing-gitops-install.html[Installing GitOps].
+
+.Procedure
+
+Follow link:https://developers.redhat.com/learning/learn:manage-openshift-virtual-machines-gitops/resource/resources:connect-and-configure-external-repository-argo-cd-virtual-machines[the _Manage OpenShift virtual machines with GitOps_ learning path] in performing these steps:
+
+. Connect an external Git repository to your Argo CD instance.
+
+. Create the required VM configuration in the Git repository.
+
+. Use the VM configuration to create VMs on your cluster.
+
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.openshift.com/gitops/[OpenShift GitOps documentation]
+
diff --git a/virt/managing_vms/advanced_vm_management/virt-schedule-vms.adoc b/virt/managing_vms/advanced_vm_management/virt-schedule-vms.adoc
index 1cccf23b77b7..54c48074ce31 100644
--- a/virt/managing_vms/advanced_vm_management/virt-schedule-vms.adoc
+++ b/virt/managing_vms/advanced_vm_management/virt-schedule-vms.adoc
@@ -19,8 +19,8 @@ include::modules/virt-schedule-cpu-host-model-vms.adoc[leveloffset=+1]
 include::modules/virt-vm-custom-scheduler.adoc[leveloffset=+1]
 
 // Hiding in ROSA/OSD, not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../../nodes/scheduling/secondary_scheduler/nodes-secondary-scheduler-configuring.adoc#nodes-secondary-scheduler-configuring-console_secondary-scheduler-configuring[Deploying a secondary scheduler]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc b/virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc
index 114680dab98a..6e612c87f468 100644
--- a/virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc
+++ b/virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc
@@ -27,6 +27,6 @@ include::modules/virt-example-vm-node-placement-tolerations.adoc[leveloffset=+2]
 * xref:../../../virt/post_installation_configuration/virt-node-placement-virt-components.adoc#virt-node-placement-virt-components[Specifying nodes for virtualization components]
 * xref:../../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
 * xref:../../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity[Controlling pod placement on nodes using node affinity rules]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/virt/managing_vms/virt-accessing-vm-consoles.adoc b/virt/managing_vms/virt-accessing-vm-consoles.adoc
index 4172d9d33dd9..98f6abd34cca 100644
--- a/virt/managing_vms/virt-accessing-vm-consoles.adoc
+++ b/virt/managing_vms/virt-accessing-vm-consoles.adoc
@@ -21,15 +21,14 @@ You can connect to the VNC console of a virtual machine by using the {product-ti
 :context: vnc-console
 include::modules/virt-connecting-to-vm-console-web.adoc[leveloffset=+2]
 include::modules/virt-connecting-vm-virtctl.adoc[leveloffset=+2]
-:!vnc-console:
-
-:context: vnc-console
 include::modules/virt-temporary-token-VNC.adoc[leveloffset=+2]
-:!vnc-console:
 
-:context: vnc-console
+[role="_additional-resources"]
+.Additional resources
+* xref:../../virt/about_virt/virt-architecture.adoc#virt-about-ssp-operator_virt-architecture[About the Scheduling, Scale, and Performance (SSP) Operator]
+
 include::modules/virt-cluster-role-VNC.adoc[leveloffset=+3]
-:!vnc-console:
+:context: virt-accessing-vm-consoles
 
 [id="serial-console_virt-accessing-vm-consoles"]
 == Connecting to the serial console
@@ -44,7 +43,7 @@ Running concurrent VNC connections to a single virtual machine is not currently
 :context: serial-console
 include::modules/virt-connecting-to-vm-console-web.adoc[leveloffset=+2]
 include::modules/virt-connecting-vm-virtctl.adoc[leveloffset=+2]
-:!serial-console:
+:context: virt-accessing-vm-consoles
 
 [id="desktop-viewer_virt-accessing-vm-consoles"]
 == Connecting to the desktop viewer
@@ -53,4 +52,4 @@ You can connect to a Windows virtual machine (VM) by using the desktop viewer an
 
 :context: desktop-viewer
 include::modules/virt-connecting-to-vm-console-web.adoc[leveloffset=+2]
-:!desktop-viewer:
+:context: virt-accessing-vm-consoles
\ No newline at end of file
diff --git a/virt/managing_vms/virt-accessing-vm-ssh.adoc b/virt/managing_vms/virt-accessing-vm-ssh.adoc
index 21f1b620949e..65d3f4ab73ee 100644
--- a/virt/managing_vms/virt-accessing-vm-ssh.adoc
+++ b/virt/managing_vms/virt-accessing-vm-ssh.adoc
@@ -139,22 +139,22 @@ See the link:https://access.redhat.com/articles/6994974#networking-multus[Multus
 
 .Prerequisites
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * You configured a secondary network such as xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Linux bridge] or xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[SR-IOV].
 * You created a network attachment definition for a xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-creating-linux-bridge-nad-web_virt-connecting-vm-to-linux-bridge[Linux bridge network] or the SR-IOV Network Operator created a xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-network-attachment_virt-connecting-vm-to-sriov[network attachment definition] when you created an `SriovNetwork` object.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * You configured a xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[secondary network].
 * You created a xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#creating-ovn-nad_virt-connecting-vm-to-ovn-secondary-network[network attachment definition].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-vm-creating-nic-web.adoc[leveloffset=+2]
 
 include::modules/virt-connecting-secondary-network-ssh.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [NOTE]
 ====
 You can also xref:../../virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc#virt-accessing-vm-secondary-network-fqdn[access a VM attached to a secondary network interface by using the cluster FQDN].
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/managing_vms/virt-controlling-vm-states.adoc b/virt/managing_vms/virt-controlling-vm-states.adoc
index efe8d51d9f82..029c2831a76f 100644
--- a/virt/managing_vms/virt-controlling-vm-states.adoc
+++ b/virt/managing_vms/virt-controlling-vm-states.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can stop, start, restart, and unpause virtual machines from the web console.
+You can stop, start, restart, pause, and unpause virtual machines from the web console.
 
 You can use xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#virt-using-the-cli-tools[`virtctl`] to manage virtual machine states and perform other actions from the CLI. For example, you can use `virtctl` to force stop a VM or expose a port.
 
@@ -19,3 +19,5 @@ include::modules/virt-restarting-vm-web.adoc[leveloffset=+1]
 include::modules/virt-pausing-vm-web.adoc[leveloffset=+1]
 
 include::modules/virt-unpausing-vm-web.adoc[leveloffset=+1]
+
+include::modules/virt-controlling-multiple-vms.adoc[leveloffset=+1]
diff --git a/virt/managing_vms/virt-edit-vms.adoc b/virt/managing_vms/virt-edit-vms.adoc
index c9bb066d74f0..eea989b6d061 100644
--- a/virt/managing_vms/virt-edit-vms.adoc
+++ b/virt/managing_vms/virt-edit-vms.adoc
@@ -10,18 +10,24 @@ You can update a virtual machine (VM) configuration by using the {product-title}
 
 You can also edit a VM by using the command line.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 To edit a VM to configure disk sharing by using virtual disks or LUN, see xref:../../virt/managing_vms/virtual_disks/virt-configuring-shared-volumes-for-vms.adoc#virt-configuring-shared-volumes-for-vms[Configuring shared volumes for virtual machines].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+include::modules/virt-change-vm-instance-type.adoc[leveloffset=+1]
 
 include::modules/virt-hot-plugging-memory.adoc[leveloffset=+1]
+
 include::modules/virt-hot-plugging-cpu.adoc[leveloffset=+1]
+
 include::modules/virt-editing-vm-cli.adoc[leveloffset=+1]
 
 include::modules/virt-add-disk-to-vm.adoc[leveloffset=+1]
 
 include::modules/virt-storage-wizard-fields-web.adoc[leveloffset=+2]
+
 include::modules/virt-mounting-windows-driver-disk-on-vm.adoc[leveloffset=+1]
+
 include::modules/virt-adding-secret-configmap-service-account-to-vm.adoc[leveloffset=+1]
 
 [discrete]
diff --git a/virt/managing_vms/virt-using-vtpm-devices.adoc b/virt/managing_vms/virt-using-vtpm-devices.adoc
index b2692c0ddfba..ff6903043ee6 100644
--- a/virt/managing_vms/virt-using-vtpm-devices.adoc
+++ b/virt/managing_vms/virt-using-vtpm-devices.adoc
@@ -10,5 +10,11 @@ Add a virtual Trusted Platform Module (vTPM) device to a new or existing virtual
 machine by editing the `VirtualMachine` (VM) or `VirtualMachineInstance` (VMI)
 manifest.
 
+[IMPORTANT]
+====
+With {VirtProductName} 4.18 and newer, you can xref:../../virt/managing_vms/virt-exporting-vms.adoc#virt-exporting-vms[export virtual machines] (VMs) with attached vTPM devices, xref:../../virt/backup_restore/virt-backup-restore-snapshots.adoc#creating-snapshots_virt-backup-restore-snapshots[create snapshots of these VMs], and xref:../../virt/backup_restore/virt-backup-restore-snapshots.adoc#restoring-vms-from-snapshots_virt-backup-restore-snapshots[restore VMs from these snapshots]. However, cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
+====
+
 include::modules/virt-about-vtpm-devices.adoc[leveloffset=+1]
+
 include::modules/virt-adding-vtpm-to-vm.adoc[leveloffset=+1]
diff --git a/virt/managing_vms/virtual_disks/virt-migrating-storage-class.adoc b/virt/managing_vms/virtual_disks/virt-migrating-storage-class.adoc
new file mode 100644
index 000000000000..7f766f2300b5
--- /dev/null
+++ b/virt/managing_vms/virtual_disks/virt-migrating-storage-class.adoc
@@ -0,0 +1,13 @@
+:_mod-docs-content-type: ASSEMBLY
+
+[id="virt-migrating-storage-class"]
+= Migrating VM disks to a different storage class
+
+include::_attributes/common-attributes.adoc[]
+:context: virt-migrating-storage-class
+
+toc::[]
+
+You can migrate one or more virtual disks to a different storage class without stopping your virtual machine (VM) or virtual machine instance (VMI).
+
+include::modules/virt-migrating-storage-class-ui.adoc[leveloffset=+1]
diff --git a/virt/monitoring/virt-exposing-custom-metrics-for-vms.adoc b/virt/monitoring/virt-exposing-custom-metrics-for-vms.adoc
index 32fd3aab3aa7..8b37dbcb453c 100644
--- a/virt/monitoring/virt-exposing-custom-metrics-for-vms.adoc
+++ b/virt/monitoring/virt-exposing-custom-metrics-for-vms.adoc
@@ -21,17 +21,17 @@ include::modules/virt-accessing-node-exporter-outside-cluster.adoc[leveloffset=+
 [id="additional-resources_virt-exposing-custom-metrics-for-vms"]
 == Additional resources
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
-* xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#configuring-the-monitoring-stack[Configuring the monitoring stack]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/getting-started/core-platform-monitoring-first-steps.adoc#core-platform-monitoring-first-steps[Core platform monitoring first steps]
 
-* xref:../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
+* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
 
-* xref:../../observability/monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
+* xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#accessing-metrics-as-a-developer[Accessing metrics as a developer]
 
-* xref:../../observability/monitoring/reviewing-monitoring-dashboards.adoc#reviewing-monitoring-dashboards[Reviewing monitoring dashboards]
+* xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-a-developer.adoc#reviewing-monitoring-dashboards-developer_accessing-metrics-as-a-developer[Reviewing monitoring dashboards as a developer]
 
 * xref:../../applications/application-health.adoc#application-health[Monitoring application health by using health checks]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 * xref:../../nodes/pods/nodes-pods-configmaps.adoc#nodes-pods-configmaps[Creating and using config maps]
 
diff --git a/virt/monitoring/virt-monitoring-overview.adoc b/virt/monitoring/virt-monitoring-overview.adoc
index 73d927904f72..10052bf661da 100644
--- a/virt/monitoring/virt-monitoring-overview.adoc
+++ b/virt/monitoring/virt-monitoring-overview.adoc
@@ -11,14 +11,14 @@ You can monitor the health of your cluster and virtual machines (VMs) with the f
 Monitoring {VirtProductName} VM health status::
 View the overall health of your {VirtProductName} environment in the web console by navigating to the *Home* -> *Overview* page in the {product-title} web console. The *Status* card displays the overall health of {VirtProductName} based on the alerts and conditions.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/monitoring/virt-running-cluster-checkups.adoc#virt-running-cluster-checkups[{product-title} cluster checkup framework]::
 Run automated tests on your cluster with the {product-title} cluster checkup framework to check the following conditions:
 * Network connectivity and latency between two VMs attached to a secondary network interface
 * VM running a Data Plane Development Kit (DPDK) workload with zero packet loss
 * Cluster storage is optimally configured for {VirtProductName}
 //* The {product-title} cluster can run real-time virtualized workloads.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 //:FeatureName: The {product-title} cluster checkup framework
 //include::snippets/technology-preview.adoc[]
@@ -33,7 +33,12 @@ xref:../../virt/monitoring/virt-monitoring-vm-health.adoc#virt-monitoring-vm-hea
 Configure readiness, liveness, and guest agent ping probes and a watchdog for VMs.
 
 xref:../../virt/monitoring/virt-runbooks.adoc#virt-runbooks[Runbooks]::
+ifdef::openshift-dedicated,openshift-rosa[]
 Diagnose and resolve issues that trigger {VirtProductName} xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[alerts] in the {product-title} web console.
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+Diagnose and resolve issues that trigger {VirtProductName} xref:../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-managing-alerts_key-concepts[alerts] in the {product-title} web console.
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 //:FeatureName: The guest agent ping probe
 //include::snippets/technology-preview.adoc[]
diff --git a/virt/monitoring/virt-monitoring-vm-health.adoc b/virt/monitoring/virt-monitoring-vm-health.adoc
index ab7a199d6409..d024e71d7e15 100644
--- a/virt/monitoring/virt-monitoring-vm-health.adoc
+++ b/virt/monitoring/virt-monitoring-vm-health.adoc
@@ -26,7 +26,7 @@ You can define a watchdog to monitor the health of the guest operating system by
 
 The watchdog device monitors the agent and performs one of the following actions if the guest operating system is unresponsive:
 
-* `poweroff`: The VM powers down immediately. If `spec.running` is set to `true` or `spec.runStrategy` is not set to `manual`, then the VM reboots.
+* `poweroff`: The VM powers down immediately. If `spec.runStrategy` is not set to `manual`, the VM reboots.
 * `reset`: The VM reboots in place and the guest operating system cannot react.
 +
 [NOTE]
@@ -46,15 +46,15 @@ include::modules/virt-defining-watchdog-device-vm.adoc[leveloffset=+2]
 include::modules/virt-installing-watchdog-agent.adoc[leveloffset=+2]
 
 // Hiding in ROSA/OSD as TP not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-define-guest-agent-ping-probe.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [id="additional-resources_monitoring-vm-health"]
 [role="_additional-resources"]
 == Additional resources
 
 * xref:../../applications/application-health.adoc#application-health[Monitoring application health by using health checks]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/monitoring/virt-prometheus-queries.adoc b/virt/monitoring/virt-prometheus-queries.adoc
index 0c57a5252708..694eaefc738b 100644
--- a/virt/monitoring/virt-prometheus-queries.adoc
+++ b/virt/monitoring/virt-prometheus-queries.adoc
@@ -7,29 +7,27 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 {VirtProductName} provides metrics that you can use to monitor the consumption of cluster infrastructure resources, including vCPU, network, storage, and guest memory swapping. You can also use metrics to query live migration status.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 Use the {product-title} monitoring dashboard to query virtualization metrics.
 {VirtProductName} provides metrics that you can use to monitor the consumption of cluster infrastructure resources, including network, storage, and guest memory swapping. You can also use metrics to query live migration status.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="prerequisites_{context}"]
 == Prerequisites
 
 // Hiding in ROSA/OSD as user cannot edit MCO
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * To use the vCPU metric, the `schedstats=enable` kernel argument must be applied to the `MachineConfig` object. This kernel argument enables scheduler statistics used for debugging and performance tuning and adds a minor additional load to the scheduler. For more information, see xref:../../machine_configuration/machine-configs-configure.adoc#nodes-nodes-kernel-arguments_machine-configs-configure[Adding kernel arguments to nodes].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 * For guest memory swapping queries to return data, memory swapping must be enabled on the virtual guests.
 
-include::modules/monitoring-about-querying-metrics.adoc[leveloffset=+1]
+include::modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc[leveloffset=+1]
 
-include::modules/monitoring-querying-metrics-for-all-projects-as-an-administrator.adoc[leveloffset=+2]
-
-include::modules/monitoring-querying-metrics-for-user-defined-projects-as-a-developer.adoc[leveloffset=+2]
+include::modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc[leveloffset=+1]
 
 include::modules/virt-querying-metrics.adoc[leveloffset=+1]
 
@@ -38,8 +36,13 @@ include::modules/virt-live-migration-metrics.adoc[leveloffset=+2]
 [id="additional-resources_virt-prometheus-queries"]
 [role="_additional-resources"]
 == Additional resources
-
+// HCP link removed for now
+ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 * link:https://prometheus.io/docs/prometheus/latest/querying/basics/[Querying Prometheus]
 
diff --git a/virt/monitoring/virt-runbooks.adoc b/virt/monitoring/virt-runbooks.adoc
index d4bf1bced9cf..ae9e26ed16ad 100644
--- a/virt/monitoring/virt-runbooks.adoc
+++ b/virt/monitoring/virt-runbooks.adoc
@@ -7,7 +7,14 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 :!virt-runbooks:
-To diagnose and resolve issues that trigger {VirtProductName} xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[alerts], follow the procedures in the runbooks for the {VirtProductName} Operator. Triggered {VirtProductName} alerts can be viewed in the main *Observe* -> *Alerts* tab in the web console, and also in the *Virtualization* -> *Overview* tab.
+To diagnose and resolve issues that trigger {VirtProductName} 
+ifdef::openshift-dedicated,openshift-rosa[]
+xref:../../observability/monitoring/managing-alerts.adoc#managing-alerts[alerts], 
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+xref:../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-managing-alerts_key-concepts[alerts], 
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+follow the procedures in the runbooks for the {VirtProductName} Operator. Triggered {VirtProductName} alerts can be viewed in the main *Observe* -> *Alerts* tab in the web console, and also in the *Virtualization* -> *Overview* tab.
 
 Runbooks for the {VirtProductName} Operator are maintained in the link:https://github.com/openshift/runbooks/tree/master/alerts/openshift-virtualization-operator[openshift/runbooks] Git repository, and you can view them on GitHub. 
 
diff --git a/virt/monitoring/virt-running-cluster-checkups.adoc b/virt/monitoring/virt-running-cluster-checkups.adoc
index f30b9aa5f257..53e84dc987b3 100644
--- a/virt/monitoring/virt-running-cluster-checkups.adoc
+++ b/virt/monitoring/virt-running-cluster-checkups.adoc
@@ -63,20 +63,20 @@ include::modules/virt-building-real-time-container-disk-image.adoc[leveloffset=+
 ////
 
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_running-cluster-checkups"]
 == Additional resources
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Attaching a virtual machine to multiple networks]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 // Hiding pending resolution of	OSDOCS-3691
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../networking/hardware_networks/using-dpdk-and-rdma.adoc#example-vf-use-in-dpdk-mode-intel_using-dpdk-and-rdma[Using a virtual function in DPDK mode with an Intel NIC]
 * xref:../../networking/hardware_networks/using-dpdk-and-rdma.adoc#nw-example-dpdk-line-rate_using-dpdk-and-rdma[Using SR-IOV and the Node Tuning Operator to achieve a DPDK line rate]
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/composing_a_customized_rhel_system_image/installing-composer_composing-a-customized-rhel-system-image[Installing image builder]
 * link:https://access.redhat.com/solutions/253273[How to register and subscribe a RHEL system to the Red Hat Customer Portal using Red Hat Subscription Manager]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/nodes/virt-node-maintenance.adoc b/virt/nodes/virt-node-maintenance.adoc
index 83075222a328..9bdce4d490f1 100644
--- a/virt/nodes/virt-node-maintenance.adoc
+++ b/virt/nodes/virt-node-maintenance.adoc
@@ -38,7 +38,7 @@ VM eviction strategy::
 
 The VM `LiveMigrate` eviction strategy ensures that a virtual machine instance (VMI) is not interrupted if the node is placed into maintenance or drained. VMIs with this eviction strategy will be live migrated to another node.
 +
-You can configure eviction strategies for virtual machines (VMs) by using the {VirtProductName} web console or the xref:../../virt/live_migration/virt-configuring-live-migration.adoc#virt-configuring-a-live-migration-policy_virt-configuring-live-migration[command line].
+You can configure eviction strategies for virtual machines (VMs) by using the {product-title} web console or the xref:../../virt/live_migration/virt-configuring-live-migration.adoc#virt-configuring-a-live-migration-policy_virt-configuring-live-migration[command line].
 +
 [IMPORTANT]
 ====
@@ -82,14 +82,7 @@ endif::openshift-rosa,openshift-dedicated[]
 [id="run-strategies"]
 == Run strategies
 
-A virtual machine (VM) configured with `spec.running: true` is immediately restarted. The `spec.runStrategy` key provides greater flexibility for determining how a VM behaves under certain conditions.
-
-[IMPORTANT]
-====
-The `spec.runStrategy` and `spec.running` keys are mutually exclusive. Only one of them can be used.
-
-A VM configuration with both keys is invalid.
-====
+The `spec.runStrategy` key determines how a VM behaves under certain conditions.
 
 include::modules/virt-runstrategies-vms.adoc[leveloffset=+2]
 
diff --git a/virt/post_installation_configuration/virt-node-placement-virt-components.adoc b/virt/post_installation_configuration/virt-node-placement-virt-components.adoc
index 60741db71643..929dc3c4ce05 100644
--- a/virt/post_installation_configuration/virt-node-placement-virt-components.adoc
+++ b/virt/post_installation_configuration/virt-node-placement-virt-components.adoc
@@ -25,6 +25,6 @@ include::modules/virt-node-placement-rule-examples.adoc[leveloffset=+1]
 * xref:../../virt/managing_vms/advanced_vm_management/virt-specifying-nodes-for-vms.adoc#virt-specifying-nodes-for-vms[Specifying nodes for virtual machines]
 * xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
 * xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity[Controlling pod placement on nodes using node affinity rules]
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/virt/post_installation_configuration/virt-post-install-config.adoc b/virt/post_installation_configuration/virt-post-install-config.adoc
index 5eec482e80cd..1e2cad2a2ea6 100644
--- a/virt/post_installation_configuration/virt-post-install-config.adoc
+++ b/virt/post_installation_configuration/virt-post-install-config.adoc
@@ -14,16 +14,16 @@ The following procedures are typically performed after {VirtProductName} is inst
 
 * xref:../../virt/post_installation_configuration/virt-post-install-network-config.adoc#virt-post-install-network-config[Network configuration]:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 ** Installing the Kubernetes NMState and SR-IOV Operators
 ** Configuring a Linux bridge network for external access to virtual machines (VMs)
 ** Configuring a dedicated secondary network for live migration
 ** Configuring an SR-IOV network
 ** Enabling the creation of load balancer services by using the {product-title} web console
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 ** Enabling the creation of load balancer services by using the {product-title} web console
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 * xref:../../virt/post_installation_configuration/virt-post-install-storage-config.adoc#virt-post-install-storage-config[Storage configuration]:
 ** Defining a default storage class for the Container Storage Interface (CSI)
diff --git a/virt/post_installation_configuration/virt-post-install-network-config.adoc b/virt/post_installation_configuration/virt-post-install-network-config.adoc
index f5508ff62712..dcf0fdc171c5 100644
--- a/virt/post_installation_configuration/virt-post-install-network-config.adoc
+++ b/virt/post_installation_configuration/virt-post-install-network-config.adoc
@@ -8,24 +8,24 @@ toc::[]
 
 By default, {VirtProductName} is installed with a single, internal pod network.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 After you install {VirtProductName}, you can install networking Operators and configure additional networks.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="installing-operators"]
 == Installing networking Operators
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You must install the xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Kubernetes NMState Operator] to configure a Linux bridge network for live migration or external access to virtual machines (VMs). For installation instructions, see xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#installing-the-kubernetes-nmstate-operator-web-console_k8s-nmstate-operator[Installing the Kubernetes NMState Operator by using the web console].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can install the xref:../../networking/hardware_networks/about-sriov.adoc#about-sriov[SR-IOV Operator] to manage SR-IOV network devices and network attachments. For installation instructions, see xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sr-iov-operator_installing-sriov-operator[Installing the SR-IOV Network Operator].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can add the xref:../../networking/networking_operators/metallb-operator/about-metallb.adoc#about-metallb[About MetalLB and the MetalLB Operator] to manage the lifecycle for an instance of MetalLB on your cluster. For installation instructions, see xref:../../networking/networking_operators/metallb-operator/metallb-operator-install.adoc#installing-the-metallb-operator-using-web-console_metallb-operator-install[Installing the MetalLB Operator from the OperatorHub using the web console].
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="configuring-linux-bridge-network"]
 == Configuring a Linux bridge network
@@ -36,10 +36,10 @@ include::modules/virt-creating-linux-bridge-nncp.adoc[leveloffset=+2]
 
 include::modules/virt-creating-linux-bridge-nad-web.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 .Next steps
 * xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-attaching-vm-secondary-network-cli_virt-connecting-vm-to-linux-bridge[Attaching a virtual machine (VM) to a Linux bridge network]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="configuring-network-live-migration"]
 == Configuring a network for live migration
@@ -50,7 +50,7 @@ include::modules/virt-configuring-secondary-network-vm-live-migration.adoc[level
 
 include::modules/virt-selecting-migration-network-ui.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [id="configuring-sriov-network"]
 == Configuring an SR-IOV network
 
@@ -63,6 +63,6 @@ include::modules/nw-sriov-network-attachment.adoc[leveloffset=+2]
 .Next steps
 
 * xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-attaching-vm-to-sriov-network_virt-connecting-vm-to-sriov[Attaching a virtual machine (VM) to an SR-IOV network]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-enabling-load-balancer-service-web.adoc[leveloffset=+1]
diff --git a/virt/post_installation_configuration/virt-post-install-storage-config.adoc b/virt/post_installation_configuration/virt-post-install-storage-config.adoc
index c43932bb8d9f..5ab3c01c0ac0 100644
--- a/virt/post_installation_configuration/virt-post-install-storage-config.adoc
+++ b/virt/post_installation_configuration/virt-post-install-storage-config.adoc
@@ -8,9 +8,9 @@ toc::[]
 
 The following storage configuration tasks are mandatory:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * You must configure a xref:../../storage/dynamic-provisioning.adoc#defining-storage-classes_dynamic-provisioning[default storage class] for your cluster. Otherwise, the cluster cannot receive automated boot source updates.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * You must configure xref:../../virt/storage/virt-configuring-storage-profile.adoc#virt-configuring-storage-profile[storage profiles] if your storage provider is not recognized by CDI. A storage profile provides recommended storage settings based on the associated storage class.
 
 Optional: You can configure local storage by using the hostpath provisioner (HPP).
diff --git a/virt/storage/virt-automatic-bootsource-updates.adoc b/virt/storage/virt-automatic-bootsource-updates.adoc
index 9ffba454afd5..b847292f86b2 100644
--- a/virt/storage/virt-automatic-bootsource-updates.adoc
+++ b/virt/storage/virt-automatic-bootsource-updates.adoc
@@ -28,18 +28,20 @@ include::modules/virt-managing-auto-update-all-system-boot-sources.adoc[leveloff
 
 _Custom_ boot sources that are not provided by {VirtProductName} are not controlled by the feature gate. You must manage them individually by editing the `HyperConverged` custom resource (CR).
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 You must configure a storage class. Otherwise, the cluster cannot receive automated updates for custom boot sources. See xref:../../storage/dynamic-provisioning.adoc#defining-storage-classes_dynamic-provisioning[Defining a storage class] for details. 
 ====
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 You must configure a storage profile. Otherwise, the cluster cannot receive automated updates for custom boot sources. See xref:../../virt/storage/virt-configuring-storage-profile.adoc#virt-configuring-storage-profile[Configure storage profiles] for details.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+include::modules/virt-configuring-default-and-virt-default-storage-class.adoc[leveloffset=+2]
 
 include::modules/virt-configuring-storage-class-bootsource-update.adoc[leveloffset=+2]
 
diff --git a/virt/storage/virt-configuring-storage-profile.adoc b/virt/storage/virt-configuring-storage-profile.adoc
index 5dc544adcb14..b01e41bf02ba 100644
--- a/virt/storage/virt-configuring-storage-profile.adoc
+++ b/virt/storage/virt-configuring-storage-profile.adoc
@@ -12,13 +12,14 @@ The Containerized Data Importer (CDI) recognizes a storage provider if it has be
 
 For recognized storage types, the CDI provides values that optimize the creation of PVCs. You can also configure automatic settings for the storage class by customizing the storage profile. If the CDI does not recognize your storage provider, you must configure storage profiles.
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [IMPORTANT]
 ====
 When using {VirtProductName} with {rh-storage-first}, specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.
 
 To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and `VolumeMode: Block`.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-customizing-storage-profile.adoc[leveloffset=+1]
+include::modules/virt-viewing-automatically-created-storage-profiles.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/virt/storage/virt-storage-config-overview.adoc b/virt/storage/virt-storage-config-overview.adoc
index b937496a21b3..473979ea7e58 100644
--- a/virt/storage/virt-storage-config-overview.adoc
+++ b/virt/storage/virt-storage-config-overview.adoc
@@ -13,11 +13,11 @@ You can configure a default storage class, storage profiles, Containerized Data
 
 The following storage configuration tasks are mandatory:
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../storage/dynamic-provisioning.adoc#defining-storage-classes_dynamic-provisioning[Configure a default storage class]::
 
 You must configure a default storage class for your cluster. Otherwise, the cluster cannot receive automated boot source updates.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 xref:../../virt/storage/virt-configuring-storage-profile.adoc#virt-configuring-storage-profile[Configure storage profiles]::
 
diff --git a/virt/support/virt-collecting-virt-data.adoc b/virt/support/virt-collecting-virt-data.adoc
index 5ff7c8d17a71..9b1ff9703d69 100644
--- a/virt/support/virt-collecting-virt-data.adoc
+++ b/virt/support/virt-collecting-virt-data.adoc
@@ -9,18 +9,23 @@ toc::[]
 When you submit a xref:../../support/getting-support.adoc#support-submitting-a-case_getting-support[support case] to Red Hat Support, it is helpful to provide debugging information for {product-title} and {VirtProductName} by using the following tools:
 
 // must-gather not supported for ROSA/OSD, per Dustin Row
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 must-gather tool::
 The `must-gather` tool collects diagnostic information, including resource definitions and service logs.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 Prometheus::
 Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
 
 Alertmanager::
 The Alertmanager service handles alerts received from Prometheus. The Alertmanager is also responsible for sending the alerts to external notification systems.
-
+//link needs to be added for HCP when available
+ifdef::openshift-dedicated,openshift-rosa[]
 For information about the {product-title} monitoring stack, see xref:../../observability/monitoring/monitoring-overview.adoc#about-openshift-monitoring[About {product-title} monitoring].
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+For information about the {product-title} monitoring stack, see xref:../../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring].
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // This procedure is in the assembly so that we can add xrefs instead of a long list of additional resources.
 [id="virt-collecting-data-about-your-environment_{context}"]
@@ -29,22 +34,29 @@ For information about the {product-title} monitoring stack, see xref:../../obser
 Collecting data about your environment minimizes the time required to analyze and determine the root cause.
 
 .Prerequisites
-
+//link needs to be added for HCP when available
+ifdef::openshift-dedicated,openshift-rosa[]
 * xref:../../observability/monitoring/configuring-the-monitoring-stack.adoc#modifying-retention-time-for-prometheus-metrics-data_configuring-the-monitoring-stack[Set the retention time for Prometheus metrics data] to a minimum of seven days.
 * xref:../../observability/monitoring/managing-alerts.adoc#sending-notifications-to-external-systems_managing-alerts[Configure the Alertmanager to capture relevant alerts and to send alert notifications to a dedicated mailbox] so that they can be viewed and persisted outside the cluster.
+endif::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+* xref:../../observability/monitoring/configuring-core-platform-monitoring/storing-and-recording-data.adoc#modifying-retention-time-for-prometheus-metrics-data_storing-and-recording-data[Set the retention time for Prometheus metrics data] to a minimum of seven days.
+* xref:../../observability/monitoring/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc#configuring-alert-notifications_configuring-alerts-and-notifications[Configure the Alertmanager to capture relevant alerts and to send alert notifications to a dedicated mailbox] so that they can be viewed and persisted outside the cluster.
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Record the exact number of affected nodes and virtual machines.
 
 .Procedure
 
 // must-gather not supported for ROSA/OSD, per Dustin Row
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 . xref:../../support/gathering-cluster-data.adoc#support_gathering_data_gathering-cluster-data[Collect must-gather data for the cluster].
-. link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/troubleshooting_openshift_data_foundation/index#downloading-log-files-and-diagnostic-information_rhodf[Collect must-gather data for {rh-storage-first}], if necessary.
+. link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.18/html-single/troubleshooting_openshift_data_foundation/index#downloading-log-files-and-diagnostic-information_rhodf[Collect must-gather data for {rh-storage-first}], if necessary.
 . xref:../../virt/support/virt-collecting-virt-data.adoc#virt-using-virt-must-gather_virt-collecting-virt-data[Collect must-gather data for {VirtProductName}].
-. xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-all-projects-as-an-administrator_managing-metrics[Collect Prometheus metrics for the cluster].
-endif::openshift-rosa,openshift-dedicated[]
+. xref:../../observability/monitoring/accessing-metrics/accessing-metrics-as-an-administrator.adoc#querying-metrics-for-all-projects-with-mon-dashboard_accessing-metrics-as-an-administrator[Collect Prometheus metrics for the cluster].
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+//link needs to be added for HCP when available
 ifdef::openshift-rosa,openshift-dedicated[]
-* xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-all-projects-as-an-administrator_managing-metrics[Collect Prometheus metrics for the cluster].
+* xref:../../observability/monitoring/managing-metrics.adoc#querying-metrics-for-all-projects-with-mon-dashboard_managing-metrics[Collect Prometheus metrics for the cluster].
 endif::openshift-rosa,openshift-dedicated[]
 
 [id="virt-collecting-data-about-vms_{context}"]
@@ -64,16 +76,16 @@ Collecting data about malfunctioning virtual machines (VMs) minimizes the time r
 .Procedure
 
 // must-gather not supported for ROSA/OSD, per Dustin Row
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 . xref:../../virt/support/virt-collecting-virt-data.adoc#virt-must-gather-options_virt-collecting-virt-data[Collect must-gather data for the VMs] using the `/usr/bin/gather` script.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 . Collect screenshots of VMs that have crashed _before_ you restart them.
 . xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#vm-memory-dump-commands_virt-using-the-cli-tools[Collect memory dumps from VMs] _before_ remediation attempts.
 . Record factors that the malfunctioning VMs have in common. For example, the VMs have the same host or network.
 
 // must-gather not supported for ROSA/OSD, per Dustin Row
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-using-virt-must-gather.adoc[leveloffset=+1]
 
 include::modules/virt-must-gather-options.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/support/virt-support-overview.adoc b/virt/support/virt-support-overview.adoc
index c7537b794a9a..4935adc8ddfb 100644
--- a/virt/support/virt-support-overview.adoc
+++ b/virt/support/virt-support-overview.adoc
@@ -31,13 +31,13 @@ xref:../../virt/support/virt-collecting-virt-data.adoc#virt-collecting-data-abou
 Configure Prometheus and Alertmanager and collect `must-gather` data for {product-title} and {VirtProductName}.
 
 // must-gather not supported for ROSA/OSD, per Dustin Row
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/support/virt-collecting-virt-data.adoc#virt-using-virt-must-gather_virt-collecting-virt-data[`must-gather` tool for {VirtProductName}]::
 Configure and use the `must-gather` tool.
 
 xref:../../virt/support/virt-collecting-virt-data.adoc#virt-collecting-data-about-vms_virt-collecting-virt-data[Collecting data about VMs]::
 Collect `must-gather` data and memory dumps from VMs.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="virt-creating-jira-issue_{context}"]
 === Creating a Jira issue
diff --git a/virt/support/virt-troubleshooting.adoc b/virt/support/virt-troubleshooting.adoc
index 78c93c7fe675..655907bad628 100644
--- a/virt/support/virt-troubleshooting.adoc
+++ b/virt/support/virt-troubleshooting.adoc
@@ -83,8 +83,8 @@ include::modules/virt-loki-log-queries.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources for LokiStack and LogQL
-* xref:../../observability/logging/log_storage/about-log-storage.adoc#about-log-storage[About log storage]
-* xref:../../observability/logging/log_storage/installing-log-storage.adoc#cluster-logging-loki-deploy_installing-log-storage[Deploying the LokiStack]
+//* xref :../../observability/logging/log_storage/about-log-storage.adoc#about-log-storage[About log storage]
+//* xref :../../observability/logging/log_storage/installing-log-storage.adoc#cluster-logging-loki-deploy_installing-log-storage[Deploying the LokiStack]
 * link:https://grafana.com/docs/loki/latest/logql/log_queries/[LogQL log queries] in the Grafana documentation
 
 include::modules/virt-common-error-messages.adoc[leveloffset=+1]
diff --git a/virt/updating/upgrading-virt.adoc b/virt/updating/upgrading-virt.adoc
index 13c7efa97319..0fc4885214ec 100644
--- a/virt/updating/upgrading-virt.adoc
+++ b/virt/updating/upgrading-virt.adoc
@@ -6,47 +6,54 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-Learn how Operator Lifecycle Manager (OLM) delivers z-stream and minor version updates for {VirtProductName}.
-
-include::modules/virt-rhel-9.adoc[leveloffset=+1]
+Learn how to keep {VirtProductName} updated and compatible with {product-title}.
 
 include::modules/virt-about-upgrading-virt.adoc[leveloffset=+1]
 
-include::modules/virt-about-workload-updates.adoc[leveloffset=+2]
-
-ifndef::openshift-rosa,openshift-dedicated,openshift-origin[]
-include::modules/virt-about-control-plane-only-updates.adoc[leveloffset=+2]
+include::modules/virt-rhel-9.adoc[leveloffset=+2]
 
-Learn more about xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update].
+include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+1]
 
-include::modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc[leveloffset=+1]
-endif::openshift-rosa,openshift-dedicated,openshift-origin[]
+// workload updates
 
-include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+1]
+include::modules/virt-about-workload-updates.adoc[leveloffset=+1]
 
-[id="approving-operator-upgrades_upgrading-virt"]
-== Approving pending Operator updates
-
-include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+2]
-
-[id="monitoring-upgrade-status_upgrading-virt"]
-== Monitoring update status
-
-include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+2]
+include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+2]
 
 include::modules/virt-viewing-outdated-workloads.adoc[leveloffset=+2]
 
 [NOTE]
 ====
-Configure workload updates to ensure that VMIs update automatically.
+To ensure that VMIs update automatically, configure workload updates.
 ====
 
+// control plane updates
+
+ifndef::openshift-rosa,openshift-dedicated,openshift-origin,openshift-rosa-hcp[]
+include::modules/virt-about-control-plane-only-updates.adoc[leveloffset=+1]
+
+Learn more about xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update].
+
+include::modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc[leveloffset=+2]
+endif::openshift-rosa,openshift-dedicated,openshift-origin,openshift-rosa-hcp[]
+
+[id="advanced-options_upgrading-virt"]
+== Advanced options
+
+The *stable* release channel and the *Automatic* approval strategy are recommended for most {VirtProductName} installations. Use other settings only if you understand the risks.
+
+include::modules/virt-changing-update-settings.adoc[leveloffset=+2]
+
+include::modules/virt-manual-approval-strategy.adoc[leveloffset=+2]
+
+include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+2]
+
 [id="additional-resources_upgrading-virt"]
 [role="_additional-resources"]
 == Additional resources
-ifndef::openshift-rosa,openshift-dedicated,openshift-origin[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-origin,openshift-rosa-hcp[]
 * xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
-endif::openshift-rosa,openshift-dedicated,openshift-origin[]
+endif::openshift-rosa,openshift-dedicated,openshift-origin,openshift-rosa-hcp[]
 * xref:../../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[What are Operators?]
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Operator Lifecycle Manager concepts and resources]
 * xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-csv_olm-understanding-olm[Cluster service versions (CSVs)]
diff --git a/virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc b/virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc
index 5f91e94be36a..1ac19567d813 100644
--- a/virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc
+++ b/virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc
@@ -19,8 +19,8 @@ include::modules/virt-connecting-vm-secondarynw-using-fqdn.adoc[leveloffset=+1]
 [id="additional-resources_accessing-vm-secondary-network-fqdn"]
 == Additional resources
 // Hiding until OSDOCS-3691 is merged
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-load-balancer.adoc#configuring-ingress-cluster-traffic-load-balancer[Configuring ingress cluster traffic using a load balancer]
 * xref:../../networking/networking_operators/metallb-operator/about-metallb.adoc#about-metallb_about-metallb[About MetalLB and the MetalLB Operator]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/vm_networking/virt-configuring-viewing-ips-for-vms.adoc#configuring-ips_virt-configuring-viewing-ips-for-vms[Configuring IP addresses for virtual machines]
diff --git a/virt/vm_networking/virt-connecting-vm-to-default-pod-network.adoc b/virt/vm_networking/virt-connecting-vm-to-default-pod-network.adoc
index 7e8a11d7a36f..3f8da3c661d4 100644
--- a/virt/vm_networking/virt-connecting-vm-to-default-pod-network.adoc
+++ b/virt/vm_networking/virt-connecting-vm-to-default-pod-network.adoc
@@ -21,10 +21,10 @@ include::modules/virt-configuring-masquerade-mode-dual-stack.adoc[leveloffset=+1
 include::modules/virt-jumbo-frames-vm-pod-nw.adoc[leveloffset=+1]
 
 // Hiding from ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_virt-connecting-vm-to-default-pod-network"]
 == Additional resources
 * xref:../../networking/changing-cluster-network-mtu.adoc#changing-cluster-network-mtu[Changing the MTU for the cluster network]
 * xref:../../scalability_and_performance/optimization/optimizing-networking.adoc#optimizing-mtu_optimizing-networking[Optimizing the MTU for your network]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc b/virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc
index 0317b5e112ce..76baa51e504f 100644
--- a/virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc
+++ b/virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc
@@ -6,13 +6,13 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a VM to an Open Virtual Network (OVN)-Kubernetes secondary network. {VirtProductName} supports the `layer2` topology for OVN-Kubernetes.
 
 A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes.
 
 * A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.
@@ -23,18 +23,18 @@ You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {
 ====
 An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You can use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
 
 . xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 [NOTE]
 ====
 For `localnet` topology, you must xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-localnet-switched-topology_configuring-additional-network-ovnk[configure an OVS bridge] by creating a `NodeNetworkConfigurationPolicy` object before creating the NAD.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 . xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes secondary network] by adding the network details to the VM specification.
 
@@ -50,15 +50,15 @@ Configuring IP address management (IPAM) by specifying the `spec.config.ipam.sub
 
 include::modules/virt-creating-layer2-nad-cli.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-creating-localnet-nad-cli.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-creating-nad-l2-overlay-console.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 include::modules/virt-creating-nad-localnet-console.adoc[leveloffset=+2]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="attaching-vm-to-ovn-secondary-nw"]
 == Attaching a virtual machine to the OVN-Kubernetes secondary network
@@ -68,11 +68,11 @@ You can attach a virtual machine (VM) to the OVN-Kubernetes secondary network in
 include::modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc[leveloffset=+2]
 
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_virt-connecting-vm-to-ovn-secondary-network"]
 == Additional resources
 * xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-ovnk-additional-networks_configuring-additional-network[Creating secondary networks on OVN-Kubernetes]
 * xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[About the Kubernetes NMState Operator]
 * xref:../../networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc#understanding-multiple-networks[Creating primary networks using a NetworkAttachmentDefinition]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc b/virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc
new file mode 100644
index 000000000000..bd1d81b12bf1
--- /dev/null
+++ b/virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc
@@ -0,0 +1,74 @@
+:_mod-docs-content-type: ASSEMBLY                               
+[id="virt-connecting-vm-to-primary-udn"]                                    
+= Connecting a virtual machine to a primary user-defined network                                                
+include::_attributes/common-attributes.adoc[]                   
+:context: virt-connecting-vm-to-primary-udn                                    
+                                                                
+toc::[]                
+
+You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM's primary interface by using the {product-title} web console or the CLI. The primary user-defined network replaces the default pod network in your specified namespace. Unlike the pod network, you can define the primary UDN per project, where each project can use its specific subnet and topology.
+
+{VirtProductName} supports the namespace-scoped `UserDefinedNetwork` and the cluster-scoped `ClusterUserDefinedNetwork` custom resource definitions (CRD). 
+
+Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN network across multiple namespaces.
+
+[NOTE]
+====
+You must add the `k8s.ovn.org/primary-user-defined-network` label when you create a namespace that is to be used with user-defined networks.
+====
+
+With the layer 2 topology, OVN-Kubernetes creates an overlay network between nodes. You can use this overlay network to connect VMs on different nodes without having to configure any additional physical networking infrastructure. 
+
+The layer 2 topology enables seamless migration of VMs without the need for Network Address Translation (NAT) because persistent IP addresses are preserved across cluster nodes during live migration. 
+
+You must consider the following limitations before implementing a primary UDN:
+
+* You cannot use the `virtctl ssh` command to configure SSH access to a VM.
+* You cannot use the `oc port-forward` command to forward ports to a VM.
+* You cannot use headless services to access a VM.
+* You cannot define readiness and liveness probes to configure VM health checks.
+ 
+[NOTE]
+====
+{VirtProductName} currently does not support secondary user-defined networks.
+====
+
+[id="creating-primary-udn-web_{context}"]
+== Creating a primary user-defined network by using the web console
+
+You can use the {product-title} web console to create a primary namespace-scoped `UserDefinedNetwork` or a cluster-scoped `ClusterUserDefinedNetwork` CRD. The UDN serves as the default primary network for pods and VMs that you create in namespaces associated with the network.
+
+include::modules/virt-creating-udn-namespace-web.adoc[leveloffset=+2]
+
+include::modules/virt-creating-primary-udn-web.adoc[leveloffset=+2]
+
+include::modules/virt-creating-primary-cluster-udn-web.adoc[leveloffset=+2]
+
+[id="next-steps-web_{context}"]
+.Next steps
+* xref:../../virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc#virt-creating-udn-namespace-web_virt-connecting-vm-to-primary-udn[Create namespaces that are associated with the cluster-scoped UDN]
+
+[id="creating-primary-udn-cli_{context}"]
+== Creating a primary user-defined network by using the CLI
+
+You can create a primary `UserDefinedNetwork` or `ClusterUserDefinedNetwork` CRD by using the CLI.
+
+include::modules/virt-creating-udn-namespace-cli.adoc[leveloffset=+2]
+
+include::modules/virt-creating-a-primary-udn.adoc[leveloffset=+2]
+
+include::modules/virt-creating-a-primary-cluster-udn.adoc[leveloffset=+2]
+
+[id="next-steps-cli_{context}"]
+.Next steps
+* xref:../../virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc#virt-creating-udn-namespace-cli_virt-connecting-vm-to-primary-udn[Create namespaces that are associated with the cluster-scoped UDN]
+
+include::modules/virt-attaching-vm-to-primary-udn.adoc[leveloffset=+1]
+
+//Excluding from ROSA because the Networking -> Multiple networks -> Primary networks section is not part of ROSA docs
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+* xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-user-defined-networks[About user-defined networks]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/virt/vm_networking/virt-connecting-vm-to-service-mesh.adoc b/virt/vm_networking/virt-connecting-vm-to-service-mesh.adoc
index 33ef7912bc07..03e5fb278fd2 100644
--- a/virt/vm_networking/virt-connecting-vm-to-service-mesh.adoc
+++ b/virt/vm_networking/virt-connecting-vm-to-service-mesh.adoc
@@ -10,12 +10,12 @@ toc::[]
 
 include::modules/virt-adding-vm-to-service-mesh.adoc[leveloffset=+1]
 
-// Hiding in OSD until PR 67901 merges
-ifndef::openshift-dedicated[]
+// Hiding in OSD until PR 67901 merges - HCP hidden as well
+ifndef::openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_virt-connecting-vm-to-service-mesh"]
 == Additional resources
 * xref:../../service_mesh/v2x/installing-ossm.adoc#installing-ossm[Installing the Service Mesh Operators]
 * xref:../../service_mesh/v2x/ossm-create-smcp.adoc#ossm-create-smcp[Creating the Service Mesh control plane]
 * xref:../../service_mesh/v2x/ossm-create-mesh.adoc#ossm-create-mesh[Adding projects to the Service Mesh member roll]
-endif::openshift-dedicated[]
\ No newline at end of file
+endif::openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/virt/vm_networking/virt-dedicated-network-live-migration.adoc b/virt/vm_networking/virt-dedicated-network-live-migration.adoc
index c3f26618c29f..cf3a68ee37f6 100644
--- a/virt/vm_networking/virt-dedicated-network-live-migration.adoc
+++ b/virt/vm_networking/virt-dedicated-network-live-migration.adoc
@@ -6,12 +6,12 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can configure a dedicated xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Multus network] for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
-endif::openshift-rosa,openshift-dedicated[]
-ifdef::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can configure a dedicated xref:../../virt/vm_networking/virt-dedicated-network-live-migration.adoc#virt-configuring-secondary-network-vm-live-migration_virt-dedicated-network-live-migration[secondary network] for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-configuring-secondary-network-vm-live-migration.adoc[leveloffset=+1]
 
diff --git a/virt/vm_networking/virt-exposing-vm-with-service.adoc b/virt/vm_networking/virt-exposing-vm-with-service.adoc
index e6135b1cfd7b..33bd14ab75a8 100644
--- a/virt/vm_networking/virt-exposing-vm-with-service.adoc
+++ b/virt/vm_networking/virt-exposing-vm-with-service.adoc
@@ -11,21 +11,21 @@ You can expose a virtual machine within the cluster or outside the cluster by cr
 include::modules/virt-about-services.adoc[leveloffset=+1]
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../networking/networking_operators/metallb-operator/metallb-operator-install.adoc#metallb-operator-install_metallb-operator-install[Installing the MetalLB Operator]
 * xref:../../networking/metallb/metallb-configure-services.adoc#metallb-configure-services[Configuring services to use MetalLB]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-dual-stack-support-services.adoc[leveloffset=+1]
 
 include::modules/virt-creating-service-cli.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="additional-resources_creating-service-vm"]
 == Additional resources
 * xref:../../networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-nodeport.adoc#configuring-ingress-cluster-traffic-nodeport[Configuring ingress cluster traffic using a NodePort]
 * xref:../../networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-load-balancer.adoc#configuring-ingress-cluster-traffic-load-balancer[Configuring ingress cluster traffic using a load balancer]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/virt/vm_networking/virt-hot-plugging-network-interfaces.adoc b/virt/vm_networking/virt-hot-plugging-network-interfaces.adoc
index b81b34a3abf5..d4402f50c6ea 100644
--- a/virt/vm_networking/virt-hot-plugging-network-interfaces.adoc
+++ b/virt/vm_networking/virt-hot-plugging-network-interfaces.adoc
@@ -6,19 +6,19 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can add or remove secondary network interfaces without stopping your virtual machine (VM). {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can add or remove secondary network interfaces without stopping your virtual machine (VM). {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. {VirtProductName} also supports hot plugging secondary interfaces that use SR-IOV binding.
 
 [NOTE]
 ====
 Hot unplugging is not supported for Single Root I/O Virtualization (SR-IOV) interfaces.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 [id="virtio-limitations_virt-hot-plugging-network-interfaces"]
 == VirtIO limitations
@@ -40,9 +40,9 @@ include::modules/virt-hot-unplugging-bridge-network-interface-cli.adoc[leveloffs
 == Additional resources
 
 * xref:../../virt/getting_started/virt-using-the-cli-tools.adoc#installing-virtctl_virt-using-the-cli-tools[Installing virtctl]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#creating-linux-bridge-nad[Creating a Linux bridge network attachment definition]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#configuring-vm-network-interface[Connecting a virtual machine to a Linux bridge network]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-network-attachment_virt-connecting-vm-to-sriov[Creating an SR-IOV network attachment definition]
 * xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-attaching-vm-to-sriov-network_virt-connecting-vm-to-sriov[Connecting a virtual machine to an SR-IOV network]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/virt/vm_networking/virt-networking-overview.adoc b/virt/vm_networking/virt-networking-overview.adoc
index 564633ba2200..cd3a0d80166c 100644
--- a/virt/vm_networking/virt-networking-overview.adoc
+++ b/virt/vm_networking/virt-networking-overview.adoc
@@ -32,11 +32,16 @@ image:darkcircle-6.png[20,20] The machine network can be defined over a selected
 
 image:darkcircle-7.png[20,20] Secondary VM networks are typically bridged directly to a physical network, with or without VLAN encapsulation. It is also possible to create virtual overlay networks for secondary networks.
 
-[NOTE]
+[IMPORTANT]
 ====
 Connecting VMs directly to the underlay network is not supported on {product-rosa}.
 ====
 
+[NOTE]
+====
+Connecting VMs to user-defined networks with the `layer2` topology is recommended on public clouds.
+====
+
 image:darkcircle-8.png[20,20] Secondary VM networks can be defined on dedicated set of NICs, as shown in Figure 1, or they can use the machine network.
 
 include::modules/virt-networking-glossary.adoc[leveloffset=+1]
@@ -52,37 +57,46 @@ Each VM is connected by default to the default internal pod network. You can add
 xref:../../virt/vm_networking/virt-exposing-vm-with-service.adoc#virt-exposing-vm-with-service[Exposing a virtual machine as a service]::
 
 // Hiding from ROSA/OSD until OSDOCS-3691 is merged
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can expose a VM within the cluster or outside the cluster by creating a `Service` object. For on-premise clusters, you can configure a load balancing service by using the MetalLB Operator. You can xref:../../networking/networking_operators/metallb-operator/metallb-operator-install.adoc#metallb-operator-install_metallb-operator-install[install the MetalLB Operator] by using the {product-title} web console or the CLI.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 // Hiding from ROSA/OSD until OSDOCS-3691 is merged
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can expose a VM within the cluster or outside the cluster by creating a `Service` object.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
+[id="primary-udn-config"]
+== Configuring a primary user-defined network
+
+xref:../../virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc#virt-connecting-vm-to-primary-udn[Connecting a virtual machine to a primary user-defined network]::
+
+You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM’s primary interface. The primary user-defined network replaces the default pod network to connect pods and VMs in selected namespaces. Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN `layer2` network across multiple namespaces.
++
+User-defined networks with the `layer2` overlay topology are useful for VM workloads, and a good alternative to secondary networks in environments where physical network access is limited, such as the public cloud. The `layer2` topology enables seamless migration of VMs without the need for Network Address Translation (NAT), and also provides persistent IP addresses that are preserved between reboots and during live migration.
 
 [id="secondary-network-config"]
 == Configuring VM secondary network interfaces
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a virtual machine to a secondary network by using Linux bridge, SR-IOV and OVN-Kubernetes CNI plugins. You can list multiple secondary networks and interfaces in the VM specification. It is not required to specify the primary pod network in the VM specification when connecting to a secondary network interface.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a virtual machine to a secondary network by using an OVN-Kubernetes Container Network Interface (CNI) plugin. It is not required to specify the primary pod network in the VM specification when connecting to a secondary network interface.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
 xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Connecting a virtual machine to an OVN-Kubernetes secondary network]::
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a VM to an Open Virtual Network (OVN)-Kubernetes secondary network. {VirtProductName} supports the `layer2` topology for OVN-Kubernetes. 
 +
 --
 A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes CNI plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure. 
 --
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can connect a VM to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes. The `localnet` topology is the recommended way of exposing VMs to the underlying physical network, with or without VLAN encapsulation.
 +
 --
@@ -90,25 +104,25 @@ You can connect a VM to an OVN-Kubernetes secondary network. {VirtProductName} s
 
 * A `localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
 --
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Updated the xref to the correct ID
 
 To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
 
 . xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#creating-ovn-nad_virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 +
 [NOTE]
 ====
 For `localnet` topology, you must xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-localnet-switched-topology_configuring-additional-network-ovnk[configure an OVS bridge] by creating a `NodeNetworkConfigurationPolicy` object before creating the NAD.
 ====
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 . xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes secondary network] by adding the network details to the VM specification.
 
 // Hiding from ROSA/OSD as SR-IOV not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[Connecting a virtual machine to an SR-IOV network]::
 
 You can use Single Root I/O Virtualization (SR-IOV) network devices with additional networks on your {product-title} cluster installed on bare metal or Red Hat OpenStack Platform (RHOSP) infrastructure for applications that require high bandwidth or low latency.
@@ -120,11 +134,11 @@ You can connect a VM to an SR-IOV network by performing the following steps:
 . xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-configuring-device_virt-connecting-vm-to-sriov[Configure an SR-IOV network device] by creating a `SriovNetworkNodePolicy` CRD.
 . xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-network-attachment_virt-connecting-vm-to-sriov[Configure an SR-IOV network] by creating an `SriovNetwork` object.
 . xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-attaching-vm-to-sriov-network_virt-connecting-vm-to-sriov[Connect the VM to the SR-IOV network] by including the network details in the VM configuration.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
 // Hiding from ROSA/OSD as Linux Bridge not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Connecting a virtual machine to a Linux bridge network]::
 
 xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Install the Kubernetes NMState Operator] to configure Linux bridges, VLANs, and bonding for your secondary networks. The OVN-Kubernetes `localnet` topology is the recommended way of connecting a VM to the underlying physical network, but {VirtProductName} also supports Linux bridge networks.
@@ -139,47 +153,47 @@ You can create a Linux bridge network and attach a VM to the network by performi
 . xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-creating-linux-bridge-nncp_virt-connecting-vm-to-linux-bridge[Configure a Linux bridge network device] by creating a `NodeNetworkConfigurationPolicy` custom resource definition (CRD).
 . xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#creating-linux-bridge-nad[Configure a Linux bridge network] by creating a `NetworkAttachmentDefinition` CRD.
 . xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#configuring-vm-network-interface[Connect the VM to the Linux bridge network] by including the network details in the VM configuration.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
 //ROSA/OSD supports hot plugging with bridge binding and layer2 OVN-Kubernetes topology
 xref:../../virt/vm_networking/virt-hot-plugging-network-interfaces.adoc#virt-hot-plugging-network-interfaces[Hot plugging secondary network interfaces]::
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can add or remove secondary network interfaces without stopping your VM. {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. {VirtProductName} also supports hot plugging secondary interfaces that use the SR-IOV binding.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifdef::openshift-rosa,openshift-dedicated[]
+ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 You can add or remove secondary network interfaces without stopping your VM. {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the OVN-Kubernetes `layer2` topology.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
 // Hiding in ROSA/OSD as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/vm_networking/virt-using-dpdk-with-sriov.adoc#virt-using-dpdk-with-sriov[Using DPDK with SR-IOV]::
 
 The Data Plane Development Kit (DPDK) provides a set of libraries and drivers for fast packet processing. You can configure clusters and VMs to run DPDK workloads over SR-IOV networks.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/vm_networking/virt-dedicated-network-live-migration.adoc#virt-dedicated-network-live-migration[Configuring a dedicated network for live migration]::
 
 You can configure a dedicated xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Multus network] for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 // Hiding in ROSA/OSD as not supported Tech Preview
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 xref:../../virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc#virt-accessing-vm-secondary-network-fqdn[Accessing a virtual machine by using the cluster FQDN]::
 
 You can access a VM that is attached to a secondary network interface from outside the cluster by using its fully qualified domain name (FQDN).
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 xref:../../virt/vm_networking/virt-configuring-viewing-ips-for-vms.adoc#virt-configuring-viewing-ips-for-vms[Configuring and viewing IP addresses]::
 
 You can configure an IP address of a secondary network interface when you create a VM. The IP address is provisioned with cloud-init. You can view the IP address of a VM by using the {product-title} web console or the command line. The network information is collected by the QEMU guest agent.
 
 // Hiding from ROSA/OSD as Linux Bridge is not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [id="comparing-bridge-localnet"]
 === Comparing Linux bridge CNI and OVN-Kubernetes localnet topology
 
@@ -213,7 +227,7 @@ The following table provides a comparison of features available when using the L
 |Yes
 
 |===
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 
 [id="service-mesh-integration"]
diff --git a/virt/vm_networking/virt-using-dpdk-with-sriov.adoc b/virt/vm_networking/virt-using-dpdk-with-sriov.adoc
index 765db6abab94..740cf706f638 100644
--- a/virt/vm_networking/virt-using-dpdk-with-sriov.adoc
+++ b/virt/vm_networking/virt-using-dpdk-with-sriov.adoc
@@ -13,16 +13,16 @@ You can configure clusters and virtual machines (VMs) to run DPDK workloads over
 include::modules/virt-configuring-cluster-dpdk.adoc[leveloffset=+1]
 
 // Hiding until PR 65079 is merged
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources_configuring-cluster-dpdk"]
 .Additional resources
 * xref:../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager[Using CPU Manager and Topology Manager]
 * xref:../../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#configuring-huge-pages_huge-pages[Configuring huge pages]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 // Hiding as not supported
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * link:https://access.redhat.com/solutions/5688941[Creating a custom machine config pool]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/virt-removing-custom-mcp.adoc[leveloffset=+2]
 
diff --git a/web_console/creating-quick-start-tutorials.adoc b/web_console/creating-quick-start-tutorials.adoc
index d5fb364ff7de..bb652776b751 100644
--- a/web_console/creating-quick-start-tutorials.adoc
+++ b/web_console/creating-quick-start-tutorials.adoc
@@ -47,6 +47,6 @@ include::modules/quick-start-content-guidelines.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* For voice and tone requirements, refer to link:https://www.patternfly.org/v4/ux-writing/brand-voice-and-tone[PatternFly's brand voice and tone guidelines].
-* For other UX content guidance, refer to all areas of link:https://www.patternfly.org/v4/ux-writing/about[PatternFly's UX writing style guide].
+* For voice and tone requirements, refer to link:https://www.patternfly.org/ux-writing/brand-voice-and-tone[PatternFly's brand voice and tone guidelines].
+* For other UX content guidance, refer to all areas of link:https://www.patternfly.org/ux-writing/about[PatternFly's UX writing style guide].
 endif::openshift-rosa,openshift-dedicated[]
diff --git a/web_console/dynamic-plugin/content-security-policy.adoc b/web_console/dynamic-plugin/content-security-policy.adoc
new file mode 100644
index 000000000000..a5373dd458b4
--- /dev/null
+++ b/web_console/dynamic-plugin/content-security-policy.adoc
@@ -0,0 +1,25 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="content-security-policy_{context}"]
+= Content Security Policy (CSP)
+include::_attributes/common-attributes.adoc[]
+:context: content-security-policy
+
+toc::[]
+
+You can specify Content Security Policy (CSP) directives for your dynamic plugin using the `contentSecurityPolicy` field in the `ConsolePluginSpec` file. This field helps mitigate potential security risks by specifying which sources are allowed for fetching content like scripts, styles, images, and fonts. For dynamic plugins that require loading resources from external sources, defining custom CSP rules ensures secure integration into the {product-title} console.
+
+[IMPORTANT]
+====
+The console currently uses the `Content-Security-Policy-Report-Only` response header, so the browser will only warn about CSP violations in the web console and enforcement of CSP policies will be limited. CSP violations will be logged in the browser console, but the associated CSP directives will not be enforced. This feature is behind a `feature-gate`, so you will need to manually enable it.
+
+For more information, see xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling-features-console_nodes-cluster-enabling[Enabling feature sets using the web console].
+====
+
+include::modules/csp-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+[id="content-security-policy_additional-resources"]
+== Additional resources
+
+* link:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy[Content Security Policy (CSP)]
+
diff --git a/web_console/dynamic-plugin/deploy-plugin-cluster.adoc b/web_console/dynamic-plugin/deploy-plugin-cluster.adoc
index ba3c06392117..bac600e4623b 100644
--- a/web_console/dynamic-plugin/deploy-plugin-cluster.adoc
+++ b/web_console/dynamic-plugin/deploy-plugin-cluster.adoc
@@ -14,21 +14,21 @@ include::modules/deployment-plug-in-cluster.adoc[leveloffset=+1]
 
 include::modules/dynamic-plugin-proxy-service.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../security/certificate_types_descriptions/service-ca-certificates.adoc#service-ca-certificates[Service CA certificates]
 * xref:../../security/certificates/service-serving-certificate.adoc#service-serving-certificate[Securing service traffic using service serving certificate secrets]
 * xref:../../web_console/dynamic-plugin/dynamic-plugins-reference.adoc#dynamic-plugin-api_dynamic-plugins-reference[Dynamic plugin API]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
 include::modules/disabling-plug-in-browser.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 [id="dynamic-plugins_additional-resources"]
 == Additional resources
 
 * xref:../../applications/working_with_helm_charts/understanding-helm.adoc#understaning-helm[Understanding Helm]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/web_console/dynamic-plugin/dynamic-plugin-example.adoc b/web_console/dynamic-plugin/dynamic-plugin-example.adoc
index d8056a32d29b..67fa72d4b26b 100644
--- a/web_console/dynamic-plugin/dynamic-plugin-example.adoc
+++ b/web_console/dynamic-plugin/dynamic-plugin-example.adoc
@@ -8,4 +8,4 @@ toc::[]
 
 Before working through the example, verify that the plugin is working by following the steps in xref:../../web_console/dynamic-plugin/dynamic-plugins-get-started.adoc#dynamic-plugin-development_dynamic-plugins-get-started[Dynamic plugin development]
 
-include::modules/adding-tab-pods-page.adoc[leveloffset=+1]
+include::modules/adding-tab-pods-page.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/web_console/dynamic-plugin/dynamic-plugins-reference.adoc b/web_console/dynamic-plugin/dynamic-plugins-reference.adoc
index cb787ad51e43..236e4289973d 100644
--- a/web_console/dynamic-plugin/dynamic-plugins-reference.adoc
+++ b/web_console/dynamic-plugin/dynamic-plugins-reference.adoc
@@ -14,8 +14,8 @@ include::modules/dynamic-plugin-api.adoc[leveloffset=+1]
 
 include::modules/troubleshooting-dynamic-plugin.adoc[leveloffset=+1]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../security/certificates/service-serving-certificate.adoc#understanding-service-serving_service-serving-certificate[Understanding service serving certificates]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/web_console/web-console-overview.adoc b/web_console/web-console-overview.adoc
index 85e55e14cdb3..4689ca092ebd 100644
--- a/web_console/web-console-overview.adoc
+++ b/web_console/web-console-overview.adoc
@@ -17,24 +17,20 @@ include::modules/odc-accessing-perspectives.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../welcome/learn_more_about_openshift.adoc#cluster-administrator[Learn more about Cluster Administrator]
 * xref:../getting_started/openshift-overview.adoc#for-administrators[Overview of the *Administrator* perspective]
 * xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating and deploying applications on {product-title} using the *Developer* perspective]
 * xref:../applications/odc-viewing-application-composition-using-topology-view.adoc#odc-viewing-application-composition-using-topology-view[Viewing the applications in your project, verifying their deployment status, and interacting with them in the *Topology* view]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../web_console/using-dashboard-to-get-cluster-information.adoc#using-dashboard-to-get-cluster-info[Viewing cluster information]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../web_console/configuring-web-console.adoc#configuring-web-console[Configuring the web console]
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
 * xref:../web_console/customizing-the-web-console.adoc#customizing-web-console[Customizing the web console]
-endif::openshift-rosa,openshift-dedicated[]
-ifndef::openshift-rosa,openshift-dedicated[]
 * xref:../web_console/customizing-the-web-console.adoc#customizing-web-console[About the web console]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../web_console/web_terminal/odc-using-web-terminal.adoc#odc-using-web-terminal[Using the web terminal]
 * xref:../web_console/creating-quick-start-tutorials.adoc#creating-quick-start-tutorials[Creating quick start tutorials]
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 * xref:../web_console/disabling-web-console.adoc#disabling-web-console[Disabling the web console]
-endif::openshift-rosa,openshift-dedicated[]
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
diff --git a/web_console/web-console.adoc b/web_console/web-console.adoc
index 61fe552156a3..8704a20fa63b 100644
--- a/web_console/web-console.adoc
+++ b/web_console/web-console.adoc
@@ -24,8 +24,8 @@ include::modules/web-console-overview.adoc[leveloffset=+1]
 // include::modules/multi-cluster-about.adoc[leveloffset=+1]
 //include::modules/enabling-multi-cluster-console.adoc[leveloffset=+2]
 
-ifndef::openshift-rosa,openshift-dedicated[]
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 [role="_additional-resources"]
 .Additional resources
 * xref:../nodes/clusters/nodes-cluster-enabling-features.adoc[Enabling feature sets using the web console]
-endif::openshift-rosa,openshift-dedicated[]
\ No newline at end of file
+endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
\ No newline at end of file
diff --git a/welcome/about-hcp.adoc b/welcome/about-hcp.adoc
index 6a951953e583..4ac306b8f219 100644
--- a/welcome/about-hcp.adoc
+++ b/welcome/about-hcp.adoc
@@ -53,7 +53,7 @@ Use the following sections to find content to help you learn about and use {hcp-
 
 | xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture]
 | xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Installing {hcp-title}]
-| xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
+// | xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
 | xref:../support/index.adoc#support-overview[Getting Support]
 
 | link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
diff --git a/welcome/cloud-experts-rosa-hcp-sts-explained.adoc b/welcome/cloud-experts-rosa-hcp-sts-explained.adoc
index 4f8bb5f4e6d7..ed97cc7e4c06 100644
--- a/welcome/cloud-experts-rosa-hcp-sts-explained.adoc
+++ b/welcome/cloud-experts-rosa-hcp-sts-explained.adoc
@@ -42,17 +42,23 @@ Security features for AWS STS include:
 * *OpenID Connect (OIDC)* - A mechanism for cluster Operators to authenticate with AWS, assume the cluster roles through a trust policy, and obtain temporary credentials from AWS IAM STS to make the required API calls.
 * *Roles and policies* - The roles and policies used by {hcp-title} can be divided into account-wide roles and policies and Operator roles and policies.
 +
-The policies determine the allowed actions for each of the roles. See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources for ROSA clusters that use STS] for more details about the individual roles and policies and xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[ROSA IAM role resource] for more details about trust policies.
+The policies determine the allowed actions for each of the roles.
+ifdef::openshift-rosa[]
+See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources] for more details about the individual roles and policies. See xref:../rosa_planning/rosa-sts-ocm-role.adoc#rosa-sts-ocm-role[ROSA IAM role resource] for more details about trust policies.
+endif::openshift-rosa[]
+ifdef::openshift-rosa-hcp[]
+See xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-resources[About IAM resources] for more details about the individual roles and policies. See xref:../rosa_planning/rosa-hcp-prepare-iam-roles-resources.adoc#rosa-hcp-prepare-iam-roles-resources[Required IAM roles and resources] for more details on preparing these resources in your cluster.
+endif::openshift-rosa-hcp[]
 +
 --
 ** The account-wide roles are:
-+
-*** ManagedOpenShift-Installer-Role
-*** ManagedOpenShift-Worker-Role
-*** ManagedOpenShift-Support-Role
-+
+
+*** `<prefix>-HCP-ROSA-Worker-Role`
+*** `<prefix>-HCP-ROSA-Support-Role`
+*** `<prefix>-HCP-ROSA-Installer-Role`
+
 ** The account-wide AWS-managed policies are:
-+
+
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAInstallerPolicy.html[ROSAInstallerPolicy]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAWorkerInstancePolicy.html[ROSAWorkerInstancePolicy]
 *** link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy.html[ROSASRESupportPolicy]
@@ -73,7 +79,7 @@ Certain policies are used by the cluster Operator roles, listed below. The Opera
 ====
 +
 ** The Operator roles are:
-+
+
 *** <operator_role_prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials
 *** <operator_role_prefix>-openshift-cloud-network-config-controller-cloud-credentials
 *** <operator_role_prefix>-openshift-machine-api-aws-cloud-credentials
@@ -96,8 +102,7 @@ Deploying a {hcp-title} cluster follows the following steps:
 
 During the cluster creation process, the ROSA CLI creates the required JSON files for you and outputs the commands you need. If desired, the ROSA CLI can also run the commands for you.
 
-The ROSA CLI can automatically create the roles for you, or you can manually create them by using the `--mode manual` or `--mode auto` flags. For further details about deployment, see xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc#rosa-sts-creating-cluster-customizations_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations].
-//Change the above xref when we have HCP specific docs
+The ROSA CLI can automatically create the roles for you, or you can manually create them by using the `--mode manual` or `--mode auto` flags. For further details about deployment, see xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-cluster-using-customizations_rosa-sts-creating-a-cluster-with-customizations[Creating a cluster with customizations].
 
 [id="hcp-sts-process"]
 == {hcp-title} workflow
diff --git a/welcome/index.adoc b/welcome/index.adoc
index 830dbafe3784..b634948bafcc 100644
--- a/welcome/index.adoc
+++ b/welcome/index.adoc
@@ -28,6 +28,7 @@ To navigate the {product-title} {product-version} documentation, you can use one
 
 * Use the navigation bar to browse the documentation.
 * Select the task that interests you from xref:../welcome/learn_more_about_openshift.adoc#learn_more_about_openshift[Learn more about {product-title}].
+* {product-title} has a variety of layered offerings to add additional functionality and extend the capabilities of a cluster. For more information, see link:https://access.redhat.com/support/policy/updates/openshift_operators[{product-title} Operator Life Cycles]
 endif::openshift-rosa,openshift-dedicated,openshift-dpu,openshift-telco[]
 
 ifdef::openshift-dpu[]
diff --git a/welcome/learn_more_about_openshift.adoc b/welcome/learn_more_about_openshift.adoc
index cf6831324398..ad96ef77f8be 100644
--- a/welcome/learn_more_about_openshift.adoc
+++ b/welcome/learn_more_about_openshift.adoc
@@ -8,33 +8,45 @@ toc::[]
 
 Use the following sections to find content to help you learn about and better understand {product-title} functions:
 
+[id="support"]
+== Learning and support
+
+[options="header",cols="2*"]
+|===
+| Learn about {product-title} |Optional additional resources
+
+|link:https://www.openshift.com/learn/whats-new[What's new in {product-title}]
+|link:https://www.openshift.com/blog?hsLang=en-us[OpenShift blog]
+
+|link:https://access.redhat.com/support/policy/updates/openshift[{product-title} Life Cycle Policy]
+|link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} life cycle]
+
+|link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
+|link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]
+
+| xref:../support/getting-support.adoc#getting-support[Getting Support]
+| xref:../support/gathering-cluster-data.adoc#gathering-data[Gathering data about your cluster]
+
+|===
+
 [id="architecture"]
 == Architecture
 
-[options="header",cols="3*"]
+[options="header",cols="2*"]
 |===
-| Learn about {product-title} |Plan an {product-title} deployment |Optional additional resources
+| Learn about {product-title} |Optional additional resources
 
 | link:https://www.openshift.com/blog/enterprise-kubernetes-with-openshift-part-one?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Enterprise Kubernetes with OpenShift]
 | link:https://access.redhat.com/articles/4128421[Tested platforms]
-| link:https://www.openshift.com/blog?hsLang=en-us[OpenShift blog]
 
 | xref:../architecture/architecture.adoc#architecture[Architecture]
 | xref:../security/container_security/security-understanding.adoc#understanding-security[Security and compliance]
-| link:https://www.openshift.com/learn/whats-new[What's new in {product-title}]
 
-|
 | xref:../networking/understanding-networking.adoc#understanding-networking[Networking]
-| link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} life cycle]
+| xref:../networking/ovn_kubernetes_network_provider/ovn-kubernetes-architecture-assembly.adoc#ovn-kubernetes-architecture-con[OVN-Kubernetes architecture]
 
-|
 | xref:../backup_and_restore/index.adoc#backup-restore-overview[Backup and restore]
-|
-
-| link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
-|
-a|* xref:../support/getting-support.adoc#getting-support[Getting Support]
-* link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]
+| xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#scenario-2-restoring-cluster-state[Restoring to a previous cluster state]
 
 |===
 
@@ -50,7 +62,7 @@ Explore the following {product-title} installation tasks:
 | xref:../installing/overview/installing-preparing.adoc#installing-preparing[Selecting a cluster installation method and preparing it for users]
 
 | xref:../installing/overview/installing-fips.adoc#installing-fips-mode_installing-fips[Installing a cluster in FIPS mode]
-|
+| xref:../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#agent-installer-fips-compliance_preparing-to-install-with-agent-based-installer[About FIPS compliance]
 
 |===
 
@@ -61,8 +73,8 @@ Explore the following {product-title} installation tasks:
 |===
 | Learn about other installer tasks on {product-title} |Optional additional resources
 
-| xref:../installing/validation_and_troubleshooting/installing-troubleshooting.adoc#installing-troubleshooting[Check installation logs]
-|
+| xref:../installing/validation_and_troubleshooting/installing-troubleshooting.adoc#installing-troubleshooting[Troubleshooting installation issues]
+| xref:../installing/validation_and_troubleshooting/validating-an-installation.adoc#validating-an-installation[Validating an installation]
 
 | xref:../storage/persistent_storage/persistent-storage-ocs.adoc#red-hat-openshift-data-foundation[Install {rh-storage-first}]
 | xref:../machine_configuration/mco-coreos-layering.adoc#mco-coreos-layering[{op-system-first} image layering]
@@ -134,34 +146,34 @@ a|* xref:../machine_management/index.adoc#machine-api-overview_overview-of-machi
 | Manage xref:../machine_management/index.adoc#machine-mgmt-intro-managing-compute_overview-of-machine-management[compute] and xref:../machine_management/index.adoc#machine-mgmt-intro-managing-control-plane_overview-of-machine-management[control plane] machines with machine sets.
 |
 
-|xref:../machine_management/deploying-machine-health-checks.adoc#deploying-machine-health-checks[Deploying machine health checks]
-|
+| xref:../machine_management/deploying-machine-health-checks.adoc#deploying-machine-health-checks[Deploying machine health checks]
+| xref:../machine_management/control_plane_machine_management/cpmso-about.adoc#cpmso-about[About control plane machine sets]
 
-|xref:../machine_management/applying-autoscaling.adoc#applying-autoscaling[Applying autoscaling to an {product-title} cluster]
-|
+| xref:../machine_management/applying-autoscaling.adoc#applying-autoscaling[Applying autoscaling to an {product-title} cluster]
+| xref:../nodes/pods/nodes-pods-priority.adoc#nodes-pods-priority[Including pod priority in pod scheduling decisions]
 
 | xref:../registry/index.adoc#registry-overview[Manage container registries]
 | link:https://access.redhat.com/documentation/en-us/red_hat_quay/[Red Hat Quay]
 
 | xref:../authentication/understanding-authentication.adoc#understanding-authentication[Manage users and groups]
-|
+| xref:../authentication/impersonating-system-admin.adoc#impersonating-system-admin[Impersonating the system:admin user]
 
 | xref:../authentication/understanding-authentication.adoc#understanding-authentication[Manage authentication]
-| xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[multiple identity providers]
+| xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[Multiple identity providers]
 
-| Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates
-|
+| Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[Service] certificates
+| xref:../networking/network_security/network-policy-apis.adoc#network-policy-apis[Network security]
 
 | xref:../networking/understanding-networking.adoc#understanding-networking[Manage networking]
 a|* xref:../networking/networking_operators/cluster-network-operator.adoc#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator]
-* xref:../networking/multiple_networks/understanding-multiple-networks.adoc#understanding-multiple-networks[multiple network interfaces]
-* xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[network policy]
+* xref:../networking/multiple_networks/understanding-multiple-networks.adoc#understanding-multiple-networks[Multiple network interfaces]
+* xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[Network policy]
 
 | xref:../operators/understanding/olm-understanding-operatorhub.adoc#olm-understanding-operatorhub[Manage Operators]
-|
+| xref:../operators/user/olm-creating-apps-from-installed-operators.adoc#olm-creating-apps-from-installed-operators[Creating applications from installed Operators]
 
+| xref:../windows_containers/index.adoc#index[{productwinc} overview]
 | xref:../windows_containers/understanding-windows-container-workloads.adoc#understanding-windows-container-workloads_understanding-windows-container-workloads[Understanding Windows container workloads]
-|
 
 |===
 
@@ -178,17 +190,17 @@ a|* xref:../updating/updating_a_cluster/updating-cluster-web-console.adoc#updati
 * xref:../disconnected/updating/index.adoc#about-disconnected-updates[Using the OpenShift Update Service in a disconnected environment]
 
 | xref:../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-extending-api-with-crds[Use custom resource definitions (CRDs) to modify the cluster]
-a|* xref:../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-creating-custom-resources-definition_crd-extending-api-with-crds[create a CRD]
-* xref:../operators/understanding/crds/crd-managing-resources-from-crds.adoc#crd-managing-resources-from-crds[manage resources from CRDs]
+a|* xref:../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-creating-custom-resources-definition_crd-extending-api-with-crds[Create a CRD]
+* xref:../operators/understanding/crds/crd-managing-resources-from-crds.adoc#crd-managing-resources-from-crds[Manage resources from CRDs]
 
 | xref:../applications/quotas/quotas-setting-per-project.adoc#quotas-setting-per-project[Set resource quotas]
-| xref:../applications/quotas/quotas-setting-per-project.adoc#quotas-setting-per-project[set quotas]
+| xref:../applications/quotas/quotas-setting-per-project.adoc#quotas-setting-per-project[Set quotas]
 
 | xref:../applications/pruning-objects.adoc#pruning-objects[Prune and reclaim resources]
-|
+| xref:../cicd/builds/advanced-build-operations.adoc#builds-build-pruning-advanced-build-operations[Performing advanced builds]
 
 | xref:../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scale] and xref:../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[tune] clusters
-|
+| xref:../scalability_and_performance/index.adoc#index[{product-title} scalability and performance]
 
 |===
 
@@ -199,22 +211,21 @@ a|* xref:../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-cr
 |===
 |Learn about {product-title} |Optional additional resources
 
-| xref:../observability/logging/cluster-logging.adoc#cluster-logging[OpenShift Logging]
-|
+// | //xref :../observability/logging/cluster-logging.adoc#cluster-logging[OpenShift Logging]
+// |
 
+| xref:../observability/distr_tracing/distr-tracing-rn.adoc#distr-tracing-rn[Release notes for the {DTProductName}]
 | xref:../observability/distr_tracing/distr_tracing_arch/distr-tracing-architecture.adoc#distr-tracing-architecture[{jaegername}]
-|
 
 | xref:../observability/otel/otel-installing.adoc#install-otel[Red Hat build of OpenTelemetry]
-|
+| xref:../observability/otel/otel-config-multicluster.adoc#otel-config-multicluster[Gathering the observability data from multiple clusters]
 
 | xref:../observability/network_observability/network-observability-overview.adoc#network-observability-overview[About Network Observability]
 a|* xref:../observability/network_observability/metrics-alerts-dashboards.adoc#metrics-alerts-dashboards_metrics-alerts-dashboards[Using metrics with dashboards and alerts]
 * xref:../observability/network_observability/observing-network-traffic.adoc#network-observability-trafficflow_nw-observe-network-traffic[Obsserving the network traffic from the Traffic flows view]
 
-| xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
-a|* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[In-cluster monitoring]
-* xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring_about-remote-health-monitoring[Remote health monitoring]
+| xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
+a|* xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring_about-remote-health-monitoring[Remote health monitoring]
 * xref:../observability/power_monitoring/power-monitoring-overview.adoc#power-monitoring-overview[{PM-title-c} (Technology Preview)]
 
 |===
@@ -226,40 +237,31 @@ a|* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overvie
 |===
 |Learn about {product-title} |Optional additional resources
 
-| xref:../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Manage storage]
-|
-
-| xref:../storage/understanding-ephemeral-storage.adoc#understanding-ephemeral-storage[Storage]
-|
+| xref:../storage/index.adoc#storage-types[Storage types]
+a| * xref:../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Persistent storage]
+* xref:../storage/understanding-ephemeral-storage.adoc#understanding-ephemeral-storage[Ephemeral storage]
 
 |===
 
 [id="application_site_reliability_engineer"]
 == Application Site Reliability Engineer (App SRE)
 
-[options="header",cols="3*"]
+[options="header",cols="2*"]
 |===
-|Learn about {product-title} |Deploy and manage applications |Optional additional resources
+|Learn about {product-title} |Optional additional resources
 
-|
+| xref:../applications/index.adoc#building-applications-overview[Building applications overview]
 | xref:../applications/projects/working-with-projects.adoc#working-with-projects[Projects]
-| xref:../support/getting-support.adoc#getting-support[Getting Support]
 
-| xref:../architecture/architecture.adoc#architecture[Architecture]
 | xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Operators]
-| link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]
+| xref:../operators/operator-reference.adoc#cluster-operator-reference[Cluster Operator reference]
 
 |
-| xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
+// | xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
 | link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]
 
 |
 | link:https://www.openshift.com/blog/tag/logging[Blogs about logging]
-|
-
-|
-| xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring]
-|
 
 |===
 
@@ -303,20 +305,38 @@ a|* xref:../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-sched
 * xref:../machine_management/creating-infrastructure-machinesets.adoc#creating-infrastructure-machinesets[Creating infrastructure machine sets]
 |===
 
+[id="self-managed-hcp"]
+== {hcp-capital}
 
-//
-//[id="hosted-control-plane-activities"]
-//== Hosted control plane activities
-
-//[options="header",cols="2*"]
-// |===
-// |Learn about {hcp-capital} |Optional additional resources
-
-// | xref:../hosted_control_planes/index.adoc#hosted_control_planes[Hosted control planes overview]
-// | xref:../hosted_control_planes/index.adoc#hosted-control-planes-overview_hcp-overview[Introduction to hosted control planes]
-
-// | xref:../hosted_control_planes/hcp-getting-started.adoc#hcp-getting-started [Getting started with hosted control planes]
-// |
+[options="header",cols="2*"]
+|===
+|Learn about {hcp} |Optional additional resources
+
+| xref:../hosted_control_planes/index.adoc#hosted-control-planes-overview[Hosted control planes overview]
+a|
+xref:../hosted_control_planes/index.adoc#hosted-control-planes-version-support_hcp-overview[Versioning for {hcp}]
+
+| Preparing to deploy
+a| * xref:../hosted_control_planes/hcp-prepare/hcp-requirements.adoc#hcp-requirements[Requirements for {hcp}]
+* xref:../hosted_control_planes/hcp-prepare/hcp-sizing-guidance.adoc#hcp-sizing-guidance[Sizing guidance for {hcp}]
+* xref:../hosted_control_planes/hcp-prepare/hcp-override-resource-util.adoc#hcp-override-resource-util[Overriding resource utilization measurements]
+* xref:../hosted_control_planes/hcp-prepare/hcp-cli.adoc#hcp-cli[Installing the {hcp} command-line interface]
+* xref:../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-distribute-workloads[Distributing hosted cluster workloads]
+* xref:../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc#hcp-enable-disable[Enabling or disabling the {hcp} feature]
+
+| Deploying {hcp}
+a| * xref:../hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc#hcp-deploy-virt[Deploying {hcp} on {VirtProductName}]
+* xref:../hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc#hcp-deploy-aws[Deploying {hcp} on {aws-short}]
+* xref:../hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc#hcp-deploy-bm[Deploying {hcp} on bare metal]
+* xref:../hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc#hcp-deploy-non-bm[Deploying {hcp} on non-bare-metal agent machines]
+* xref:../hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc#hcp-deploy-ibmz[Deploying {hcp} on {ibm-z-title}]
+* xref:../hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc#hcp-deploy-ibm-power[Deploying {hcp} on {ibm-power-title}]
+
+| Deploying {hcp} in a disconnected environment
+a| * xref:../hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm.adoc#hcp-deploy-dc-bm[Deploying {hcp} on bare metal in a disconnected environment]
+* xref:../hosted_control_planes/hcp-disconnected/hcp-deploy-dc-virt.adoc#hcp-deploy-dc-virt[Deploying {hcp} on {VirtProductName} in a disconnected environment]
+
+| xref:../hosted_control_planes/hcp-troubleshooting.adoc#hcp-troubleshooting[Troubleshooting {hcp}]
+a| xref:../hosted_control_planes/hcp-troubleshooting.adoc#hosted-control-planes-troubleshooting_hcp-troubleshooting[Gathering information to troubleshoot {hcp}]
 
-// |===
-//
\ No newline at end of file
+|===
diff --git a/welcome/providing-feedback-on-red-hat-documentation.adoc b/welcome/providing-feedback-on-red-hat-documentation.adoc
new file mode 100644
index 000000000000..1c5c8614ae61
--- /dev/null
+++ b/welcome/providing-feedback-on-red-hat-documentation.adoc
@@ -0,0 +1,18 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="providing-feedback-on-red-hat-documentation"]
+= Providing feedback on {product-title} documentation
+include::_attributes/common-attributes.adoc[]
+:context: providing-feedback-on-red-hat-documentation
+
+toc::[]
+
+To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account.
+
+.Procedure
+
+. Click one of the following links:
+** To create a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Documentation_issue&issuetype=1&components=12367614&priority=10200&versions=12431396[Jira issue] for {product-title}
+** To create a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12323181&issuetype=1&priority=10200[Jira issue] for {VirtProductName}
+. Enter a brief description of the issue in the *Summary*.
+. Provide a detailed description of the issue or enhancement in the *Description*. Include a URL to where the issue occurs in the documentation.
+. Click *Create* to create the issue.
\ No newline at end of file
diff --git a/windows_containers/enabling-windows-container-workloads.adoc b/windows_containers/enabling-windows-container-workloads.adoc
index 8c235a406be6..e80d40ae9cfc 100644
--- a/windows_containers/enabling-windows-container-workloads.adoc
+++ b/windows_containers/enabling-windows-container-workloads.adoc
@@ -51,6 +51,8 @@ include::modules/installing-wmco-using-cli.adoc[leveloffset=+2]
 
 include::modules/configuring-secret-for-wmco.adoc[leveloffset=+1]
 
+include::modules/wmco-configure-debug-logging.adoc[leveloffset=+1]
+
 include::modules/wmco-cluster-wide-proxy.adoc[leveloffset=+1]
 
 .Additional resources
diff --git a/windows_containers/windows-node-upgrades.adoc b/windows_containers/windows-node-upgrades.adoc
index 9dedf9241029..d8b4b5d74675 100644
--- a/windows_containers/windows-node-upgrades.adoc
+++ b/windows_containers/windows-node-upgrades.adoc
@@ -1,13 +1,37 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="windows-node-upgrades"]
-= Windows node upgrades
+= Windows node updates
 include::_attributes/common-attributes.adoc[]
 :context: windows-node-upgrades
 
 toc::[]
 
-You can ensure your Windows nodes have the latest updates by upgrading the Windows Machine Config Operator (WMCO).
+You can ensure your Windows nodes have the latest updates by updating the Windows Machine Config Operator (WMCO).
+
+You can update the WMCO in any of the following scenarios:
+
+* Within the current version. for example, from <10.y.z> to <10.y.z+1>.
+* To a new, contiguous version. For example, from <10.y> to <10.y+1>.
+* From an EUS version to another EUS version by using a Control Plane Only update. For example, from <10.y> to <10.y+2>.
 
 include::modules/wmco-upgrades.adoc[leveloffset=+1]
 
-For more information on Operator upgrades using the Operator Lifecycle Manager (OLM), see xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators].
+[role="_additional-resources"]
+.Additional resources
+* xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators].
+
+include::modules/windows-upgrades-eus.adoc[leveloffset=+1]
+include::modules/wmco-upgrades-eus-using-web-console.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
+* xref:../windows_containers/enabling-windows-container-workloads.adoc#installing-wmco-using-web-console_enabling-windows-container-workloads[Installing the Windows Machine Config Operator using the web console]
+
+include::modules/wmco-upgrades-eus-using-cli.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operator-from-a-cluster-using-cli_olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster using the CLI]
+* xref:../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
+* xref:../windows_containers/enabling-windows-container-workloads.adoc#installing-wmco-using-cli_enabling-windows-container-workloads[Installing the Windows Machine Config Operator using the CLI]