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 }} 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/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-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc index e3857dd5a..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 @@ -437,7 +437,7 @@ endif::[] nodeTemplate: ansibleSSHPrivateKeySecret: dataplane-adoption-secret ansible: - ansibleUser: root + ansibleUser: tripleo-admin ifeval::["{build}" == "downstream"] ansibleVarsFrom: - secretRef: @@ -537,18 +537,18 @@ ifeval::["{build}" != "downstream"] # This is required for FIPS enabled until trunk.rdoproject.org # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 - dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - dnf -y upgrade openstack-selinux - rm -f /run/virtlogd.pid - rm -rf repo-setup-main + sudo dnf -y install crypto-policies + sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS + sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + sudo dnf -y upgrade openstack-selinux + sudo rm -f /run/virtlogd.pid + sudo rm -rf repo-setup-main endif::[] ifeval::["{build}" == "downstream"] edpm_bootstrap_command: | set -euxo pipefail - dnf -y upgrade openstack-selinux - rm -f /run/virtlogd.pid + sudo dnf -y upgrade openstack-selinux + sudo rm -f /run/virtlogd.pid endif::[] gather_facts: false @@ -560,8 +560,8 @@ endif::[] edpm_ovs_packages: - openvswitch3.3 edpm_default_mounts: - - path: /dev/hugepages - 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. 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..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 @@ -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] ==== @@ -144,7 +144,7 @@ endif::[] nodeTemplate: ansibleSSHPrivateKeySecret: dataplane-adoption-secret ansible: - ansibleUser: root + ansibleUser: tripleo-admin ifeval::["{build}" == "downstream"] ansibleVarsFrom: - secretRef: @@ -242,10 +242,10 @@ ifeval::["{build}" != "downstream"] # This is required for FIPS enabled until trunk.rdoproject.org # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 - dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - rm -rf repo-setup-main + sudo dnf -y install crypto-policies + sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS + sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + sudo rm -rf repo-setup-main endif::[] gather_facts: false 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-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_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_converting-object-storage-nodes.adoc b/docs_user/modules/proc_converting-object-storage-nodes.adoc index 8dbf65cde..2ce64cfc3 100644 --- a/docs_user/modules/proc_converting-object-storage-nodes.adoc +++ b/docs_user/modules/proc_converting-object-storage-nodes.adoc @@ -200,12 +200,12 @@ ifeval::["{build}" != "downstream"] # This is required for FIPS enabled until trunk.rdoproject.org # is not being served from a centos7 host, tracked by # https://issues.redhat.com/browse/RHOSZUUL-1517 - dnf -y install crypto-policies - update-crypto-policies --set FIPS:NO-ENFORCE-EMS - ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - dnf -y upgrade openstack-selinux - rm -f /run/virtlogd.pid - rm -rf repo-setup-main + sudo dnf -y install crypto-policies + sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS + sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream + sudo dnf -y upgrade openstack-selinux + sudo rm -f /run/virtlogd.pid + sudo rm -rf repo-setup-main endif::[] ifeval::["{build}" == "downstream"] rhc_release: 9.2 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::[] 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-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/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-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/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_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 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/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 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: + 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 7fea1cfc1..3af5af306 100644 --- a/scenarios/hci.yaml +++ b/scenarios/hci.yaml @@ -21,9 +21,9 @@ 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 hostname_groups_map: # map ansible groups in the inventory to role hostname format for # 17.1 deployment 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 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/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 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 diff --git a/scenarios/uni05epsilon.yaml b/scenarios/uni05epsilon.yaml index 861f29bdb..7fa41e976 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 @@ -62,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" @@ -69,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 @@ -94,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 @@ -133,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 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/uni07eta/config_download.yaml b/scenarios/uni07eta/config_download.yaml index 652ef9b53..9d59885f2 100644 --- a/scenarios/uni07eta/config_download.yaml +++ b/scenarios/uni07eta/config_download.yaml @@ -44,7 +44,7 @@ parameter_defaults: use_neutron: false 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 @@ -53,7 +53,7 @@ parameter_defaults: ControllerCount: 3 ComputeCount: 2 NetworkerCount: 3 - NeutronGlobalPhysnetMtu: 1400 + NeutronGlobalPhysnetMtu: 9000 CinderLVMLoopDeviceSize: 20480 CloudName: overcloud.example.com CloudNameInternal: overcloud.internalapi.example.com @@ -76,7 +76,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'}] 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 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/defaults/main.yaml b/tests/roles/development_environment/defaults/main.yaml index d77ea96ac..1879c0842 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 @@ -25,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 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/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 - < /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 - ${BASH_ALIASES[openstack]} token issue -f json - register: adoption_oidc_token_result + 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: | @@ -183,3 +241,23 @@ ${BASH_ALIASES[openstack]} credential show {{ before_adoption_credential.stdout }} -f value -c blob register: after_adoption_credential failed_when: after_adoption_credential.stdout != 'test' + +- name: get ldap user token + ansible.builtin.shell: | + {{ shell_header }} + {{ oc_header }} + + alias openstack="oc exec -t openstackclient -- openstack" + + auth_url=$(${BASH_ALIASES[openstack]} endpoint list --service keystone --interface public -f value -c URL) + + alias openstack="oc exec -t openstackclient -- env -u OS_CLOUD - OS_AUTH_URL=${auth_url} OS_USERNAME=ipauser1 OS_PASSWORD={{ ipa_user_password }} OS_PROJECT_DOMAIN_NAME=REDHAT OS_USER_DOMAIN_NAME=REDHAT openstack" + + ${BASH_ALIASES[openstack]} token issue -f json + register: keystone_ldap_responding_result + when: enable_keystone_ldap | default(false) | bool + +- name: Print ldap user token + ansible.builtin.debug: + var: keystone_ldap_responding_result + when: enable_keystone_ldap | default(false) | bool 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: | 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