Skip to content

Commit d14b316

Browse files
cschwedeklgill
cschwede
and
klgill
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> Co-authored-by: Katie Gilligan <kgilliga@redhat.com>
1 parent 3e13597 commit d14b316

3 files changed

Lines changed: 227 additions & 3 deletions

File tree

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

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,10 +8,15 @@ ifdef::context[:parent-context: {context}]
88
= Migrating the {object_storage} to {rhos_long_noacro} nodes
99

1010
[role="_abstract"]
11-
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.
11+
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.
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 by using the `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 that are managed by the data plane operator.
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 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].
140+
141+
* *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].

‎docs_user/modules/proc_converting-object-storage-nodes.adoc‎

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

0 commit comments

Comments
 (0)