:_mod-docs-content-type: PROCEDURE
[id="adopting-the-loadbalancer-service_{context}"]

= Adopting the {loadbalancer_service}

[role="_abstract"]
To adopt the {loadbalancer_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. After completing the data plane adoption, you must trigger a failover of existing load balancers to upgrade their amphora VMs to use the new image and establish connectivity with the new control plane.

.Procedure

. Migrate the server certificate authority (CA) passphrase from the previous deployment:
+
----
include::../../tests/roles/octavia_adoption/tasks/octavia_certs.yaml[lines="6..16",indent=0]
----

. To isolate the management network, add the network interface for the VLAN base interface:
+
[subs="+quotes"]
----
$ oc get --no-headers nncp | cut -f 1 -d ' ' | grep -v nncp-dns | while read; do

interfaces=$(oc get nncp $REPLY -o jsonpath="{.spec.desiredState.interfaces[*].name}")

(echo $interfaces | grep -w -q "octbr\|enp6s0.24") || \
        oc patch nncp $REPLY --type json --patch '
[{
    "op": "add",
    "path": "/spec/desiredState/interfaces/-",
    "value": {
      "description": "Octavia VLAN host interface",
      "name": "enp6s0.24",
      "state": "up",
      "type": "vlan",
      "vlan": {
        "base-iface": "<enp6s0>",
        "id": 24
        }
    }
},
{
    "op": "add",
    "path": "/spec/desiredState/interfaces/-",
    "value": {
      "description": "Octavia Bridge",
      "mtu": <mtu>,
      "state": "up",
      "type": "linux-bridge",
      "name": "octbr",
      "bridge": {
        "options": { "stp": { "enabled": "false" } },
        "port": [ { "name": "enp6s0.24" } ]
        }
    }
}]'

done
----
+
where:

<enp6s0>::
Specifies the name of the network interface in your {OpenShiftShort} setup.
<mtu>::
Specifies the `mtu` value in your environment.

. To connect pods that manage load balancer virtual machines (amphorae) and the OpenvSwitch pods that are managed by the OVN operator, configure the {loadbalancer_service} network attachment definition:
+
----
$ cat  octavia-nad.yaml << EOF_CAT
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  labels:
    osp/net: octavia
  name: octavia
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "octavia",
      "type": "bridge",
      "bridge": "octbr",
      "ipam": {
        "type": "whereabouts",
        "range": "172.23.0.0/24",
        "range_start": "172.23.0.30",
        "range_end": "172.23.0.70",
        "routes": [
           {
             "dst": "172.24.0.0/16",
             "gw" : "172.23.0.150"
           }
         ]
      }
    }
EOF_CAT
$ oc apply -f octavia-nad.yaml
----

. Enable the {loadbalancer_service} in {OpenShiftShort}:
+
----
$ oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  ovn:
    template:
      ovnController:
        networkAttachment: tenant
        nicMappings:
          octavia: octbr
  octavia:
    enabled: true
    template:
      amphoraImageContainerImage: quay.io/gthiemonge/octavia-amphora-image
      octaviaHousekeeping:
        networkAttachments:
          - octavia
      octaviaHealthManager:
        networkAttachments:
          - octavia
      octaviaWorker:
        networkAttachments:
          - octavia
'
----

. Wait for the {loadbalancer_service} control plane services CRs to be ready:
+
----
$ oc wait --for condition=Ready --timeout=600s octavia.octavia.openstack.org/octavia
----

. Ensure that the {loadbalancer_service} is registered in the {identity_service}:
+
----
$ alias openstack="oc exec -t openstackclient -- openstack"
$ openstack service list | grep load-balancer
| bd078ca6f90c4b86a48801f45eb6f0d7 | octavia   | load-balancer |
$ openstack endpoint list --service load-balancer
+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+
| ID                               | Region    | Service Name | Service Type  | Enabled | Interface | URL                                               |
+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+
| f1ae7756b6164baf9cb82a1a670067a2 | regionOne | octavia      | load-balancer | True    | public    | https://octavia-public-openstack.apps-crc.testing |
| ff3222b4621843669e89843395213049 | regionOne | octavia      | load-balancer | True    | internal  | http://octavia-internal.openstack.svc:9876        |
+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+
----

.Post-adoption cleanup

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`.

----
$ alias openstack="oc exec -t openstackclient -- openstack"
$ openstack loadbalancer create --vip-subnet-id public-subnet --name lb-post-adoption --wait
----

After you complete the data plane adoption, perform the following cleanup steps to upgrade existing load balancers and remove old resources.

. Trigger a failover for all existing load balancers to upgrade the amphorae virtual machines to use the new image and establish connectivity with the new control plane:
+
----
$ openstack loadbalancer list -f value -c id | \
      xargs -n1 -P4 ${BASH_ALIASES[openstack]} loadbalancer failover --wait
----

. Delete old flavors that were migrated to the new control plane:
+
----
$ openstack flavor delete octavia_65
# The following flavors might not exist in OSP 17.1 deployments
$ openstack flavor show octavia_amphora-mvcpu-ha && \
  openstack flavor delete octavia_amphora-mvcpu-ha
$ openstack loadbalancer flavor show octavia_amphora-mvcpu-ha && \
  openstack loadbalancer flavor delete octavia_amphora-mvcpu-ha
$ openstack loadbalancer flavorprofile show octavia_amphora-mvcpu-ha_profile && \
  openstack loadbalancer flavorprofile delete octavia_amphora-mvcpu-ha_profile
----

[NOTE]
Some flavors may still be in-use by load balancers and cannot be deleted.

. Delete the old management network and its ports:
+
----
$ for net_id in $(openstack network list -f value -c ID --name lb-mgmt-net); do \
    desc=$(openstack network show "$net_id" -f value -c description); \
    [ -z "$desc" ] && WALLABY_LB_MGMT_NET_ID="$net_id" ; \
  done
$ for id in $(openstack port list --network "$WALLABY_LB_MGMT_NET_ID" -f value -c ID); do \
    openstack port delete "$id" ; \
  done
$ openstack network delete "$WALLABY_LB_MGMT_NET_ID"
----

. Verify that only one `lb-mgmt-net` and one `lb-mgmt-subnet` exists:
+
----
$ openstack network list | grep lb-mgmt-net
| fe470c29-0482-4809-9996-6d636e3feea3 | lb-mgmt-net          | 6a881091-097d-441c-937b-5a23f4f243b7 |
$ openstack subnet list | grep lb-mgmt-subnet
| 6a881091-097d-441c-937b-5a23f4f243b7 | lb-mgmt-subnet          | fe470c29-0482-4809-9996-6d636e3feea3 | 172.24.0.0/16   |
----