From 9fdeaabd9ca139bddd841985e7ee29534551ecfa Mon Sep 17 00:00:00 2001 From: Christian Schwede Date: Wed, 1 Apr 2026 10:13:06 +0200 Subject: [PATCH] Add procedure for converting external Swift storage nodes Adds documentation for converting existing TripleO-managed Swift storage nodes post-adoption without data migration. There are two ways to adopt existing Swift storage nodes: 1. Migrate data to PVs (or dataplane nodes), which is required if Swift storage was deployed on previous controller nodes 2. Convert existing TripleO/Director-managed nodes to dataplane nodes, which should be used for any former external ObjectStorage node to avoid moving huge amounts of data. This commit adds documentation for the second option; the first one already exists. JIRA: OSPRH-23099 Signed-off-by: Christian Schwede Co-authored-by: Katie Gilligan --- ..._migrating-the-object-storage-service.adoc | 9 +- ...c_adopting-the-object-storage-service.adoc | 9 +- .../proc_converting-object-storage-nodes.adoc | 283 ++++++++++++++++++ 3 files changed, 298 insertions(+), 3 deletions(-) create mode 100644 docs_user/modules/proc_converting-object-storage-nodes.adoc diff --git a/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc b/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc index fbd29ae8c..6fbf3c3bc 100644 --- a/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc +++ b/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc @@ -8,10 +8,15 @@ ifdef::context[:parent-context: {context}] = Migrating the {object_storage} to {rhos_long_noacro} nodes [role="_abstract"] -If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long_noacro} nodes. +If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long} nodes. If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see "Migrating the {Ceph} cluster". If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in "Deploying a Ceph ingress daemon" and "Create or update the Object Storage service endpoints". +You have two options for handling the existing {object_storage} storage nodes: + +* *Migrate data to new {rhos_acro} nodes* : Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`. +* *Convert existing nodes to data plane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the data plane operator. + The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the {object_storage} during the migration. [NOTE] @@ -22,6 +27,8 @@ include::../modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc[level include::../modules/con_troubleshooting-object-storage-migration.adoc[leveloffset=+1] +include::../modules/proc_converting-object-storage-nodes.adoc[leveloffset=+1] + [role="_additional-resources"] == Additional resources * xref:ceph-migration_adopt-control-plane[Migrating the {Ceph} cluster] diff --git a/docs_user/modules/proc_adopting-the-object-storage-service.adoc b/docs_user/modules/proc_adopting-the-object-storage-service.adoc index f76133383..85d1d89dd 100644 --- a/docs_user/modules/proc_adopting-the-object-storage-service.adoc +++ b/docs_user/modules/proc_adopting-the-object-storage-service.adoc @@ -132,5 +132,10 @@ $ openstack object save test obj --file - Hello World! ---- -[NOTE] -The Object Storage data is still stored on the existing {OpenStackShort} nodes. For more information about migrating the actual data from the {OpenStackShort} deployment to the {rhos_acro} deployment, see xref:migrating-object-storage-data-to-rhoso-nodes_migrate-object-storage-service[Migrating the {object_storage_first_ref} data from {OpenStackShort} to {rhos_long} nodes]. +.Next steps + +After the initial adoption, the {object_storage} data is still stored on the existing {OpenStackShort} nodes. You have two options for handling these storage nodes: + +* *Migrate data to new {rhos_acro} nodes*: Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`. For more information, see xref:migrating-object-storage-data-to-rhoso-nodes_migrate-object-storage-service[Migrating the {object_storage_first_ref} data from {OpenStackShort} to {rhos_long} nodes]. + +* *Convert existing nodes to dataplane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the `openstack-operators`. For more information, see xref:converting-object-storage-nodes[Converting {object_storage} storage nodes]. diff --git a/docs_user/modules/proc_converting-object-storage-nodes.adoc b/docs_user/modules/proc_converting-object-storage-nodes.adoc new file mode 100644 index 000000000..5b7f2f1bb --- /dev/null +++ b/docs_user/modules/proc_converting-object-storage-nodes.adoc @@ -0,0 +1,283 @@ +:_mod-docs-content-type: PROCEDURE +[id="converting-object-storage-nodes"] + += Converting {object_storage} storage nodes + +[role="_abstract"] +If you used external {object_storage} storage nodes, you can convert these +nodes after the initial {object_storage_first_ref} adoption is complete. This +step reconfigures the nodes in-place while keeping the {object_storage} +available throughout the process. + +Before you begin, review the following key concepts: + +Pre-provisioned nodes:: Setting `preProvisioned: true` in the + `OpenStackDataPlaneNodeSet` custom resource (CR) skips provisioning the node from scratch and does not reinstall the operating system. +{object_storage} disk and mount preservation:: `edpm_swift_disks: []` must be + set in both the `nodeTemplate` and in the individual node definition under + `nodes` to ensure that no disks are formatted or mounted differently. + Existing disk mounts are untouched. The `SwiftRawDisks` parameter from + {OpenStackPreviousInstaller} is not migrated or converted. Disks on + converted nodes must be managed manually. +Rolling conversion with multiple node sets:: In production, do not convert + all {object_storage} nodes at once. Instead, create separate + `OpenStackDataPlaneNodeSet` custom resources and deploy them sequentially. Align + groups with ring zones or regions so that no more than one replica of any + partition is affected during the conversion. + +.Prerequisites + +* The initial {object_storage} adoption is complete. For more information, see + xref:adopting-the-object-storage-service_hsm-integration[Adopting the + {object_storage}]. +* Nodes cannot be members of more than one `OpenStackDataPlaneNodeSet` CR at + the same time. If the nodes you want to convert were part of the node set + that you created during the control plane adoption, delete that node set + before proceeding: ++ +---- +$ oc delete openstackdataplanenodeset +---- ++ +where: + +``:: +Specifies the node set that you want to delete. + +.Procedure + +. Create a patch file to configure the {object_storage} data plane storage + ports: ++ +[NOTE] +The {OpenStackPreviousInstaller} deployment used different default +ports: 6002 for the account server, 6001 for the container server, 6000 for +the object server. The converted nodes must continue to use these same +ports to ensure connectivity between all {object_storage} storage nodes by using +the unmodified rings. ++ +---- +cat > swift-config-patch.yaml << EOF +spec: + swift: + template: + swiftStorage: + defaultConfigOverwrite: + 01-account-server.conf: | + [DEFAULT] + bind_port = 6002 + 01-container-server.conf: | + [DEFAULT] + bind_port = 6001 + 01-object-server.conf: | + [DEFAULT] + bind_port = 6000 +EOF +---- ++ +[NOTE] +If you customized any {object_storage} service settings in the +{OpenStackPreviousInstaller} deployment, include those settings as well. For +example, if you changed the workers count or added additional configuration options +for the account, container, or object services, add them to the +corresponding section in the patch file. + +. Apply the patch to the `OpenStackControlPlane` CR: ++ +---- +$ oc patch openstackcontrolplane openstack --type=merge --patch-file=swift-config-patch.yaml +---- + +. Create a `OpenStackDataPlaneService` CR to remove remaining + {OpenStackPreviousInstaller} artifacts, such as containers, `systemd` units, and + configuration, from the node: ++ +---- +$ oc apply -f - <