Skip to content

Commit 54f161b

Browse files
openshift-merge-bot[bot]openshift-merge-bot[bot]
authored
Merge pull request #1237 from klgill/docs-move-clean-up-procedure
moved post-adoption clean-up to data plane chapter
2 parents f651445 + 0c85fb8 commit 54f161b

3 files changed

Lines changed: 71 additions & 54 deletions

File tree

‎docs_user/assemblies/assembly_adopting-the-data-plane.adoc‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,5 +30,7 @@ include::../modules/proc_adopting-networker-services-to-the-data-plane.adoc[leve
3030

3131
include::../modules/proc_enabling-high-availability-for-instances.adoc[leveloffset=+1]
3232

33+
include::../modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc[leveloffset=+1]
34+
3335
ifdef::parent-context[:context: {parent-context}]
3436
ifndef::parent-context[:!context:]

‎docs_user/modules/proc_adopting-the-loadbalancer-service.adoc‎

Lines changed: 2 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -151,58 +151,6 @@ $ openstack endpoint list --service load-balancer
151151
+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+
152152
----
153153

154-
.Post-adoption cleanup
154+
.Next steps
155155

156-
Before running the post-adoption cleanup, you can ensure that the connectivty between the new control plane and the adopted Compute nodes is functional by creating a new load balancer and checking that its `provisioning_status` becomes `ACTIVE`.
157-
158-
----
159-
$ alias openstack="oc exec -t openstackclient -- openstack"
160-
$ openstack loadbalancer create --vip-subnet-id public-subnet --name lb-post-adoption --wait
161-
----
162-
163-
After you complete the data plane adoption, perform the following cleanup steps to upgrade existing load balancers and remove old resources.
164-
165-
. Trigger a failover for all existing load balancers to upgrade the amphorae virtual machines to use the new image and to establish connectivity with the new control plane:
166-
+
167-
----
168-
$ openstack loadbalancer list -f value -c id | \
169-
xargs -r -n1 -P4 ${BASH_ALIASES[openstack]} loadbalancer failover --wait
170-
----
171-
172-
. Delete old flavors that were migrated to the new control plane:
173-
+
174-
----
175-
$ openstack flavor delete octavia_65
176-
# The following flavors might not exist in OSP 17.1 deployments
177-
$ openstack flavor show octavia_amphora-mvcpu-ha && \
178-
openstack flavor delete octavia_amphora-mvcpu-ha
179-
$ openstack loadbalancer flavor show octavia_amphora-mvcpu-ha && \
180-
openstack loadbalancer flavor delete octavia_amphora-mvcpu-ha
181-
$ openstack loadbalancer flavorprofile show octavia_amphora-mvcpu-ha_profile && \
182-
openstack loadbalancer flavorprofile delete octavia_amphora-mvcpu-ha_profile
183-
----
184-
+
185-
[NOTE]
186-
Some flavors might still be used by load balancers and cannot be deleted.
187-
188-
. Delete the old management network and its ports:
189-
+
190-
----
191-
$ for net_id in $(openstack network list -f value -c ID --name lb-mgmt-net); do \
192-
desc=$(openstack network show "$net_id" -f value -c description); \
193-
[ -z "$desc" ] && WALLABY_LB_MGMT_NET_ID="$net_id" ; \
194-
done
195-
$ for id in $(openstack port list --network "$WALLABY_LB_MGMT_NET_ID" -f value -c ID); do \
196-
openstack port delete "$id" ; \
197-
done
198-
$ openstack network delete "$WALLABY_LB_MGMT_NET_ID"
199-
----
200-
201-
. Verify that only one `lb-mgmt-net` and one `lb-mgmt-subnet` exists:
202-
+
203-
----
204-
$ openstack network list | grep lb-mgmt-net
205-
| fe470c29-0482-4809-9996-6d636e3feea3 | lb-mgmt-net | 6a881091-097d-441c-937b-5a23f4f243b7 |
206-
$ openstack subnet list | grep lb-mgmt-subnet
207-
| 6a881091-097d-441c-937b-5a23f4f243b7 | lb-mgmt-subnet | fe470c29-0482-4809-9996-6d636e3feea3 | 172.24.0.0/16 |
208-
----
156+
After you complete the data plane adoption, you must upgrade existing load balancers and remove old resources. For more information, see xref:performing-post-adoption-cleanup-of-load-balancers_data-plane[Post-adoption tasks for the {loadbalancer_service}].

‎docs_user/modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc‎

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
:_mod-docs-content-type: PROCEDURE
2+
[id="performing-post-adoption-cleanup-of-load-balancers_{context}"]
3+
4+
= Post-adoption tasks for the {loadbalancer_service}
5+
6+
[role="_abstract"]
7+
If you adopted the {loadbalancer_first_ref}, after you complete the data plane adoption, you must perform the following tasks:
8+
9+
* Upgrade the amphorae virtual machines to the new images.
10+
* Remove obsolete resources from your existing load balancers.
11+
12+
.Prerequisites
13+
* You have adopted the {loadbalancer_service}. For more information, see xref:adopting-the-loadbalancer-service_troubleshooting-hsm[Adopting the {loadbalancer_service}].
14+
15+
.Procedure
16+
17+
. Ensure that the connectivity between the new control plane and the adopted Compute nodes is functional by creating a new load balancer and checking that its `provisioning_status` becomes `ACTIVE`:
18+
+
19+
----
20+
$ alias openstack="oc exec -t openstackclient -- openstack"
21+
$ openstack loadbalancer create --vip-subnet-id public-subnet --name lb-post-adoption --wait
22+
----
23+
24+
. Trigger a failover for all existing load balancers to upgrade the amphorae virtual machines to use the new image and to establish connectivity with the new control plane:
25+
+
26+
----
27+
$ openstack loadbalancer list -f value -c id | \
28+
xargs -r -n1 -P4 ${BASH_ALIASES[openstack]} loadbalancer failover --wait
29+
----
30+
31+
. Delete old flavors that were migrated to the new control plane:
32+
+
33+
----
34+
$ openstack flavor delete octavia_65
35+
# The following flavors might not exist in OSP 17.1 deployments
36+
$ openstack flavor show octavia_amphora-mvcpu-ha && \
37+
openstack flavor delete octavia_amphora-mvcpu-ha
38+
$ openstack loadbalancer flavor show octavia_amphora-mvcpu-ha && \
39+
openstack loadbalancer flavor delete octavia_amphora-mvcpu-ha
40+
$ openstack loadbalancer flavorprofile show octavia_amphora-mvcpu-ha_profile && \
41+
openstack loadbalancer flavorprofile delete octavia_amphora-mvcpu-ha_profile
42+
----
43+
+
44+
[NOTE]
45+
Some flavors might still be used by load balancers and cannot be deleted.
46+
47+
. Delete the old management network and its ports:
48+
+
49+
----
50+
$ for net_id in $(openstack network list -f value -c ID --name lb-mgmt-net); do \
51+
desc=$(openstack network show "$net_id" -f value -c description); \
52+
[ -z "$desc" ] && WALLABY_LB_MGMT_NET_ID="$net_id" ; \
53+
done
54+
$ for id in $(openstack port list --network "$WALLABY_LB_MGMT_NET_ID" -f value -c ID); do \
55+
openstack port delete "$id" ; \
56+
done
57+
$ openstack network delete "$WALLABY_LB_MGMT_NET_ID"
58+
----
59+
60+
. Verify that only one `lb-mgmt-net` and one `lb-mgmt-subnet` exists:
61+
+
62+
----
63+
$ openstack network list | grep lb-mgmt-net
64+
| fe470c29-0482-4809-9996-6d636e3feea3 | lb-mgmt-net | 6a881091-097d-441c-937b-5a23f4f243b7 |
65+
$ openstack subnet list | grep lb-mgmt-subnet
66+
| 6a881091-097d-441c-937b-5a23f4f243b7 | lb-mgmt-subnet | fe470c29-0482-4809-9996-6d636e3feea3 | 172.24.0.0/16 |
67+
----

0 commit comments

Comments
 (0)