Skip to content

Commit dedf9bb

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. JIRA: OSPRH-23099 Signed-off-by: Christian Schwede <cschwede@redhat.com> Co-authored-by: Katie Gilligan <kgilliga@redhat.com>
1 parent 3e13597 commit dedf9bb

3 files changed

Lines changed: 300 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: 285 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,285 @@
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+
14+
Pre-provisioned nodes:: Setting `preProvisioned: true` in the
15+
`OpenStackDataPlaneNodeSet` custom resource (CR) skips provisioning the node from scratch and does 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.
19+
Existing disk mounts are 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` custom 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_hsm-integration[Adopting the
32+
{object_storage}].
33+
* Nodes cannot be members of more than one `OpenStackDataPlaneNodeSet` CR at
34+
the same time. If the nodes you want to convert were part of the node set
35+
that you created during the control plane adoption, delete that node set
36+
before proceeding:
37+
+
38+
----
39+
$ oc delete openstackdataplanenodeset <adoption-nodeset-name>
40+
----
41+
+
42+
where:
43+
44+
`<adoption-nodeset-name>`::
45+
Specifies the node set that you want to delete.
46+
47+
.Procedure
48+
49+
. Create a patch file to configure the {object_storage} data plane storage
50+
ports:
51+
+
52+
[NOTE]
53+
====
54+
The {OpenStackPreviousInstaller} deployment used different default
55+
ports: 6002 for the account server, 6001 for the container server, 6000 for
56+
the object server. The converted nodes must continue to use these same
57+
ports to ensure connectivity between all {object_storage} storage nodes by using
58+
the unmodified rings.
59+
====
60+
+
61+
----
62+
cat > swift-config-patch.yaml << EOF
63+
spec:
64+
swift:
65+
template:
66+
swiftStorage:
67+
defaultConfigOverwrite:
68+
01-account-server.conf: |
69+
[DEFAULT]
70+
bind_port = 6002
71+
01-container-server.conf: |
72+
[DEFAULT]
73+
bind_port = 6001
74+
01-object-server.conf: |
75+
[DEFAULT]
76+
bind_port = 6000
77+
EOF
78+
----
79+
+
80+
[NOTE]
81+
If you customized any {object_storage} service settings in the
82+
{OpenStackPreviousInstaller} deployment, include those settings as well. For
83+
example, if you changed the workers count or added additional configuration options
84+
for the account, container, or object services, add them to the
85+
corresponding section in the patch file.
86+
87+
. Apply the patch to the `OpenStackControlPlane` CR:
88+
+
89+
----
90+
$ oc patch openstackcontrolplane openstack --type=merge --patch-file=swift-config-patch.yaml
91+
----
92+
93+
. Create a `OpenStackDataPlaneService` CR to remove remaining
94+
{OpenStackPreviousInstaller} artifacts, such as containers, `systemd` units, and
95+
configuration, from the node:
96+
+
97+
----
98+
$ oc apply -f - <<EOF
99+
apiVersion: dataplane.openstack.org/v1beta1
100+
kind: OpenStackDataPlaneService
101+
metadata:
102+
name: tripleo-cleanup
103+
namespace: openstack
104+
spec:
105+
playbook: osp.edpm.tripleo_cleanup
106+
EOF
107+
----
108+
109+
ifeval::["{build}" == "upstream"]
110+
. Create a `OpenStackDataPlaneService` CR to configure RPM repositories on the node:
111+
+
112+
----
113+
$ oc apply -f - <<EOF
114+
apiVersion: dataplane.openstack.org/v1beta1
115+
kind: OpenStackDataPlaneService
116+
metadata:
117+
name: repo-setup
118+
namespace: openstack
119+
spec:
120+
addCertMounts: false
121+
caCerts: combined-ca-bundle
122+
edpmServiceType: repo-setup
123+
playbookContents: |
124+
- hosts: all
125+
strategy: linear
126+
tasks:
127+
- name: Enable podified-repos
128+
become: true
129+
ansible.builtin.shell: |
130+
# This needs rhos-release.rpm to be downloaded before or an
131+
# alternative way to use upstream repos
132+
dnf install -y /tmp/rhos-release.rpm
133+
rhos-release -x
134+
rhos-release 18.0
135+
EOF
136+
----
137+
endif::[]
138+
139+
. Create the `OpenStackDataPlaneNodeSet` CR that defines which nodes to convert and how to configure them:
140+
+
141+
[subs="+quotes"]
142+
----
143+
apiVersion: dataplane.openstack.org/v1beta1
144+
kind: OpenStackDataPlaneNodeSet
145+
metadata:
146+
name: openstack-edpm-ipam
147+
namespace: openstack
148+
spec:
149+
networkAttachments:
150+
- ctlplane
151+
- storage
152+
nodeTemplate:
153+
ansible:
154+
ansibleUser: cloud-admin
155+
ifeval::["{build}" == "downstream"]
156+
ansibleVarsFrom:
157+
- secretRef:
158+
name: subscription-manager
159+
- secretRef:
160+
name: redhat-registry
161+
endif::[]
162+
ansibleVars:
163+
edpm_nodes_validation_validate_controllers_icmp: false
164+
edpm_nodes_validation_validate_gateway_icmp: false
165+
edpm_service_removal_skip_list:
166+
- tripleo-container-shutdown.service
167+
edpm_sshd_allowed_ranges:
168+
- 192.168.122.0/24
169+
edpm_swift_disks: []
170+
enable_debug: false
171+
gather_facts: false
172+
timesync_ntp_servers:
173+
- hostname: pool.ntp.org
174+
ifeval::["{build}" != "downstream"]
175+
edpm_bootstrap_command: |
176+
# This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream
177+
set -euxo pipefail
178+
curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz
179+
python3 -m venv ./venv
180+
PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main
181+
# This is required for FIPS enabled until trunk.rdoproject.org
182+
# is not being served from a centos7 host, tracked by
183+
# https://issues.redhat.com/browse/RHOSZUUL-1517
184+
dnf -y install crypto-policies
185+
update-crypto-policies --set FIPS:NO-ENFORCE-EMS
186+
./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream
187+
dnf -y upgrade openstack-selinux
188+
rm -f /run/virtlogd.pid
189+
rm -rf repo-setup-main
190+
endif::[]
191+
ifeval::["{build}" == "downstream"]
192+
rhc_release: 9.2
193+
rhc_repositories:
194+
- {name: "*", state: disabled}
195+
- {name: "rhel-9-for-x86_64-baseos-eus-rpms", state: enabled}
196+
- {name: "rhel-9-for-x86_64-appstream-eus-rpms", state: enabled}
197+
- {name: "rhel-9-for-x86_64-highavailability-eus-rpms", state: enabled}
198+
- {name: "rhoso-18.0-for-rhel-9-x86_64-rpms", state: enabled}
199+
endif::[]
200+
ansibleSSHPrivateKeySecret: dataplane-adoption-secret
201+
managementNetwork: ctlplane
202+
nodes:
203+
edpm-swift-0:
204+
ansible:
205+
ansibleHost: 192.168.122.100
206+
ansibleVars:
207+
edpm_swift_disks: []
208+
hostName: edpm-swift-0
209+
networks:
210+
- defaultRoute: true
211+
fixedIP: 192.168.122.100
212+
name: ctlplane
213+
subnetName: subnet1
214+
- name: internalapi
215+
subnetName: subnet2
216+
- name: storage
217+
subnetName: subnet3
218+
- name: tenant
219+
subnetName: subnet4
220+
preProvisioned: true
221+
services:
222+
- bootstrap
223+
- download-cache
224+
- install-os
225+
- configure-os
226+
- ssh-known-hosts
227+
- run-os
228+
- reboot-os
229+
- install-certs
230+
- tripleo-cleanup
231+
- swift
232+
tlsEnabled: true
233+
----
234+
235+
. Apply the `OpenStackDataPlaneNodeSet` CR:
236+
+
237+
----
238+
$ oc apply -f nodeset.yaml
239+
----
240+
241+
. Create an `OpenStackDataPlaneDeployment` CR to trigger the Ansible pipeline on the node:
242+
+
243+
----
244+
$ oc apply -f - <<EOF
245+
apiVersion: dataplane.openstack.org/v1beta1
246+
kind: OpenStackDataPlaneDeployment
247+
metadata:
248+
name: openstack-edpm-ipam
249+
namespace: openstack
250+
spec:
251+
nodeSets:
252+
- openstack-edpm-ipam
253+
EOF
254+
----
255+
256+
. Wait for the deployment to complete:
257+
+
258+
----
259+
$ oc wait --for condition=Ready openstackdataplanedeployment/openstack-edpm-ipam --timeout=30m
260+
----
261+
262+
.. Monitor the progress:
263+
+
264+
----
265+
$ watch oc get pod -l app=openstackansibleee
266+
----
267+
+
268+
----
269+
$ oc logs -l app=openstackansibleee -f --max-log-requests 40
270+
----
271+
272+
.Verification
273+
274+
* Verify that the Object Storage services are running on the converted node:
275+
+
276+
----
277+
$ ssh cloud-admin@192.168.122.100 "sudo systemctl status edpm_swift_*"
278+
----
279+
280+
* Verify that the Object Storage services are functional after conversion, for
281+
example by uploading an object:
282+
+
283+
----
284+
$ oc rsh openstackclient /bin/sh -c "touch obj && openstack container create cont && openstack object create cont obj"
285+
----

0 commit comments

Comments
 (0)