From 9cac77ca27a30677b05f3eed11755c79576e8ef1 Mon Sep 17 00:00:00 2001 From: Roberto Alfieri Date: Wed, 3 Jun 2026 08:36:07 +0200 Subject: [PATCH 01/20] ovn_adoption: fix scp with IPv6 addresses in cluster-to-standalone The scp command constructed from the SSH command by replacing "ssh" with "scp" does not account for IPv6 addresses. When the controller host is an IPv6 address (e.g. 2620:cf:cf:aaaa::70), scp interprets the colons as the host:path separator, causing it to connect to a bogus IPv4 address derived from the first octet. Fix by splitting the SSH command into the scp options and the host, then wrapping the host in square brackets for the scp remote path. This is compatible with both IPv4 and IPv6 addresses since brackets around an IPv4 address are valid in scp. Update both the test role and the user-facing documentation. Co-authored-by: Cursor --- docs_user/modules/proc_migrating-ovn-data.adoc | 10 +++++++--- .../ovn_adoption/tasks/cluster_to_standalone.yaml | 12 ++++++++---- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/docs_user/modules/proc_migrating-ovn-data.adoc b/docs_user/modules/proc_migrating-ovn-data.adoc index 62cb1251b..12b4edd93 100644 --- a/docs_user/modules/proc_migrating-ovn-data.adoc +++ b/docs_user/modules/proc_migrating-ovn-data.adoc @@ -57,10 +57,14 @@ $CONTROLLER1_SSH sudo ovsdb-tool cluster-to-standalone /tmp/ovn_standalone_conve $CONTROLLER1_SSH sudo chmod 644 /tmp/ovn_standalone_conversion/ovn*.db # Create local directory and copy converted databases +# Note: brackets around the address are required so that IPv6 colons +# are not confused with the scp host:path separator. mkdir -p /tmp/ovn_adoption_dbs -CONTROLLER1_SCP=$(echo "$CONTROLLER1_SSH" | sed 's/^ssh/scp/') -${CONTROLLER1_SCP}:/tmp/ovn_standalone_conversion/ovnnb_db.db /tmp/ovn_adoption_dbs/ -${CONTROLLER1_SCP}:/tmp/ovn_standalone_conversion/ovnsb_db.db /tmp/ovn_adoption_dbs/ +CONTROLLER1_SCP=$(echo "$CONTROLLER1_SSH" | sed -e 's/^ssh/scp/' -e 's/ [^ ]*$//') +CONTROLLER1_USERHOST=$(echo "$CONTROLLER1_SSH" | awk '{print $NF}') +CONTROLLER1_SCP_DEST=$(echo "$CONTROLLER1_USERHOST" | sed 's/@\(.*\)/@[\1]/') +${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnnb_db.db /tmp/ovn_adoption_dbs/ +${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnsb_db.db /tmp/ovn_adoption_dbs/ # Cleanup on controller $CONTROLLER1_SSH sudo rm -rf /tmp/ovn_standalone_conversion diff --git a/tests/roles/ovn_adoption/tasks/cluster_to_standalone.yaml b/tests/roles/ovn_adoption/tasks/cluster_to_standalone.yaml index 266a721b0..050b0dd9c 100644 --- a/tests/roles/ovn_adoption/tasks/cluster_to_standalone.yaml +++ b/tests/roles/ovn_adoption/tasks/cluster_to_standalone.yaml @@ -23,14 +23,18 @@ # Create local temp directory mkdir -p /tmp/ovn_adoption_dbs - # Use scp like other parts of the codebase - CONTROLLER1_SCP=$(echo "$CONTROLLER1_SSH" | sed 's/^ssh/scp/') + # Build scp command from ssh command, wrapping the address in brackets + # so that IPv6 colons are not confused with the scp host:path separator. + # The last token is user@host; insert brackets around the host part only. + CONTROLLER1_SCP=$(echo "$CONTROLLER1_SSH" | sed -e 's/^ssh/scp/' -e 's/ [^ ]*$//') + CONTROLLER1_USERHOST=$(echo "$CONTROLLER1_SSH" | awk '{print $NF}') + CONTROLLER1_SCP_DEST=$(echo "$CONTROLLER1_USERHOST" | sed 's/@\(.*\)/@[\1]/') echo "Copying NB database to ansible controller..." - ${CONTROLLER1_SCP}:/tmp/ovn_standalone_conversion/ovnnb_db.db /tmp/ovn_adoption_dbs/ + ${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnnb_db.db /tmp/ovn_adoption_dbs/ echo "Copying SB database to ansible controller..." - ${CONTROLLER1_SCP}:/tmp/ovn_standalone_conversion/ovnsb_db.db /tmp/ovn_adoption_dbs/ + ${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnsb_db.db /tmp/ovn_adoption_dbs/ # Cleanup on controller $CONTROLLER1_SSH sudo rm -rf /tmp/ovn_standalone_conversion From 71d990bcedcea9c4d82da5ce35c423613bed91ba Mon Sep 17 00:00:00 2001 From: Jeremy Agee Date: Wed, 4 Feb 2026 10:38:37 -0500 Subject: [PATCH 02/20] keystone ldap adoption testing LDAP adoption testing will add a ldap domain to keystone. This ldap connection will be to the freeipa server setup for tlse environments on a multinode adoption job. Jira: https://issues.redhat.com/browse/OSPRH-6861 --- scenarios/hci.yaml | 1 + .../defaults/main.yaml | 11 ++++ .../development_environment/tasks/main.yaml | 49 +++++++++++++++ .../keystone_adoption/defaults/main.yaml | 51 ++++++++++++++++ tests/roles/keystone_adoption/tasks/main.yaml | 60 +++++++++++++++++++ 5 files changed, 172 insertions(+) diff --git a/scenarios/hci.yaml b/scenarios/hci.yaml index 7fea1cfc1..af6a070b4 100644 --- a/scenarios/hci.yaml +++ b/scenarios/hci.yaml @@ -24,6 +24,7 @@ undercloud: ctlplane_vip: 192.168.122.98 cloud_domain: "ooo.test" tlse: true +enable_keystone_ldap: true hostname_groups_map: # map ansible groups in the inventory to role hostname format for # 17.1 deployment diff --git a/tests/roles/development_environment/defaults/main.yaml b/tests/roles/development_environment/defaults/main.yaml index d77ea96ac..a71378103 100644 --- a/tests/roles/development_environment/defaults/main.yaml +++ b/tests/roles/development_environment/defaults/main.yaml @@ -1,3 +1,14 @@ +# IPA-related variables +ipa_hostname: "osp-free-ipa-0.ooo.test" +# Short hostname for SSH to the FreeIPA server +ipa_ssh_host: "{{ ipa_hostname.split('.')[0] }}" +# ci-framework test-operator default is ~/.ssh/id_cifw (e.g. /home/zuul/.ssh/id_cifw in Zuul) +controller_ssh_identity_file: "{{ cifmw_test_operator_controller_priv_key_file_path | default(edpm_privatekey_path) }}" +# OpenShift cluster DNS forwarding for the IPA/LDAP domain (TLS-E) +openshift_dns_forward_zone: "{{ ipa_hostname.split('.')[1:] | join('.') }}" +openshift_dns_forward_upstream: "192.168.111.30" +ipa_admin_password: "nomoresecrets" +ipa_user_password: "nomoresecrets" prelaunch_test_instance: true prelaunch_test_instance_scripts: - pre_launch.bash diff --git a/tests/roles/development_environment/tasks/main.yaml b/tests/roles/development_environment/tasks/main.yaml index 880a99a52..93abcda38 100644 --- a/tests/roles/development_environment/tasks/main.yaml +++ b/tests/roles/development_environment/tasks/main.yaml @@ -233,3 +233,52 @@ cmd: | {{ shell_header }} curl {{ octavia_vip_address.stdout }} + +- name: Add IPA domain to Keystone and create IPA users + when: enable_keystone_ldap | default(false) | bool + block: + - name: Configure OpenShift cluster DNS forwarding for IPA domain + ansible.builtin.shell: | + {{ shell_header }} + {{ oc_header }} + oc apply -f - < Date: Wed, 10 Jun 2026 11:28:26 +0100 Subject: [PATCH 03/20] Update ip vip in controllers to avoid conflict ip with vip undercloud Following the same config as hci scenario --- scenarios/uni04delta/vips_data.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scenarios/uni04delta/vips_data.yaml b/scenarios/uni04delta/vips_data.yaml index 8b1e1df27..3aff3a399 100644 --- a/scenarios/uni04delta/vips_data.yaml +++ b/scenarios/uni04delta/vips_data.yaml @@ -17,6 +17,6 @@ dns_name: overcloud - name: ctlplane_vip network: ctlplane - ip_address: 192.168.122.98 + ip_address: 192.168.122.99 subnet: ctlplane-subnet dns_name: overcloud From 984401313879820046a93fc90fd25182ad072935 Mon Sep 17 00:00:00 2001 From: Andre Aranha Date: Wed, 17 Jun 2026 12:34:03 +0200 Subject: [PATCH 04/20] Test OIDC after adoption Jira: https://redhat.atlassian.net/browse/OSPRH-19962 --- tests/roles/keystone_adoption/tasks/main.yaml | 44 +++++++++++++------ 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/tests/roles/keystone_adoption/tasks/main.yaml b/tests/roles/keystone_adoption/tasks/main.yaml index 49be3e34c..356c5e49b 100644 --- a/tests/roles/keystone_adoption/tasks/main.yaml +++ b/tests/roles/keystone_adoption/tasks/main.yaml @@ -154,24 +154,42 @@ fi register: adoption_token_result -- name: Verify that pre-adoption OIDC token still works +- name: Verify that OIDC federation still works when: - enable_federation | default(false) | bool - - before_adoption_oidc_token is defined - - before_adoption_oidc_token.stdout is defined - ansible.builtin.shell: - cmd: | - {{ shell_header }} - {{ oc_header }} - - alias openstack="oc exec -t openstackclient -- env -u OS_CLOUD - OS_AUTH_URL={{ auth_url }} OS_AUTH_TYPE=v3oidcaccesstoken OS_ACCESS_TOKEN={{ before_adoption_oidc_token.stdout }} openstack" - - ${BASH_ALIASES[openstack]} token issue -f json - register: adoption_oidc_token_result + block: + - name: Generate OIDC token after adoption + ansible.builtin.shell: | + {{ shell_header }} + {{ oc_header }} + + oc exec openstackclient -- bash -c "cat > /tmp/oidc_cloudrc" <<'EOF' + unset OS_CLOUD + export OS_CACERT=/home/cloud-admin/full-ca-list.crt + export OS_PROJECT_NAME="{{ cifmw_federation_project_name }}" + export OS_PROJECT_DOMAIN_NAME="{{ cifmw_federation_domain }}" + export OS_AUTH_URL="{{ cifmw_federation_keystone_url }}/v3" + export OS_IDENTITY_API_VERSION=3 + export OS_AUTH_PLUGIN=openid + export OS_AUTH_TYPE=v3oidcpassword + export OS_USERNAME="{{ cifmw_federation_keycloak_testuser1_username }}" + export OS_PASSWORD="{{ cifmw_federation_keycloak_testuser1_password }}" + export OS_IDENTITY_PROVIDER="{{ cifmw_federation_idp_name }}" + export OS_CLIENT_ID="{{ cifmw_federation_keycloak_client_id }}" + export OS_CLIENT_SECRET="{{ cifmw_federation_keycloak_client_secret }}" + export OS_OPENID_SCOPE="openid profile email" + export OS_PROTOCOL=openid + export OS_ACCESS_TOKEN_TYPE=access_token + export OS_DISCOVERY_ENDPOINT="{{ cifmw_federation_keycloak_url }}/auth/realms/{{ cifmw_federation_keycloak_realm }}/.well-known/openid-configuration" + EOF + + oc exec openstackclient -- bash -c "source /tmp/oidc_cloudrc && openstack token issue -f value -c id" + register: oidc_token + failed_when: oidc_token.rc != 0 or oidc_token.stdout == "" - name: Print credentials test token ansible.builtin.debug: - var: before_adoption_token + var: oidc_token - name: Verify that pre-adoption credential stills the same ansible.builtin.shell: | From ca28151605c34b2dad5a64bb0e991d6acabfdb89 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Tue, 23 Jun 2026 14:24:32 -0400 Subject: [PATCH 05/20] fixed linting error --- .../assembly_adopting-key-manager-service-with-hsm.adoc | 2 +- ...ssembly_adopting-the-shared-file-systems-service.adoc | 4 ++-- docs_user/assemblies/assembly_migrating-ceph-rbd.adoc | 7 +++---- docs_user/assemblies/assembly_migrating-ceph-rgw.adoc | 4 +++- .../assembly_migrating-mon-from-controller-nodes.adoc | 5 +++-- .../assemblies/assembly_rhoso-180-adoption-overview.adoc | 4 +++- docs_user/modules/con_adopting-spine-leaf-networks.adoc | 4 ++-- docs_user/modules/con_adoption-guidelines.adoc | 2 +- ...ng-the-shared-file-systems-service-configuration.adoc | 2 +- .../con_preventing-config-loss-when-using-oc-patch.adoc | 4 ++-- docs_user/modules/con_storage-driver-certification.adoc | 2 +- ..._adopting-block-storage-service-with-dcn-backend.adoc | 2 +- .../proc_adopting-compute-services-with-dcn-backend.adoc | 4 +++- ...dopting-image-service-with-block-storage-backend.adoc | 2 +- .../proc_adopting-image-service-with-dcn-backend.adoc | 4 +++- ...opting-image-service-with-object-storage-backend.adoc | 2 +- ..._adopting-key-manager-service-with-proteccio-hsm.adoc | 4 +++- docs_user/modules/proc_adopting-key-manager-service.adoc | 4 +++- ...oc_adopting-networker-services-to-the-data-plane.adoc | 2 +- docs_user/modules/proc_adopting-the-compute-service.adoc | 2 +- .../modules/proc_adopting-the-loadbalancer-service.adoc | 4 +++- ...figuring-control-plane-networking-for-spine-leaf.adoc | 2 +- ...onfiguring-networking-for-control-plane-services.adoc | 6 +++++- ...oc_deploying-the-bare-metal-provisioning-service.adoc | 2 +- docs_user/modules/proc_migrating-ceph-mds.adoc | 7 ++++--- .../proc_migrating-mgr-from-controller-nodes.adoc | 2 +- docs_user/modules/proc_migrating-the-rgw-backends.adoc | 5 ++++- .../modules/proc_reusing-existing-subnet-ranges.adoc | 2 +- .../modules/proc_updating-shiftstack-credentials.adoc | 2 +- docs_user/modules/ref_adoption-duration-and-impact.adoc | 4 +++- docs_user/modules/ref_ceph-daemon-cardinality.adoc | 9 ++++++--- 31 files changed, 69 insertions(+), 42 deletions(-) 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 index 41a147a0e..feafa9145 100644 --- 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 index 1b4c66e2d..1908d406b 100644 --- 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 index 4c1edb8fa..6d5790e1e 100644 --- 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 index 88b6f8179..8c469184c 100644 --- 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 index a9ff70c83..d63c4962c 100644 --- 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 index 0346244d5..cd34fab09 100644 --- 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 index 12956dfd0..dfbdbcfc2 100644 --- 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 index 9c4a10b12..85f45bd4c 100644 --- 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 index 5fb0ac08f..474a29d13 100644 --- a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc +++ b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc @@ -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 index c9e7f6028..ec66b4792 100644 --- 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 `, 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 `, 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 -o yaml > .yaml diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc index c526210a8..e3ba5e5da 100644 --- 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 index bc8e9d2bd..eb9fd6724 100644 --- 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-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc index a599a8d44..840c8ee86 100644 --- 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 index 7ae6c3e4b..883989c56 100644 --- 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. ---- .. diff --git a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc index d74c899db..d6b94bb2f 100644 --- a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc @@ -4,7 +4,9 @@ = Adopting the {image_service} with multiple {Ceph} back ends (DCN) [role="_abstract"] -Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster. +Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters that provide storage at different sites. + +This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster. During adoption, the {image_service} instances 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 {image_service} running on {rhocp_long}, the data path remains local. Image data continues to be stored in the {Ceph} cluster at each edge site. When you create a virtual machine or volume from an image, the operation occurs at the local {Ceph} cluster. This architecture uses {Ceph} shallow copies (copy-on-write clones) to enable fast boot times without transferring image data across the WAN. diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc index 4d26ae245..53a141d1a 100644 --- a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc @@ -4,7 +4,7 @@ = Adopting the {image_service} that is deployed with a {object_storage} back end [role="_abstract"] -Adopt the {image_service_first_ref} that you deployed with an {object_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 object storage back end: +Adopt the {image_service_first_ref} with an {object_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 object storage back end. ---- .. diff --git a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc index e35a26ac8..da5b3ccec 100644 --- a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc +++ b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc @@ -4,7 +4,9 @@ = Adopting the {key_manager} with Proteccio HSM integration [role="_abstract"] -To adopt the {key_manager_first_ref} with Proteccio hardware security module (HSM) integration, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets. You configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends. +Adopt the {key_manager_first_ref} with Proteccio HSM by patching the `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends. + +The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets. The {key_manager} Proteccio HSM adoption is complete if you see the following results: diff --git a/docs_user/modules/proc_adopting-key-manager-service.adoc b/docs_user/modules/proc_adopting-key-manager-service.adoc index 4b9aff482..097b78072 100644 --- a/docs_user/modules/proc_adopting-key-manager-service.adoc +++ b/docs_user/modules/proc_adopting-key-manager-service.adoc @@ -4,7 +4,9 @@ = Adopting the {key_manager} [role="_abstract"] -To adopt the {key_manager_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. You configure the {key_manager} to use the `simple_crypto` back end. +Adopt the {key_manager_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use the `simple_crypto` back end. + +The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. The {key_manager} adoption is complete if you see the following results: diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc index c223178eb..770838cb5 100644 --- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc +++ b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc @@ -4,7 +4,7 @@ = Adopting Networker services to the {rhos_acro} data plane [role="_abstract"] -Adopt the Networker services in your existing {rhos_prev_long} deployment to the {rhos_long} data plane. The Networker services could be running on Controller nodes or dedicated Networker nodes. You decide which services you want to run on the Networker nodes, and create a separate `OpenStackDataPlaneNodeSet` custom resource (CR) for the Networker nodes. +Adopt Networker services to the {rhos_long} data plane by creating a `OpenStackDataPlaneNodeSet` custom resource (CR) that includes the services to run on the Networker nodes. The Networker services could be running on Controller nodes or dedicated Networker nodes. [TIP] ==== diff --git a/docs_user/modules/proc_adopting-the-compute-service.adoc b/docs_user/modules/proc_adopting-the-compute-service.adoc index b6008d3cf..fc92c24bc 100644 --- a/docs_user/modules/proc_adopting-the-compute-service.adoc +++ b/docs_user/modules/proc_adopting-the-compute-service.adoc @@ -4,7 +4,7 @@ = Adopting the {compute_service} [role="_abstract"] -To adopt the {compute_service_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. The following procedure describes a single-cell setup. +Adopt the {compute_service_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}. This procedure describes a single-cell setup. //[NOTE] //The following example scenario describes a single-cell setup. Real diff --git a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc b/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc index f995d74d7..5be427b8b 100644 --- a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc +++ b/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc @@ -4,7 +4,9 @@ = Adopting the {loadbalancer_service} [role="_abstract"] -To adopt the {loadbalancer_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. After completing the data plane adoption, you must trigger a failover of existing load balancers to upgrade their amphora virtual machines to use the new image and to establish connectivity with the new control plane. +Adopt the {loadbalancer_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}. + +After data plane adoption, trigger a failover of existing load balancers to upgrade amphora virtual machines to use the new image and to establish connectivity with the new control plane. .Procedure diff --git a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc b/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc index 4ba45bd6a..2e2c270ea 100644 --- a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc +++ b/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc @@ -4,7 +4,7 @@ = Configuring control plane networking for spine-leaf topologies [role="_abstract"] -If you are adopting a spine-leaf or Distributed Compute Node (DCN) deployment, update the control plane networking for communication across sites. Add subnets for remote sites to your existing `NetConfig` custom resource (CR) and update `NetworkAttachmentDefinition` CRs with routes to enable connectivity between the central control plane and remote sites. +Adopt a spine-leaf or Distributed Compute Node (DCN) deployment by updating the control plane networking for communication across sites. Add subnets for remote sites to `NetConfig` custom resources (CR) and add routes to `NetworkAttachmentDefinition` CRs to enable inter-site connectivity. .Prerequisites diff --git a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc index 1447adeff..34a3bb692 100644 --- a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc +++ b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc @@ -4,7 +4,11 @@ = Configuring isolated networks on control plane services [role="_abstract"] -After the NMState operator creates the desired hypervisor network configuration for isolated networks, you must configure the {rhos_prev_long} ({OpenStackShort}) services to use the configured interfaces. You define a `NetworkAttachmentDefinition` custom resource (CR) for each isolated network. In some clusters, these CRs are managed by the Cluster Network Operator, in which case you use `Network` CRs instead. For more information, see +After the NMState operator creates the required hypervisor network configuration for isolated networks, configure {rhos_prev_long} services to use isolated network interfaces by defining `NetworkAttachmentDefinition` CRs for each network. + +In clusters managed by Cluster Network Operator, use `Network` CRs instead. + +For more information, see link:{defaultOCPURL}/networking/cluster-network-operator#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] in _Networking_. .Procedure diff --git a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc index b1b33da6c..ca4520678 100644 --- a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc +++ b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc @@ -4,7 +4,7 @@ = Deploying the {bare_metal} [role="_abstract"] -To deploy the {bare_metal_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) that has the {bare_metal} disabled. The `ironic-operator` applies the configuration and starts the Bare Metal Provisioning services. After the services are running, the {bare_metal} automatically begins polling the power state of the bare-metal nodes that it manages. +Deploy the {bare_metal_first_ref} by patching the `OpenStackControlPlane` CR with the {bare_metal} disabled. The `ironic-operator` applies the configuration and starts the Bare Metal Provisioning services. The {bare_metal} then automatically polls the power state of the bare-metal nodes. [NOTE] By default, {rhos_acro} versions {rhos_curr_ver} and later of the {bare_metal} include a new multitenant aware role-based access control (RBAC) model. As a result, bare-metal nodes might be missing when you run the `openstack baremetal node list` command after you adopt the {bare_metal}. Your nodes are not deleted. Due to the increased access restrictions in the RBAC model, you must identify which project owns the missing bare-metal nodes and set the `owner` field on each missing bare-metal node. diff --git a/docs_user/modules/proc_migrating-ceph-mds.adoc b/docs_user/modules/proc_migrating-ceph-mds.adoc index 6c7e90c99..cfcfab109 100644 --- a/docs_user/modules/proc_migrating-ceph-mds.adoc +++ b/docs_user/modules/proc_migrating-ceph-mds.adoc @@ -4,12 +4,13 @@ = Migrating {Ceph} MDS to new nodes within the existing cluster [role="_abstract"] -You can migrate the MDS daemon when {rhos_component_storage_file_first_ref}, deployed with either a cephfs-native or ceph-nfs back end, is part of the overcloud deployment. The MDS migration is performed by `cephadm`, and you move the daemons placement from a hosts-based approach to a label-based approach. +Migrate the MDS daemon from a hosts-based approach to a label-based approach. The Shared File Systems service (manila) must be deployed with either a cephfs-native or ceph-nfs back end. The MDS migration is performed by `cephadm`. + ifeval::["{build}" != "upstream"] -This ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command. You can also have a general view of how the daemons are co-located within a given host, as described in the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. +The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command. You can also have a general view of how the daemons are co-located within a given host, as described in the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. endif::[] ifeval::["{build}" != "downstream"] -This ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command, and have a general view of how the daemons are co-located within a given host. +The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command, and have a general view of how the daemons are co-located within a given host. endif::[] .Prerequisites diff --git a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc b/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc index 490d2002b..79a73d61f 100644 --- a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc +++ b/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc @@ -4,7 +4,7 @@ = Migrating Ceph Manager daemons to {Ceph} nodes [role="_abstract"] -You must migrate your Ceph Manager 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. +Migrate Ceph Manager daemons from {rhos_prev_long} Controller nodes to a set of existing {Ceph} nodes, or Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. [NOTE] The following procedure uses `cephadm` and the Ceph Orchestrator to drive the Ceph Manager migration, and the Ceph spec to modify the placement and reschedule the Ceph Manager daemons. Ceph Manager is run in an active/passive state. It also provides many modules, including the Ceph Orchestrator. Every potential module, such as the Ceph Dashboard, that is provided by `ceph-mgr` is implicitly migrated with Ceph Manager. diff --git a/docs_user/modules/proc_migrating-the-rgw-backends.adoc b/docs_user/modules/proc_migrating-the-rgw-backends.adoc index 80a1a9983..558278dd8 100644 --- a/docs_user/modules/proc_migrating-the-rgw-backends.adoc +++ b/docs_user/modules/proc_migrating-the-rgw-backends.adoc @@ -4,7 +4,10 @@ = Migrating the {Ceph} RGW back ends [role="_abstract"] -You must migrate your Ceph Object Gateway (RGW) back ends from your Controller nodes to your {Ceph} nodes. To ensure that you distribute the correct amount of services to your available nodes, you use `cephadm` labels to refer to a group of nodes where a given daemon type is deployed. For more information about the cardinality diagram, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality]. +Migrate Ceph Object Gateway (RGW) back ends from Controller nodes to {Ceph} nodes. To distribute the correct amount of services to your available nodes, use `cephadm` labels to refer to a group of nodes where a given daemon type is deployed. + +For more information about the cardinality diagram, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality]. + The following procedure assumes that you have three target nodes, `cephstorage-0`, `cephstorage-1`, `cephstorage-2`. .Procedure diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc index 65c20cd2b..f05803a41 100644 --- a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc +++ b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc @@ -4,7 +4,7 @@ = Reusing existing subnet ranges [role="_abstract"] -You can reuse existing subnet ranges if they have enough IP addresses to allocate to the new control plane services. You configure the new control plane services to use the same subnet as you used in the {rhos_prev_long} ({OpenStackShort}) environment, and configure the allocation pools that are used by the new services to exclude IP addresses that are already allocated to existing cluster nodes. By reusing existing subnets, you avoid additional link local route configuration between the existing and new subnets. +Configure new control plane services to reuse the subnets from the {rhos_prev_long} ({OpenStackShort}) environment, and to exclude IP addresses that are already allocated to existing cluster nodes. This avoids additional link local route configuration between the existing and new subnets. ifeval::["{build_variant}" != "ospdo"] If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges. diff --git a/docs_user/modules/proc_updating-shiftstack-credentials.adoc b/docs_user/modules/proc_updating-shiftstack-credentials.adoc index c6075239a..a4591859e 100644 --- a/docs_user/modules/proc_updating-shiftstack-credentials.adoc +++ b/docs_user/modules/proc_updating-shiftstack-credentials.adoc @@ -4,7 +4,7 @@ = Updating {OpenShiftShort} on {OpenStackShort} credentials and recovering the image-registry operator [role="_abstract"] -After {rhos_long} adoption, any {rhocp_long} clusters that were deployed on {rhos_prev_long} ({OpenStackShort}) 17.1 with installer-provisioned infrastructure still reference the {OpenStackPreviousInstaller} keystone endpoint in their cloud credentials. To authenticate with keystone and avoid timeouts, update the credentials and image-registry operator. +After adoption, update {rhocp_long} clusters with installer-provisioned infrastructure to reference the new keystone endpoint in the cloud credentials instead of the {OpenStackPreviousInstaller} endpoint. This facilitates authentication with keystone and avoids timeouts. [IMPORTANT] Run all commands against the guest {OpenShiftShort} cluster that is running on {OpenStackShort} VMs, not the underlying {rhos_acro} host cluster. diff --git a/docs_user/modules/ref_adoption-duration-and-impact.adoc b/docs_user/modules/ref_adoption-duration-and-impact.adoc index aa576e3bd..25b2ea330 100644 --- a/docs_user/modules/ref_adoption-duration-and-impact.adoc +++ b/docs_user/modules/ref_adoption-duration-and-impact.adoc @@ -4,7 +4,9 @@ = Adoption duration and impact [role="_abstract"] -The durations in the following table were recorded in a test environment that consisted of 228 Compute nodes and 3 Networker nodes. To accurately estimate the adoption duration for each task, perform these procedures in a test environment with hardware that is similar to your production environment. Ensure that you set up the {rhocp_long} environment and install the Operators before testing. +The durations in the following table were recorded in a test environment that consisted of 228 Compute nodes and 3 Networker nodes. To accurately estimate the duration for each task, perform these procedures in a test environment with similar hardware to your production environment. + +Set up the {rhocp_long} environment and install the Operators before testing. [IMPORTANT] Durations can vary significantly based on the content of your environment, for example, the size of your service databases or the number of services. The durations represent raw execution time. They do not include human operator activity. diff --git a/docs_user/modules/ref_ceph-daemon-cardinality.adoc b/docs_user/modules/ref_ceph-daemon-cardinality.adoc index 391bc0812..0a9aae3b6 100644 --- a/docs_user/modules/ref_ceph-daemon-cardinality.adoc +++ b/docs_user/modules/ref_ceph-daemon-cardinality.adoc @@ -4,12 +4,15 @@ = {Ceph} daemon cardinality [role="_abstract"] -{Ceph} {CephVernum} and later applies strict constraints in the way daemons can be colocated within the same node. +{Ceph} {CephVernum} and later applies strict constraints in the way daemons can be colocated within the same node. Your topology depends on the available hardware and the amount of Red Hat Ceph Storage services in the Controller nodes that you retire. + +The amount of services that you can migrate depends on the amount of available nodes in the cluster. + +The following diagrams show the distribution of Red Hat Ceph Storage daemons on Red Hat Ceph Storage nodes where at least 3 nodes are required. + ifeval::["{build}" != "upstream"] For more information, see the Red Hat Knowledgebase article link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. endif::[] -Your topology depends on the available hardware and the amount of {Ceph} services in the Controller nodes that you retire. -The amount of services that you can migrate depends on the amount of available nodes in the cluster. The following diagrams show the distribution of {Ceph} daemons on {Ceph} nodes where at least 3 nodes are required. * The following scenario includes only RGW and RBD, without the {Ceph} dashboard: + From 167d2aca62a542b488e4d17d9c507545dbd6f228 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Thu, 11 Jun 2026 14:44:58 -0400 Subject: [PATCH 06/20] fixed variable description --- .../proc_adopting-compute-services-to-the-data-plane.adoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) 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 index e3857dd5a..ed3e9a95a 100644 --- 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 @@ -560,8 +560,8 @@ endif::[] edpm_ovs_packages: - openvswitch3.3 edpm_default_mounts: - - path: /dev/hugepages - opts: pagesize= + - path: /dev/hugepages + opts: pagesize= 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. From 9bffc906026c96a2a97b69eff2704828efb2ef0b Mon Sep 17 00:00:00 2001 From: Renjing Xiao Date: Fri, 26 Jun 2026 13:36:47 +0100 Subject: [PATCH 07/20] Update uni07eta adoption config MTU to 9000 Update uni07eta adoption scenario for MTU 9000 and external network change. All network MTUs set to 9000 to match greenfield. External network changed from VLAN 218 to VLAN 99 to match greenfield, with ospbr-218 handling the VLAN 218 provider network. Related-Issue: #OSPRH-28563 Assisted-by: Claude Opus 4.6 Signed-off-by: Renjing Xiao --- scenarios/uni07eta/config_download.yaml | 6 +++--- scenarios/uni07eta/network_data.yaml.j2 | 16 ++++++++-------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/scenarios/uni07eta/config_download.yaml b/scenarios/uni07eta/config_download.yaml index 71a58cc1a..380ff7606 100644 --- a/scenarios/uni07eta/config_download.yaml +++ b/scenarios/uni07eta/config_download.yaml @@ -50,7 +50,7 @@ parameter_defaults: nova::compute::libvirt::virt_type: qemu ExtraConfig: neutron::notification_driver: 'noop' - neutron::plugins::ml2::path_mtu: 1400 + neutron::plugins::ml2::path_mtu: 9000 neutron::plugins::ml2::ovn::ovn_router_indirect_snat: true BarbicanSimpleCryptoGlobalDefault: true Debug: true @@ -59,7 +59,7 @@ parameter_defaults: ControllerCount: 3 ComputeCount: 2 NetworkerCount: 3 - NeutronGlobalPhysnetMtu: 1400 + NeutronGlobalPhysnetMtu: 9000 CinderLVMLoopDeviceSize: 20480 CloudName: overcloud.example.com CloudNameInternal: overcloud.internalapi.example.com @@ -82,7 +82,7 @@ parameter_defaults: CtlplaneNetworkAttributes: network: dns_domain: example.com - mtu: 1500 + mtu: 9000 name: ctlplane tags: - 192.168.122.0/24 diff --git a/scenarios/uni07eta/network_data.yaml.j2 b/scenarios/uni07eta/network_data.yaml.j2 index 675aa1df3..fc24a8d37 100644 --- a/scenarios/uni07eta/network_data.yaml.j2 +++ b/scenarios/uni07eta/network_data.yaml.j2 @@ -1,6 +1,6 @@ --- - name: Storage - mtu: 1500 + mtu: 9000 vip: true name_lower: storage dns_domain: storage.{{ cloud_domain }}. @@ -12,7 +12,7 @@ allocation_pools: [{'start': '172.18.0.120', 'end': '172.18.0.250'}] - name: InternalApi - mtu: 1500 + mtu: 9000 vip: true name_lower: internal_api dns_domain: internal-api.{{ cloud_domain }}. @@ -24,7 +24,7 @@ allocation_pools: [{'start': '172.17.0.120', 'end': '172.17.0.250'}] - name: Tenant - mtu: 1500 + mtu: 9000 vip: false # Tenant network does not use VIPs name_lower: tenant dns_domain: tenant.{{ cloud_domain }}. @@ -36,7 +36,7 @@ allocation_pools: [{'start': '172.19.0.120', 'end': '172.19.0.250'}] - name: Octavia - mtu: 1500 + mtu: 9000 vip: false name_lower: octavia dns_domain: octavia.{{ cloud_domain }}. @@ -48,13 +48,13 @@ end: 172.23.0.250 - name: External - mtu: 1500 + mtu: 9000 vip: true name_lower: external dns_domain: external.{{ cloud_domain }}. service_net_map_replace: external subnets: external_subnet: - vlan: 218 - ip_subnet: '172.38.0.0/24' - allocation_pools: [{'start': '172.38.0.50', 'end': '172.38.0.80'}] + vlan: 99 + ip_subnet: '192.168.32.0/20' + allocation_pools: [{'start': '192.168.32.50', 'end': '192.168.32.80'}] From e045c16593abdf48e9455482207cb777f59e0f44 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miko=C5=82aj=20Ciecierski?= Date: Fri, 26 Jun 2026 15:55:54 +0200 Subject: [PATCH 08/20] Remove unused undercloud ctlplane_vip from scenario files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The undercloud ctlplane_vip was set in scenario files but never used by any service endpoint — they all use ctlplane_ip instead. The consumer in ci-framework's adoption_osp_deploy role has been removed in openstack-k8s-operators/ci-framework#4019. This removes the now-unnecessary ctlplane_vip key from the undercloud section in all 12 scenario files. The overcloud VIPs in vips_data.yaml files are unrelated and remain untouched. Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/4019 Related-Issue: #OSPRH-17418 Co-authored-by: Cursor --- scenarios/bgp-l3-xl.yaml | 1 - scenarios/dcn_nostorage.yaml | 1 - scenarios/dcn_storage.yaml | 1 - scenarios/hci.yaml | 1 - scenarios/uni01alpha.yaml | 1 - scenarios/uni02beta.yaml | 1 - scenarios/uni04delta-ipv6.yaml | 1 - scenarios/uni04delta.yaml | 1 - scenarios/uni05epsilon.yaml | 1 - scenarios/uni06zeta.yaml | 1 - scenarios/uni07eta.yaml | 1 - scenarios/uni09iota.yaml | 1 - 12 files changed, 12 deletions(-) diff --git a/scenarios/bgp-l3-xl.yaml b/scenarios/bgp-l3-xl.yaml index 7bf268ee1..d681e234f 100644 --- a/scenarios/bgp-l3-xl.yaml +++ b/scenarios/bgp-l3-xl.yaml @@ -114,7 +114,6 @@ undercloud: value: false undercloud_parameters_override: "bgp-l3-xl/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "bgp-l3-xl/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.98 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/dcn_nostorage.yaml b/scenarios/dcn_nostorage.yaml index f11fe92c0..4ea8dda04 100644 --- a/scenarios/dcn_nostorage.yaml +++ b/scenarios/dcn_nostorage.yaml @@ -67,7 +67,6 @@ undercloud: value: 192.168.144.200,192.168.144.220 undercloud_parameters_override: "dcn_nostorage/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "dcn_nostorage/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.98 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/dcn_storage.yaml b/scenarios/dcn_storage.yaml index 71e11bf07..a3d53744e 100644 --- a/scenarios/dcn_storage.yaml +++ b/scenarios/dcn_storage.yaml @@ -71,7 +71,6 @@ undercloud: value: 192.168.144.200,192.168.144.220 undercloud_parameters_override: "dcn_storage/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "dcn_storage/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.98 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/hci.yaml b/scenarios/hci.yaml index af6a070b4..3af5af306 100644 --- a/scenarios/hci.yaml +++ b/scenarios/hci.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "hci/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "hci/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.98 cloud_domain: "ooo.test" tlse: true enable_keystone_ldap: true diff --git a/scenarios/uni01alpha.yaml b/scenarios/uni01alpha.yaml index 9bbd639d0..60445d067 100644 --- a/scenarios/uni01alpha.yaml +++ b/scenarios/uni01alpha.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni01alpha/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni01alpha/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/uni02beta.yaml b/scenarios/uni02beta.yaml index ff77107f7..f38f46eab 100644 --- a/scenarios/uni02beta.yaml +++ b/scenarios/uni02beta.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni02beta/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni02beta/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/uni04delta-ipv6.yaml b/scenarios/uni04delta-ipv6.yaml index 22a8b55b3..8acfcebdd 100644 --- a/scenarios/uni04delta-ipv6.yaml +++ b/scenarios/uni04delta-ipv6.yaml @@ -28,7 +28,6 @@ undercloud: undercloud_parameters_override: "uni04delta-ipv6/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni04delta-ipv6/undercloud_parameter_defaults.yaml" - ctlplane_vip: 2620:cf:cf:aaaa::98 cloud_domain: "example.com" hostname_groups_map: diff --git a/scenarios/uni04delta.yaml b/scenarios/uni04delta.yaml index 22217d994..6502e6eb5 100644 --- a/scenarios/uni04delta.yaml +++ b/scenarios/uni04delta.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni04delta/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni04delta/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.98 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/uni05epsilon.yaml b/scenarios/uni05epsilon.yaml index 861f29bdb..49a1d597b 100644 --- a/scenarios/uni05epsilon.yaml +++ b/scenarios/uni05epsilon.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni05epsilon/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni05epsilon/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 routes: &sroutes - ip_netmask: 0.0.0.0/0 next_hop: 192.168.122.1 diff --git a/scenarios/uni06zeta.yaml b/scenarios/uni06zeta.yaml index 5932b1d25..2dd6d3abd 100644 --- a/scenarios/uni06zeta.yaml +++ b/scenarios/uni06zeta.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni06zeta/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni06zeta/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/uni07eta.yaml b/scenarios/uni07eta.yaml index 5603534ea..c2174c831 100644 --- a/scenarios/uni07eta.yaml +++ b/scenarios/uni07eta.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni07eta/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni07eta/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for diff --git a/scenarios/uni09iota.yaml b/scenarios/uni09iota.yaml index 800c37d92..d40c300b1 100644 --- a/scenarios/uni09iota.yaml +++ b/scenarios/uni09iota.yaml @@ -21,7 +21,6 @@ undercloud: value: false undercloud_parameters_override: "uni09iota/hieradata_overrides_undercloud.yaml" undercloud_parameters_defaults: "uni09iota/undercloud_parameter_defaults.yaml" - ctlplane_vip: 192.168.122.101 cloud_domain: "example.com" hostname_groups_map: # map ansible groups in the inventory to role hostname format for From 114cfbfa8b2ca0184d4a8fcd329e6f844bb2c2fb Mon Sep 17 00:00:00 2001 From: Fiorella Yanac Date: Mon, 29 Jun 2026 11:26:39 +0100 Subject: [PATCH 09/20] Update the IP brigde for ceph to avoid conflict with test IP range For test IP range uses: start=192.168.122.171,end=192.168.122.250 so to avoid IP conflict, it needs to change the current IP bridge of ceph. In ci-framework-job files, IPs from .106 are assigned for ceph but it seems that it is not used. --- scenarios/uni04delta/ceph_inventory.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scenarios/uni04delta/ceph_inventory.yaml b/scenarios/uni04delta/ceph_inventory.yaml index 1503eeaf8..522b549d8 100644 --- a/scenarios/uni04delta/ceph_inventory.yaml +++ b/scenarios/uni04delta/ceph_inventory.yaml @@ -3,7 +3,7 @@ ceph: osp-ext-ceph-uni04delta-0: ansible_user: zuul ansible_ssh_private_key_file: /home/zuul/.ssh/cifmw_reproducer_key - bridge_ip: 192.168.122.210/24 + bridge_ip: 192.168.122.106/24 external_ip: 10.0.0.210/24 internalapi_ip: 172.17.0.210/24 storage_ip: 172.18.0.210/24 @@ -12,7 +12,7 @@ ceph: osp-ext-ceph-uni04delta-1: ansible_user: zuul ansible_ssh_private_key_file: /home/zuul/.ssh/cifmw_reproducer_key - bridge_ip: 192.168.122.211/24 + bridge_ip: 192.168.122.107/24 external_ip: 10.0.0.211/24 internalapi_ip: 172.17.0.211/24 storage_ip: 172.18.0.211/24 @@ -21,7 +21,7 @@ ceph: osp-ext-ceph-uni04delta-2: ansible_user: zuul ansible_ssh_private_key_file: /home/zuul/.ssh/cifmw_reproducer_key - bridge_ip: 192.168.122.212/24 + bridge_ip: 192.168.122.108/24 external_ip: 10.0.0.212/24 internalapi_ip: 172.17.0.212/24 storage_ip: 172.18.0.212/24 From fb56e92cc494e1405422c3f1380de735c3f119c1 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Mon, 29 Jun 2026 10:36:14 -0400 Subject: [PATCH 10/20] added attribute to attributes file --- docs_user/adoption-attributes.adoc | 5 +++++ docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/docs_user/adoption-attributes.adoc b/docs_user/adoption-attributes.adoc index 9809991c7..21d2e7093 100644 --- 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/modules/proc_creating-a-ceph-nfs-cluster.adoc b/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc index c860c2c2f..a554e6da4 100644 --- a/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc +++ b/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc @@ -135,7 +135,7 @@ For more information about deploying the clustered Ceph NFS service, see 'Manage * link:https://docs.redhat.com/documentation/en-us/red_hat_ceph_storage/7/html/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Red Hat Ceph Storage 7 _Operations Guide_] * link:https://docs.redhat.com/documentation/en-us/red_hat_ceph_storage/8/html/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Red Hat Ceph Storage 8 _Operations Guide_] -* link:https://docs.redhat.com/documentation/en-us/red_hat_ceph_storage/9/html/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Red Hat Ceph Storage 9 _Operations Guide_] +* link:https://www.ibm.com/docs/en/{ceph9_pdf_path}/Red_Hat_Ceph_Storage_NFS_cluster_and_share_management_(OpenStack_Manila_users_only).pdf[Red Hat Ceph Storage 9 NFS cluster and share management (OpenStack Manila users only)] > Creating an NFS cluster ==== endif::[] From 7605816aac2810d12542211ef904187ace0f5e5b Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Mon, 29 Jun 2026 16:10:20 -0400 Subject: [PATCH 11/20] removed extra word --- .../proc_preparing-RHOSO-for-director-operator-adoption.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc b/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc index fbca5c580..1dad070b1 100644 --- a/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc +++ b/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc @@ -180,7 +180,7 @@ spec: "cniVersion": "0.3.1", "name": "ctlplane", "type": "bridge", - "master": "br-ctlplane", + "bridge": "br-ctlplane", "ipam": { "type": "whereabouts", "range": "172.22.0.0/24", @@ -288,7 +288,7 @@ EOF + * Replace `` with your OpenStack 18 namespace. -. Ensure that the `OVNKubernetes IPForwarding` field is set to to `enabled`: +. Ensure that the `OVNKubernetes IPForwarding` field is set to `enabled`: + ---- $ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge From 151ca4720a2586ebf855738bdf66351ca9c4fe3c Mon Sep 17 00:00:00 2001 From: Juan Badia Payno Date: Tue, 30 Jun 2026 06:25:26 +0200 Subject: [PATCH 12/20] Enabled LUKS encryption for Ceph OSD in HCI scenarios This pull request introduces at-rest data encryption for Ceph OSDs within Hyperconverged Infrastructure (HCI) environments. By modifying the OSD specification, the HCI nodes will automatically have their underlying storage drives encrypted. --- scenarios/hci/osd_spec.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/scenarios/hci/osd_spec.yaml b/scenarios/hci/osd_spec.yaml index 0433ffab1..0ce899d88 100644 --- a/scenarios/hci/osd_spec.yaml +++ b/scenarios/hci/osd_spec.yaml @@ -1,3 +1,4 @@ --- data_devices: all: true +encrypted: true From 2fe2c57df255adcba8684f65ad9bcd86a9acc80c Mon Sep 17 00:00:00 2001 From: Roberto Alfieri Date: Fri, 5 Jun 2026 18:46:44 +0200 Subject: [PATCH 13/20] nova_verify, pre_launch_ironic: fix ironic post-adoption provisioning The post-adoption ironic instance provisioning task in nova_verify.yaml can fail with quota exceeded (HTTP 403) when the adopted environment already uses all available instances (e.g. uni04delta-ipv6 with 10 VMs from the source cloud at the default quota of 10). Set the instance quota correctly from the start in pre_launch_ironic.bash by reading the current quota and adding headroom for the pre-adoption and post-adoption test instances. The quota carries over through the Nova database migration during adoption, so the post-adoption provisioning step no longer hits the limit. Also add ironic_post_adoption_create_instance variable (default true) to allow scenarios to skip the post-adoption provisioning step entirely. Co-authored-by: Cursor --- tests/roles/dataplane_adoption/tasks/nova_verify.yaml | 1 + .../development_environment/files/pre_launch_ironic.bash | 4 ++++ tests/roles/ironic_adoption/defaults/main.yaml | 1 + 3 files changed, 6 insertions(+) diff --git a/tests/roles/dataplane_adoption/tasks/nova_verify.yaml b/tests/roles/dataplane_adoption/tasks/nova_verify.yaml index c6359abb0..a7dd0ec0b 100644 --- a/tests/roles/dataplane_adoption/tasks/nova_verify.yaml +++ b/tests/roles/dataplane_adoption/tasks/nova_verify.yaml @@ -58,6 +58,7 @@ when: - prelaunch_test_instance|bool - "'pre_launch_ironic.bash' in prelaunch_test_instance_scripts" + - ironic_post_adoption_create_instance|bool ansible.builtin.shell: | {{ shell_header }} {{ oc_header }} diff --git a/tests/roles/development_environment/files/pre_launch_ironic.bash b/tests/roles/development_environment/files/pre_launch_ironic.bash index 591d34adc..fe8249743 100644 --- a/tests/roles/development_environment/files/pre_launch_ironic.bash +++ b/tests/roles/development_environment/files/pre_launch_ironic.bash @@ -132,6 +132,10 @@ else echo "Found $ACTIVE_NODES active node(s), skipping node management operations" fi +# Ensure quota has headroom for pre-adoption and post-adoption test instances +CURRENT_QUOTA=$(${BASH_ALIASES[openstack]} quota show -c instances -f value) +${BASH_ALIASES[openstack]} quota set --instances $((CURRENT_QUOTA + 2)) default + # Create test instance on baremetal if [[ "${PRE_LAUNCH_IRONIC_CREATE_INSTANCE,,}" != "false" ]]; then # Wait for nova to be aware of the node diff --git a/tests/roles/ironic_adoption/defaults/main.yaml b/tests/roles/ironic_adoption/defaults/main.yaml index bdd4a7c4d..26540ed8e 100644 --- a/tests/roles/ironic_adoption/defaults/main.yaml +++ b/tests/roles/ironic_adoption/defaults/main.yaml @@ -109,3 +109,4 @@ ironic_retry_delay: 5 ironic_post_adoption_manage_nodes: false ironic_post_adoption_inspect_nodes: false ironic_post_adoption_provide_nodes: false +ironic_post_adoption_create_instance: true From f2fb1cc516d953c572971a45018346a48d357728 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Tue, 14 Jul 2026 10:52:05 -0400 Subject: [PATCH 14/20] updated ansibleUser to tripleo-admin --- .../proc_adopting-compute-services-to-the-data-plane.adoc | 2 +- .../proc_adopting-networker-services-to-the-data-plane.adoc | 2 +- .../modules/proc_configuring-dcn-data-plane-nodesets.adoc | 4 ++-- docs_user/modules/proc_using-new-subnet-ranges.adoc | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) 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 index ed3e9a95a..5b046c9cc 100644 --- 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: diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc index 770838cb5..80e5cfada 100644 --- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc +++ b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc @@ -144,7 +144,7 @@ endif::[] nodeTemplate: ansibleSSHPrivateKeySecret: dataplane-adoption-secret ansible: - ansibleUser: root + ansibleUser: tripleo-admin ifeval::["{build}" == "downstream"] ansibleVarsFrom: - secretRef: diff --git a/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc b/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc index fa1d79c23..50271a2d4 100644 --- a/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc +++ b/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc @@ -64,7 +64,7 @@ endif::[] nodeTemplate: ansibleSSHPrivateKeySecret: dataplane-adoption-secret ansible: - ansibleUser: root + ansibleUser: tripleo-admin ansibleVars: *edpm_ovn_bridge_mappings: ["leaf0:br-ex"]* edpm_ovn_bridge: br-int @@ -145,7 +145,7 @@ spec: nodeTemplate: ansibleSSHPrivateKeySecret: dataplane-adoption-secret ansible: - ansibleUser: root + ansibleUser: tripleo-admin ansibleVars: *edpm_ovn_bridge_mappings: ["leaf1:br-ex"]* edpm_ovn_bridge: br-int diff --git a/docs_user/modules/proc_using-new-subnet-ranges.adoc b/docs_user/modules/proc_using-new-subnet-ranges.adoc index 79b0201b5..914c584d5 100644 --- a/docs_user/modules/proc_using-new-subnet-ranges.adoc +++ b/docs_user/modules/proc_using-new-subnet-ranges.adoc @@ -104,7 +104,7 @@ As a result, the following route is added to your {OpenShiftShort} nodes: ---- nodeTemplate: ansible: - ansibleUser: root + ansibleUser: tripleo-admin ansibleVars: additional_ctlplane_host_routes: - ip_netmask: 172.31.0.0/24 From a8f3ef1d7b9a2b75c6770e460cc6f8e74e253c7b Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Mon, 13 Jul 2026 16:35:41 -0400 Subject: [PATCH 15/20] added sudo to bootstrap command --- ...pting-compute-services-to-the-data-plane.adoc | 16 ++++++++-------- ...ing-networker-services-to-the-data-plane.adoc | 6 +++--- .../proc_converting-object-storage-nodes.adoc | 10 +++++----- 3 files changed, 16 insertions(+), 16 deletions(-) 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 index 5b046c9cc..a0c63548f 100644 --- 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 @@ -530,25 +530,25 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - set -euxo pipefail + sudo set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main # 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 + sudo 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 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 set -euxo pipefail + sudo dnf -y upgrade openstack-selinux + sudo rm -f /run/virtlogd.pid endif::[] gather_facts: false diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc index 80e5cfada..c6909b9cf 100644 --- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc +++ b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc @@ -235,17 +235,17 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - set -euxo pipefail + sudo set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main # 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 + sudo dnf -y install crypto-policies update-crypto-policies --set FIPS:NO-ENFORCE-EMS ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - rm -rf repo-setup-main + sudo rm -rf repo-setup-main endif::[] gather_facts: false diff --git a/docs_user/modules/proc_converting-object-storage-nodes.adoc b/docs_user/modules/proc_converting-object-storage-nodes.adoc index 8dbf65cde..e7706af7f 100644 --- a/docs_user/modules/proc_converting-object-storage-nodes.adoc +++ b/docs_user/modules/proc_converting-object-storage-nodes.adoc @@ -193,19 +193,19 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - set -euxo pipefail + sudo set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main # 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 + sudo 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 upgrade openstack-selinux + sudo rm -f /run/virtlogd.pid + sudo rm -rf repo-setup-main endif::[] ifeval::["{build}" == "downstream"] rhc_release: 9.2 From 0e32cc4388fe69e0c8b9fad106faabcb522abd54 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Wed, 15 Jul 2026 11:17:11 -0400 Subject: [PATCH 16/20] incorporated sme feedback --- .../proc_adopting-compute-services-to-the-data-plane.adoc | 8 ++++---- ...roc_adopting-networker-services-to-the-data-plane.adoc | 6 +++--- .../modules/proc_converting-object-storage-nodes.adoc | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) 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 index a0c63548f..6a24c0e19 100644 --- 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 @@ -530,7 +530,7 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - sudo set -euxo pipefail + set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main @@ -538,15 +538,15 @@ ifeval::["{build}" != "downstream"] # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 sudo dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + 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: | - sudo set -euxo pipefail + set -euxo pipefail sudo dnf -y upgrade openstack-selinux sudo rm -f /run/virtlogd.pid endif::[] diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc index c6909b9cf..11d45bdeb 100644 --- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc +++ b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc @@ -235,7 +235,7 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - sudo set -euxo pipefail + set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main @@ -243,8 +243,8 @@ ifeval::["{build}" != "downstream"] # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 sudo dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS + sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream sudo rm -rf repo-setup-main endif::[] diff --git a/docs_user/modules/proc_converting-object-storage-nodes.adoc b/docs_user/modules/proc_converting-object-storage-nodes.adoc index e7706af7f..2ce64cfc3 100644 --- a/docs_user/modules/proc_converting-object-storage-nodes.adoc +++ b/docs_user/modules/proc_converting-object-storage-nodes.adoc @@ -193,7 +193,7 @@ endif::[] ifeval::["{build}" != "downstream"] edpm_bootstrap_command: | # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - sudo set -euxo pipefail + set -euxo pipefail curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz python3 -m venv ./venv PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main @@ -201,8 +201,8 @@ ifeval::["{build}" != "downstream"] # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 sudo dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + 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 From 1f6903c1ec030929761d339c845d778e9bda60cf Mon Sep 17 00:00:00 2001 From: Eduardo Olivares Date: Thu, 16 Jul 2026 18:26:23 +0200 Subject: [PATCH 17/20] mariadb_copy: wait for connectivity to TripleO Galera before sync check Commit 824d9edf replaced sleep-based BGP workarounds with a retry loop that checks connectivity to the podified MariaDB, but did not add an equivalent check for the source TripleO Galera nodes. With BGP, the route to the mariadb-copy-data pod may take a few seconds to be advertised, causing the subsequent WSREP sync check to fail with "ERROR 2002 (HY000): Can't connect to MySQL server" (EINPROGRESS). Add a retry-loop task that verifies TCP connectivity to every TripleO Galera member via 'select 1;' before running the non-retrying WSREP sync check. Also update the documentation procedure to include this new connectivity check step and fix the BGP note wording to correctly describe route advertisement direction. Assisted-By: Claude (claude-opus-4.6) --- ...rating-databases-to-mariadb-instances.adoc | 22 ++++++++++++++++++- tests/roles/mariadb_copy/tasks/main.yaml | 20 +++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) diff --git a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc index 81f1a1f31..67b551e2d 100644 --- a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc +++ b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc @@ -186,6 +186,26 @@ $ oc wait --for condition=Ready pod/mariadb-copy-data --timeout=30s .Procedure +. Wait for the `mariadb-copy-data` pod to reach the source TripleO Galera databases: ++ +---- +for CELL in $(echo $CELLS); do + MEMBERS=SOURCE_GALERA_MEMBERS_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')[@] + for i in "${!MEMBERS}"; do + echo "Checking connectivity to the database node $i" + oc rsh mariadb-copy-data mysql \ + -h "$i" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e 'select 1;' + done +done +---- ++ +[NOTE] +==== +For BGP-enabled environments, this command might take a few moments to succeed while the route to the `mariadb-copy-data` pod is advertised and propagated through the network via BGP. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. + +For standard deployments, this command should succeed immediately. +==== + . Check that the source Galera database clusters in each cell have its members online and synced: + ---- @@ -232,7 +252,7 @@ $ oc rsh mariadb-copy-data mysql -rsh "${PODIFIED_MARIADB_IP['super']}" \ + [NOTE] ==== -For BGP-enabled environments, this command might take a few moments to succeed while BGP routes are advertised and propagated through the network. The `mariadb-copy-data` pod needs to receive the route to the podified MariaDB IP address through BGP before it can establish a connection. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. +For BGP-enabled environments, this command might take a few moments to succeed while the route to the `mariadb-copy-data` pod is advertised and propagated through the network via BGP. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. For IPv6 environments, this command might take a few moments to succeed while the network IPv6 stack completes its setup. If the command fails, wait a few seconds and retry. diff --git a/tests/roles/mariadb_copy/tasks/main.yaml b/tests/roles/mariadb_copy/tasks/main.yaml index 6d5307d28..bc0d78eb8 100644 --- a/tests/roles/mariadb_copy/tasks/main.yaml +++ b/tests/roles/mariadb_copy/tasks/main.yaml @@ -86,6 +86,26 @@ until: _podified_db_check.rc == 0 changed_when: false +- name: wait until TripleO Galera DBs are reachable from the mariadb-copy-data pod + no_log: "{{ use_no_log }}" + ansible.builtin.shell: | + {{ oc_header }} + {{ mariadb_members_env }} + {{ mariadb_copy_shell_vars_src }} + for CELL in $(echo $CELLS); do + MEMBERS=SOURCE_GALERA_MEMBERS_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')[@] + for i in "${!MEMBERS}"; do + echo "Checking connectivity to the database node $i" + oc rsh mariadb-copy-data mysql \ + -h "$i" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e 'select 1;' + done + done + register: _galera_db_check + retries: 60 + delay: 3 + until: _galera_db_check.rc == 0 + changed_when: false + - name: check that the Galera database cluster(s) members are online and synced, for all cells no_log: "{{ use_no_log }}" ansible.builtin.shell: | From 314b736c24009b896da92e47f6aa6589149a9382 Mon Sep 17 00:00:00 2001 From: Jiri Stransky Date: Fri, 17 Jul 2026 10:51:37 +0200 Subject: [PATCH 18/20] Pin Github actions to SHAs Additionally, update the basic checkout and setup-python actions to non-EOL releases. Assisted-by: goose+gemini --- .github/workflows/docs.yaml | 6 +++--- .github/workflows/lint.yaml | 6 +++--- .github/workflows/stale-pr.yml | 2 +- .github/workflows/sync_branches_with_ext_trigger.yml | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/.github/workflows/docs.yaml b/.github/workflows/docs.yaml index 12f261d75..5a2861f97 100644 --- 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 index fe951c4ef..0b42a0aec 100644 --- 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 index 82b5392b9..2c54e2496 100644 --- 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 index f2530c183..ce8565815 100644 --- 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 }} From 59afe0619f5aa183481d68bf033e81143969fdae Mon Sep 17 00:00:00 2001 From: Roberto Alfieri Date: Wed, 15 Jul 2026 17:02:52 +0200 Subject: [PATCH 19/20] Enable Ceph for uni05epsilon adoption scenario Add external Ceph deployment to the uni05epsilon multi-cell adoption scenario, following the uni04delta pattern. The Ceph cluster is deployed on the cell1 and cell2 compute nodes (which have OSD disks) as an external cluster before the TripleO overcloud deploy. All three stacks (overcloud, cell1, cell2) reference the external-ceph environment and generated credentials. Changes: - Add ceph_inventory.yaml targeting cell1/cell2 computes - Add osd_spec.yaml for OSD device configuration - Add pre_oc_run hooks to overcloud stack: setup ceph nodes, deploy ceph cluster, create external ceph parameters - Add external-ceph.yaml environment to all three stacks Related: OSPNW-1658 Co-authored-by: Cursor --- scenarios/uni05epsilon.yaml | 24 +++++++++++++++++++ scenarios/uni05epsilon/ceph_inventory.yaml | 20 ++++++++++++++++ .../uni05epsilon/config_download_cell1.yaml | 6 +++++ .../uni05epsilon/config_download_cell2.yaml | 6 +++++ scenarios/uni05epsilon/osd_spec.yaml | 3 +++ scenarios/uni05epsilon/roles.yaml | 8 +++++++ 6 files changed, 67 insertions(+) create mode 100644 scenarios/uni05epsilon/ceph_inventory.yaml create mode 100644 scenarios/uni05epsilon/osd_spec.yaml diff --git a/scenarios/uni05epsilon.yaml b/scenarios/uni05epsilon.yaml index 49a1d597b..7fa41e976 100644 --- a/scenarios/uni05epsilon.yaml +++ b/scenarios/uni05epsilon.yaml @@ -61,6 +61,8 @@ stacks: - "/usr/share/openstack-tripleo-heat-templates/environments/podman.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/debug.yaml" + - "/usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml" + - "/home/zuul/external_ceph_params.yaml" network_data_file: "uni05epsilon/network_data.yaml.j2" routes: *sroutes vips_data_file: "uni05epsilon/vips_data_overcloud.yaml" @@ -68,6 +70,24 @@ stacks: config_download_file: "uni05epsilon/config_download_overcloud.yaml" stack_nodes: - osp-controllers + pre_oc_run: + - name: 01 Prepare Ceph nodes + type: playbook + source: "setup_cephnodes.yaml" + inventory: "{{ ansible_user_dir }}/{{ zuul.projects['github.com/openstack-k8s-operators/data-plane-adoption']. + src_dir }}/scenarios/uni05epsilon/ceph_inventory.yaml" + - name: 02 Deploy external ceph + type: playbook + source: "ceph.yml" + gathering: implicit + inventory: "{{ ansible_user_dir }}/{{ zuul.projects['github.com/openstack-k8s-operators/data-plane-adoption']. + src_dir }}/scenarios/uni05epsilon/ceph_inventory.yaml" + - name: 03 Create external Ceph parameters file + type: playbook + source: "create_external_ceph_params.yml" + extra_vars: + ceph_node: "cell1-osp-compute-uni05epsilon-0" + ceph_mon_host: "172.18.0.94,172.18.0.95" post_oc_run: - name: Multi-cell post overcloud deploy type: playbook @@ -93,6 +113,8 @@ stacks: - "/usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/debug.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml" + - "/usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml" + - "/home/zuul/external_ceph_params.yaml" - "/home/zuul/cell1-input.yaml" network_data_file: "uni05epsilon/network_data.yaml.j2" routes: *sroutes @@ -132,6 +154,8 @@ stacks: - "/usr/share/openstack-tripleo-heat-templates/environments/podman.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml" - "/usr/share/openstack-tripleo-heat-templates/environments/debug.yaml" + - "/usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml" + - "/home/zuul/external_ceph_params.yaml" - "/home/zuul/cell2-input.yaml" network_data_file: "uni05epsilon/network_data.yaml.j2" routes: *sroutes diff --git a/scenarios/uni05epsilon/ceph_inventory.yaml b/scenarios/uni05epsilon/ceph_inventory.yaml new file mode 100644 index 000000000..5f29a8883 --- /dev/null +++ b/scenarios/uni05epsilon/ceph_inventory.yaml @@ -0,0 +1,20 @@ +computes: + hosts: + cell1-osp-compute-uni05epsilon-0: + ansible_user: zuul + ansible_ssh_private_key_file: /home/zuul/.ssh/cifmw_reproducer_key + bridge_ip: 192.168.122.94/24 + external_ip: 172.21.0.94/24 + internalapi_ip: 172.17.0.94/24 + storage_ip: 172.18.0.94/24 + storagemgmt_ip: 172.20.0.94/24 + tenant_ip: 172.19.0.94/24 + cell2-osp-compute-uni05epsilon-0: + ansible_user: zuul + ansible_ssh_private_key_file: /home/zuul/.ssh/cifmw_reproducer_key + bridge_ip: 192.168.122.95/24 + external_ip: 172.21.0.95/24 + internalapi_ip: 172.17.0.95/24 + storage_ip: 172.18.0.95/24 + storagemgmt_ip: 172.20.0.95/24 + tenant_ip: 172.19.0.95/24 diff --git a/scenarios/uni05epsilon/config_download_cell1.yaml b/scenarios/uni05epsilon/config_download_cell1.yaml index a3acfd22e..52a953ef7 100644 --- a/scenarios/uni05epsilon/config_download_cell1.yaml +++ b/scenarios/uni05epsilon/config_download_cell1.yaml @@ -43,6 +43,12 @@ resource_registry: parameter_defaults: SshFirewallAllowAll: true + ExtraFirewallRules: + '110 ceph_mon': + dport: + - 3300 + - 6789 + proto: tcp # Specify that this is an additional cell NovaAdditionalCell: true diff --git a/scenarios/uni05epsilon/config_download_cell2.yaml b/scenarios/uni05epsilon/config_download_cell2.yaml index 3b75009e6..6731b7894 100644 --- a/scenarios/uni05epsilon/config_download_cell2.yaml +++ b/scenarios/uni05epsilon/config_download_cell2.yaml @@ -43,6 +43,12 @@ resource_registry: parameter_defaults: SshFirewallAllowAll: true + ExtraFirewallRules: + '110 ceph_mon': + dport: + - 3300 + - 6789 + proto: tcp # Specify that this is an additional cell NovaAdditionalCell: true diff --git a/scenarios/uni05epsilon/osd_spec.yaml b/scenarios/uni05epsilon/osd_spec.yaml new file mode 100644 index 000000000..0433ffab1 --- /dev/null +++ b/scenarios/uni05epsilon/osd_spec.yaml @@ -0,0 +1,3 @@ +--- +data_devices: + all: true diff --git a/scenarios/uni05epsilon/roles.yaml b/scenarios/uni05epsilon/roles.yaml index 9b07238fe..e7caccea2 100644 --- a/scenarios/uni05epsilon/roles.yaml +++ b/scenarios/uni05epsilon/roles.yaml @@ -46,6 +46,8 @@ - OS::TripleO::Services::AuditD - OS::TripleO::Services::BootParams - OS::TripleO::Services::CACerts + - OS::TripleO::Services::CephClient + - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderBackendDellSc - OS::TripleO::Services::CinderBackendDellEMCPowerFlex @@ -165,6 +167,8 @@ - OS::TripleO::Services::AuditD - OS::TripleO::Services::BootParams - OS::TripleO::Services::CACerts + - OS::TripleO::Services::CephClient + - OS::TripleO::Services::CephExternal - OS::TripleO::Services::Clustercheck - OS::TripleO::Services::Collectd - OS::TripleO::Services::ContainerImagePrepare @@ -217,6 +221,8 @@ subnet: tenant_subnet Storage: subnet: storage_subnet + StorageMgmt: + subnet: storage_mgmt_subnet default_route_networks: ['ControlPlane'] HostnameFormatDefault: '%stackname%-novacompute-%index%' RoleParametersDefault: @@ -240,6 +246,8 @@ - OS::TripleO::Services::AuditD - OS::TripleO::Services::BootParams - OS::TripleO::Services::CACerts + - OS::TripleO::Services::CephClient + - OS::TripleO::Services::CephExternal - OS::TripleO::Services::ComputeNeutronCorePlugin - OS::TripleO::Services::ComputeNeutronL3Agent - OS::TripleO::Services::ComputeNeutronMetadataAgent From 7757a85e6e2a85d7832c5d429a8e1d055bf0041f Mon Sep 17 00:00:00 2001 From: Andre Aranha Date: Thu, 23 Jul 2026 14:03:03 +0200 Subject: [PATCH 20/20] Fix oidc remote cloudrc path OIDC tests can run into issues due to the federation_oidc_cloudrc_remote_path var, it can try to access the /home/root folder, which doesn't exist. This patch will set federation_oidc_cloudrc_remote_path to /root/ci-framework-data/tmp/{{ federation_oidc_cloudrc_filename }} --- tests/roles/development_environment/defaults/main.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/roles/development_environment/defaults/main.yaml b/tests/roles/development_environment/defaults/main.yaml index a71378103..1879c0842 100644 --- a/tests/roles/development_environment/defaults/main.yaml +++ b/tests/roles/development_environment/defaults/main.yaml @@ -36,7 +36,7 @@ enable_federation: false get_oidc_token_command: >- ssh -i {{ edpm_privatekey_path }} -o StrictHostKeyChecking=no {{ source_osp_ssh_user }}@{{ standalone_ip | default(edpm_node_ip) }} "source {{ federation_oidc_cloudrc_remote_path }} && openstack token issue -f value -c id" # Path on the source node where the rendered cloudrc file should be stored. -federation_oidc_cloudrc_remote_path: /home/{{ source_osp_ssh_user }}/ci-framework-data/tmp/{{ federation_oidc_cloudrc_filename }} +federation_oidc_cloudrc_remote_path: /root/ci-framework-data/tmp/{{ federation_oidc_cloudrc_filename }} # Name of the cloudrc file rendered for OIDC authentication. federation_oidc_cloudrc_filename: kctestuser1 federation_oidc_cloudrc_template: kctestuser1.j2