Skip to content

Commit 45137bb

Browse files
committed
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. Signed-off-by: Christian Schwede <cschwede@redhat.com>
1 parent 3e13597 commit 45137bb

3 files changed

Lines changed: 228 additions & 2 deletions

File tree

docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,11 @@ If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object St
1212

1313
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".
1414

15+
You have two options for handling the existing {object_storage} storage nodes:
16+
17+
* *Migrate data to new {rhos_acro} nodes* -- Provision new storage nodes on {rhocp_long} and gradually move data using `swift-ring-tool`.
18+
* *Convert existing nodes to data plane nodes* -- Keep the data on the same nodes and convert them to data plane nodes managed by the EDPM operator. No data movement is required.
19+
1520
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.
1621

1722
[NOTE]
@@ -22,6 +27,8 @@ include::../modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc[level
2227

2328
include::../modules/con_troubleshooting-object-storage-migration.adoc[leveloffset=+1]
2429

30+
include::../modules/proc_converting-object-storage-nodes.adoc[leveloffset=+1]
31+
2532
[role="_additional-resources"]
2633
== Additional resources
2734
* xref:ceph-migration_adopt-control-plane[Migrating the {Ceph} cluster]

docs_user/modules/proc_adopting-the-object-storage-service.adoc

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -132,5 +132,10 @@ $ openstack object save test obj --file -
132132
Hello World!
133133
----
134134

135-
[NOTE]
136-
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].
135+
.Next steps
136+
137+
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:
138+
139+
* *Migrate data to new {rhos_acro} nodes* -- Provision new storage nodes on {rhocp_long} and gradually move data using `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].
140+
141+
* *Convert existing nodes to dataplane nodes* -- Keep the data on the same nodes and convert them to dataplane nodes managed by the openstack-operators. No data movement is required. For more information, see xref:converting-object-storage-nodes[Converting {object_storage} storage nodes].
Lines changed: 214 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,214 @@
1+
:_mod-docs-content-type: PROCEDURE
2+
[id="converting-object-storage-nodes"]
3+
4+
= Converting {object_storage} storage nodes
5+
6+
[role="_abstract"]
7+
If you used external {object_storage} storage nodes, you can convert these
8+
nodes after the initial {object_storage_first_ref} adoption is complete. This
9+
step reconfigures the nodes in-place while keeping the {object_storage}
10+
available throughout the process.
11+
12+
.Key concepts
13+
* *Pre-provisioned nodes*: Setting `preProvisioned: true` in the
14+
`OpenStackDataPlaneNodeSet` skips provisioning the node from scratch and does
15+
not reinstall the operating system.
16+
* *{object_storage} disk and mount preservation*: `edpm_swift_disks: []` must be
17+
set in *both* the `nodeTemplate` *and* in the individual node definition under
18+
`nodes` to ensure that no disks are formatted or mounted differently, leaving
19+
existing disk mounts untouched. The `SwiftRawDisks` parameter from
20+
{OpenStackPreviousInstaller} is not migrated or converted -- disks on
21+
converted nodes must be managed manually.
22+
* *Rolling conversion with multiple node sets*: In production, do not convert
23+
all {object_storage} nodes at once. Instead, create separate
24+
`OpenStackDataPlaneNodeSet` resources and deploy them sequentially. Align
25+
groups with ring zones or regions so that no more than one replica of any
26+
partition is affected during the conversion.
27+
28+
.Prerequisites
29+
30+
* The initial {object_storage} adoption is complete. For more information, see
31+
xref:adopting-the-object-storage-service[Adopting the
32+
{object_storage}].
33+
34+
.Procedure
35+
36+
. Create a cleanup `OpenStackDataPlaneService` CR to remove remaining
37+
{OpenStackPreviousInstaller} artifacts (containers, systemd units,
38+
configuration) from the node:
39+
+
40+
----
41+
$ oc apply -f - <<EOF
42+
apiVersion: dataplane.openstack.org/v1beta1
43+
kind: OpenStackDataPlaneService
44+
metadata:
45+
name: tripleo-cleanup
46+
namespace: openstack
47+
spec:
48+
playbook: osp.edpm.tripleo_cleanup
49+
EOF
50+
----
51+
52+
ifeval::["{build}" == "upstream"]
53+
. Create a repo-setup `OpenStackDataPlaneService` CR to configure RPM repositories on the node:
54+
+
55+
----
56+
$ oc apply -f - <<EOF
57+
apiVersion: dataplane.openstack.org/v1beta1
58+
kind: OpenStackDataPlaneService
59+
metadata:
60+
name: repo-setup
61+
namespace: openstack
62+
spec:
63+
addCertMounts: false
64+
caCerts: combined-ca-bundle
65+
edpmServiceType: repo-setup
66+
playbookContents: |
67+
- hosts: all
68+
strategy: linear
69+
tasks:
70+
- name: Enable podified-repos
71+
become: true
72+
ansible.builtin.shell: |
73+
# This needs rhos-release.rpm to be downloaded before or an
74+
# alternative way to use upstream repos
75+
dnf install -y /tmp/rhos-release.rpm
76+
rhos-release -x
77+
rhos-release 18.0
78+
EOF
79+
----
80+
endif::[]
81+
82+
. Create the `OpenStackDataPlaneNodeSet` CR that defines which nodes to convert and how to configure them:
83+
+
84+
[subs="+quotes"]
85+
----
86+
apiVersion: dataplane.openstack.org/v1beta1
87+
kind: OpenStackDataPlaneNodeSet
88+
metadata:
89+
name: openstack-edpm-ipam
90+
namespace: openstack
91+
spec:
92+
networkAttachments:
93+
- ctlplane
94+
- storage
95+
nodeTemplate:
96+
ansible:
97+
ansibleUser: cloud-admin
98+
ansibleVars:
99+
edpm_nodes_validation_validate_controllers_icmp: false
100+
edpm_nodes_validation_validate_gateway_icmp: false
101+
edpm_service_removal_skip_list:
102+
- tripleo-container-shutdown.service
103+
edpm_sshd_allowed_ranges:
104+
- 192.168.122.0/24
105+
edpm_swift_disks: []
106+
enable_debug: false
107+
gather_facts: false
108+
timesync_ntp_servers:
109+
- hostname: pool.ntp.org
110+
ansibleSSHPrivateKeySecret: dataplane-adoption-secret
111+
managementNetwork: ctlplane
112+
nodes:
113+
edpm-swift-0:
114+
ansible:
115+
ansibleHost: 192.168.122.100
116+
ifeval::["{build}" == "downstream"]
117+
ansibleVarsFrom:
118+
- secretRef:
119+
name: subscription-manager
120+
- secretRef:
121+
name: redhat-registry
122+
endif::[]
123+
ansibleVars:
124+
edpm_swift_disks: []
125+
ifeval::["{build}" == "downstream"]
126+
rhc_release: 9.2
127+
rhc_repositories:
128+
- {name: "*", state: disabled}
129+
- {name: "rhel-9-for-x86_64-baseos-eus-rpms", state: enabled}
130+
- {name: "rhel-9-for-x86_64-appstream-eus-rpms", state: enabled}
131+
- {name: "rhel-9-for-x86_64-highavailability-eus-rpms", state: enabled}
132+
- {name: "rhoso-18.0-for-rhel-9-x86_64-rpms", state: enabled}
133+
endif::[]
134+
hostName: edpm-swift-0
135+
networks:
136+
- defaultRoute: true
137+
fixedIP: 192.168.122.100
138+
name: ctlplane
139+
subnetName: subnet1
140+
- name: internalapi
141+
subnetName: subnet2
142+
- name: storage
143+
subnetName: subnet3
144+
- name: tenant
145+
subnetName: subnet4
146+
preProvisioned: true
147+
services:
148+
ifeval::["{build}" == "upstream"]
149+
- repo-setup
150+
endif::[]
151+
- bootstrap
152+
- download-cache
153+
- install-os
154+
- configure-os
155+
- ssh-known-hosts
156+
- run-os
157+
- reboot-os
158+
- install-certs
159+
- tripleo-cleanup
160+
- swift
161+
tlsEnabled: true
162+
----
163+
+
164+
165+
. Apply the `OpenStackDataPlaneNodeSet` CR:
166+
+
167+
----
168+
$ oc apply -f nodeset.yaml
169+
----
170+
171+
. Create an `OpenStackDataPlaneDeployment` CR to trigger the Ansible pipeline on the node:
172+
+
173+
----
174+
$ oc apply -f - <<EOF
175+
apiVersion: dataplane.openstack.org/v1beta1
176+
kind: OpenStackDataPlaneDeployment
177+
metadata:
178+
name: openstack-edpm-ipam
179+
namespace: openstack
180+
spec:
181+
nodeSets:
182+
- openstack-edpm-ipam
183+
EOF
184+
----
185+
186+
. Wait for the deployment to complete:
187+
+
188+
----
189+
$ oc wait --for condition=Ready openstackdataplanedeployment/openstack-edpm-ipam --timeout=30m
190+
----
191+
192+
. Monitor progress:
193+
+
194+
----
195+
$ watch oc get pod -l app=openstackansibleee
196+
----
197+
+
198+
----
199+
$ oc logs -l app=openstackansibleee -f --max-log-requests 20
200+
----
201+
202+
.Verification
203+
204+
* Verify that the node set is ready:
205+
+
206+
----
207+
$ oc get openstackdataplanenodeset openstack-edpm-ipam
208+
----
209+
210+
* Verify that {object_storage} services are running on the converted node:
211+
+
212+
----
213+
$ ssh cloud-admin@192.168.122.100 "sudo systemctl status edpm_swift_*"
214+
----

0 commit comments

Comments
 (0)