openstack-k8s-operators · afaranha · Jun 3, 2026 · Feb 4, 2026 · Jun 10, 2026 · Jun 17, 2026
diff --git a/.github/workflows/docs.yaml b/.github/workflows/docs.yaml
@@ -17,14 +17,14 @@ jobs:
   build:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7
         with:
           # this fetches all branches. Needed because we need gh-pages branch for deploy to work
           fetch-depth: 0
-      - uses: actions/setup-python@v2
+      - uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
         with:
           python-version: '3.9'
-      - uses: ruby/setup-ruby@v1
+      - uses: ruby/setup-ruby@003a5c4d8d6321bd302e38f6f0ec593f77f06600 # v1
         with:
           ruby-version: '3.2'
 

diff --git a/.github/workflows/lint.yaml b/.github/workflows/lint.yaml
@@ -10,8 +10,8 @@ jobs:
   pre-commit:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v5
-      - uses: actions/setup-python@v6
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7
+      - uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
         with:
           python-version: '3.13'
-      - uses: pre-commit/action@v3.0.1
+      - uses: pre-commit/action@2c7b3805fd2a0fd8c1884dcaebf91fc102a13ecd # v3.0.1
diff --git a/.github/workflows/stale-pr.yml b/.github/workflows/stale-pr.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@v9
+      - uses: actions/stale@5bef64f19d7facfb25b37b414482c7164d639639 # v9
         with:
           stale-pr-message: |
             This PR is stale because it has been for over 15 days with no activity.

diff --git a/.github/workflows/sync_branches_with_ext_trigger.yml b/.github/workflows/sync_branches_with_ext_trigger.yml
@@ -6,7 +6,7 @@ on: # yamllint disable-line rule:truthy
 
 jobs:
   trigger-sync:
-    uses: openstack-k8s-operators/ci-framework/.github/workflows/sync_branches_reusable_workflow.yml@main
+    uses: openstack-k8s-operators/ci-framework/.github/workflows/sync_branches_reusable_workflow.yml@8b22a75f4fa1b75a18b718c79a7395eca5c530ee # main
     with:
       source-branch: ${{ github.event.client_payload.source-branch }}
       target-branch: ${{ github.event.client_payload.target-branch }}

diff --git a/docs_user/adoption-attributes.adoc b/docs_user/adoption-attributes.adoc
@@ -99,6 +99,11 @@ ifeval::["{build}" == "downstream"]
 :CephCluster: Red Hat Ceph Storage
 :CephVernum: 7
 
+
+// Ceph 9 IBM PDF paths - update these when Ceph 9 minor version changes
+:ceph9_pdf_path: SSEG27_9.9.1/out/91
+:ceph9_version: 9.9.1
+
 //Components and services
 
 //Identity service (keystone)

diff --git a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc b/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc
@@ -8,7 +8,7 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {key_manager} with HSM integration
 
 [role="_abstract"]
-Adopt the {key_manager_first_ref} from {OpenStackPreviousInstaller} to {rhos_long} when your source environment includes hardware security module (HSM) integration to preserve HSM functionality and maintain access to HSM-backed secrets. HSM provides enhanced security for cryptographic operations by storing encryption keys in dedicated hardware devices.
+Adopt the {key_manager_first_ref} with HSM integration to {rhos_long} to preserve HSM functionality and maintain access to HSM-backed secrets.
 
 For additional information about the {key_manager} before you start the adoption, see the following resources:
 

diff --git a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc b/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc
@@ -8,9 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {rhos_component_storage_file}
 
 [role="_abstract"]
-The {rhos_component_storage_file_first_ref} in {rhos_long} provides a self-service API to create and manage file shares. File shares (or "shares"), are built for concurrent read/write access from multiple clients. This makes the {rhos_component_storage_file} essential in cloud environments that require a ReadWriteMany persistent storage.
+The {rhos_component_storage_file_first_ref} provides a self-service API to create and manage file shares. File shares are built for concurrent read/write access from multiple clients, making the Shared File Systems service in cloud environments that require a ReadWriteMany persistent storage.
 
-File shares in {rhos_acro} require network access. Ensure that the networking in the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment matches the network plans for your new cloud after adoption. This ensures that tenant workloads remain connected to storage during the adoption process. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
+File shares in {rhos_acro} require network access. Ensure that network plans match the {rhos_prev_long} environment to maintain tenant connectivity during adoption. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
 
 Typically, storage and storage device management are separate networks. Shared File Systems services only need access to the storage device management network.
 For example, if you used a {CephCluster} cluster in the deployment, the "storage"

diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
@@ -9,10 +9,9 @@ ifdef::context[:parent-context: {context}]
 
 [role="_abstract"]
 For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes that are
-running {Ceph} {CephVernum} or later, you must migrate the daemons that are
-included in the {rhos_prev_long} control plane into the existing external Red
-Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
-the Compute nodes for an HCI environment or dedicated storage nodes.
+running {Ceph} {CephVernum} or later, migrate the daemons from the {rhos_prev_long} control plane into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The external RHEL nodes typically include the Compute nodes for an HCI environment or dedicated storage nodes.
 
 == Prerequisites
 Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.

diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Migrating {Ceph} RGW to external RHEL nodes
 
 [role="_abstract"]
-For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
+For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, migrate the Ceph Object Gateway (RGW) daemons from the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The RHEL nodes include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
 
 == Prerequisites
 

diff --git a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
@@ -8,8 +8,9 @@ ifdef::context[:parent-context: {context}]
 :context: migrating-ceph-mon
 
 [role="_abstract"]
-You must move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of target nodes. Target nodes are either existing {Ceph} nodes, or {OpenStackShort} Compute nodes if {Ceph} is
-deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. Additional Ceph Monitors are deployed to the target nodes, and they are promoted as `_admin` nodes that you can use to manage the {CephCluster} cluster and perform day 2 operations.
+Move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of existing {Ceph} nodes, or to a set of {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
+
+Additional Ceph Monitors are deployed to the target nodes and promoted as _admin nodes to manage the {CephCluster} cluster and perform day 2 operations.
 
 To migrate the Ceph Monitor daemons, you must perform the following high-level steps:
 

diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = {rhos_long_noacro} {rhos_curr_ver} adoption overview
 
 [role="_abstract"]
-Adoption is the process of migrating a {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver}, and then completing an in-place upgrade of the data plane. You can retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation. To ensure that you understand the entire adoption process and how to sufficiently prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
+Adoption is the process of migrating a {rhos_prev_long} {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver} and upgrading the data plane in-place. Retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation.
+
+To understand the adoption process and to prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
 
 [IMPORTANT]
 Read the whole adoption guide before you start

diff --git a/docs_user/modules/con_adopting-spine-leaf-networks.adoc b/docs_user/modules/con_adopting-spine-leaf-networks.adoc
@@ -4,9 +4,9 @@
 = Configuring spine-leaf networks for the {rhos_long_noacro} deployment
 
 [role="_abstract"]
-When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, like a Distributed Compute Node (DCN) architecture, you must each L2 network segment with a separate IP subnet and create create routed provider networks. Traffic between sites is routed at L3 through spine routers or similar network infrastructure.
+When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, such as a Distributed Compute Node (DCN) architecture, adopt each L2 network segment with a separate IP subnet and create routed provider networks.
 
-You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
+Traffic between sites is routed at L3 through spine routers or similar network infrastructure. You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
 
 [NOTE]
 ====

diff --git a/docs_user/modules/con_adoption-guidelines.adoc b/docs_user/modules/con_adoption-guidelines.adoc
@@ -4,7 +4,7 @@
 = Guidelines for planning the adoption
 
 [role="_abstract"]
-When planning to adopt a {rhos_long} {rhos_curr_ver} environment, consider the scope of the change. An adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, storage interfaces, and so on affect the adoption process and can cause changes in behavior during the adoption.
+Adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, and storage interfaces can affect the adoption process and change behavior.
 
 Review the following guidelines to adequately plan for the adoption and increase the chance that you complete the adoption successfully:
 

diff --git a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc
@@ -4,7 +4,7 @@
 = Guidelines for preparing the {rhos_component_storage_file} configuration
 
 [role="_abstract"]
-To deploy {rhos_component_storage_file_first_ref} on the control plane, you must copy the original configuration file from the {rhos_prev_long} {rhos_prev_ver} deployment. You must review the content in the file to make sure you are adopting the correct configuration for {rhos_long} {rhos_curr_ver}. Not all of the content needs to be brought into the new cloud environment.
+Copy the {rhos_component_storage_file_first_ref} configuration from {rhos_prev_long} {rhos_prev_ver}, and review it to ensure that you copy the correct configuration for {rhos_long} {rhos_curr_ver}.
 
 Review the following guidelines for preparing your {rhos_component_storage_file} configuration file for adoption:
 

diff --git a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc b/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc
@@ -4,9 +4,9 @@
 = Preventing configuration loss when using the `oc patch` command
 
 [role="_abstract"]
-When you use the `oc patch` command to modify a resource, the changes are applied directly to the live object in your OpenShift cluster. If you later edit the custom resource (CR) file for the resource and apply the updates by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
+When you use `oc patch` to modify a resource, the changes are applied directly to live objects in your OpenShift cluster. If you later apply updates to the custom resource (CR) file by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
 
-To prevent loss of configuration, you can use the `--patch-file` option to configure the patch and retain patch files. Alternatively, you can export your `openstackcontrolplane` CR after the patch is applied:
+To prevent configuration loss, use the `--patch-file` option or export your `openstackcontrolplane` CR after the patch is applied.
 
 ----
 $ oc get <resource_type> <resource_name> -o yaml > <filename>.yaml

diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc
@@ -4,7 +4,7 @@
 = Storage driver certification
 
 [role="_abstract"]
-Before you adopt your {rhos_prev_long} {rhos_prev_ver} deployment to a {rhos_long} {rhos_curr_ver} deployment, confirm that your deployed storage drivers are certified for use with {rhos_acro} {rhos_curr_ver}. For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the Red Hat Ecosystem Catalog.
+Confirm that your deployed storage drivers are certified for {rhos_acro} {rhos_curr_ver} before adoption. See the Red Hat Ecosystem Catalog for certified software.
 
 [role="_additional-resources"]
 .Additional resources

diff --git a/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc
@@ -4,7 +4,7 @@
 = Adopt the {block_storage} with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. You can deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
+Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters at different sites. Deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
 
 During adoption, the {block_storage} volume services that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {block_storage} running on {rhocp_long}, the data path remains local. Volume data continues to be stored in the {Ceph} cluster at each edge site. When you create a volume or clone a volume from a snapshot, the operation occurs entirely within the local {Ceph} cluster. This preserves data locality.
 

diff --git a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc
@@ -437,7 +437,7 @@ endif::[]
   nodeTemplate:
     ansibleSSHPrivateKeySecret: dataplane-adoption-secret
     ansible:
-      ansibleUser: root
+      ansibleUser: tripleo-admin
 ifeval::["{build}" == "downstream"]
       ansibleVarsFrom:
       - secretRef:
@@ -537,18 +537,18 @@ ifeval::["{build}" != "downstream"]
           # This is required for FIPS enabled until trunk.rdoproject.org
           # is not being served from a centos7 host, tracked by
           # https://issues.redhat.com/browse/RHOSZUUL-1517
-          dnf -y install crypto-policies
-          update-crypto-policies --set FIPS:NO-ENFORCE-EMS
-          ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream
-          dnf -y upgrade openstack-selinux
-          rm -f /run/virtlogd.pid
-          rm -rf repo-setup-main
+          sudo dnf -y install crypto-policies
+          sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS
+          sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream
+          sudo dnf -y upgrade openstack-selinux
+          sudo rm -f /run/virtlogd.pid
+          sudo rm -rf repo-setup-main
 endif::[]
 ifeval::["{build}" == "downstream"]
         edpm_bootstrap_command: |
           set -euxo pipefail
-          dnf -y upgrade openstack-selinux
-          rm -f /run/virtlogd.pid
+          sudo dnf -y upgrade openstack-selinux
+          sudo rm -f /run/virtlogd.pid
 endif::[]
 
         gather_facts: false
@@ -560,8 +560,8 @@ endif::[]
         edpm_ovs_packages:
         - openvswitch3.3
         edpm_default_mounts:
-          -  path: /dev/hugepages<size>
-             opts: pagesize=<size>
+          - path: /dev/hugepages<size>
+            opts: pagesize=<size>
             fstype: hugetlbfs
             group: hugetlbfs
   nodes:
@@ -572,6 +572,7 @@ done
 +
 * `${compute}.hostName` specifies the FQDN for the node if your deployment has a custom DNS Domain.
 * `${compute}.networks` specifies the network composition. The network composition must match the source cloud configuration to avoid data plane connectivity downtime. The `ctlplane` network must come first. The commands only retain IP addresses for the hosts on the `ctlplane` and `internalapi` networks. Repeat this step for other isolated networks, or update the resulting files manually.
+* `${compute}.ansible.ansibleHost` specifies the Ansible host for the Compute node. If you are not using DNS, use the value `${!ip}`.
 * `metadata.name:` specifies the node set names for each cell, for example, `openstack-cell1`, `openstack-cell2`. Only create node sets for cells that contain Compute nodes.
 * `spec.tlsEnabled` specifies whether TLS Everywhere is enabled. If it is enabled, change `tlsEnabled` to `true`.
 * `spec.services` specifies the services to be adopted. If you are not adopting telemetry services, omit it from the services list.

diff --git a/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc
@@ -4,7 +4,9 @@
 = Adopting Compute services with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-In a Distributed Compute Node (DCN) deployment where {image_service_first_ref} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {compute_service_first_ref} nodes at each site must be configured with the {Ceph} connection details and {image_service} endpoint for their local site. Because the {image_service} has a separate API endpoint at each site, each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
+Configure the edge {compute_service_first_ref} nodes at each site with the {Ceph} connection details and {image_service_first_ref} endpoint for their local site.
+
+In a Distributed Compute Node (DCN) deployment where {image_service} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {image_service} has a separate API endpoint at each site. Each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
 
 In a DCN deployment, all node sets belong to a single {compute_service} cell. The central site and each edge site are separate `OpenStackDataPlaneNodeSet` resources within that cell. The per-site `OpenStackDataPlaneService` resources deliver different {Ceph} and {image_service} configurations to each node set while sharing the same cell-level {compute_service} configuration.
 

diff --git a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc
@@ -4,7 +4,7 @@
 = Adopting the {image_service} that is deployed with a {block_storage} back end
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} that you deployed with a {block_storage_first_ref} back end in the {rhos_prev_long} ({OpenStackShort}) environment. The control plane `glanceAPI` instance is deployed with the following configuration. You use this configuration in the patch manifest that deploys the {image_service} with the block storage back end:
+Adopt the {image_service_first_ref} with a {block_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the block storage back end.
 
 ----
 ..