:_mod-docs-content-type: PROCEDURE
[id="rolling-back-control-plane-adoption_{context}"]

= Rolling back the control plane adoption

[role="_abstract"]
If you encountered a problem and are unable to complete the adoption of the {rhos_prev_long} ({OpenStackShort}) control plane services, you can roll back the control plane adoption.

[IMPORTANT]
Do not attempt the rollback if you altered the data plane nodes in any way.
You can only roll back the control plane adoption if you altered the control plane.

During the control plane adoption, services on the {OpenStackShort} control plane are stopped but not removed. The databases on the {OpenStackShort} control plane are not edited during the adoption procedure. The {rhos_long} control plane receives a copy of the original control plane databases. The rollback procedure assumes that the data plane has not yet been modified by the adoption procedure, and it is still connected to the {OpenStackShort} control plane.

The rollback procedure consists of the following steps:

* Restoring the functionality of the {OpenStackShort} control plane.

* Removing the partially or fully deployed {rhos_acro} control plane.

.Procedure

. To restore the source cloud to a working state, start the {OpenStackShort}
control plane services that you previously stopped during the adoption
procedure:
+
----
ServicesToStart=("tripleo_horizon.service"
                 "tripleo_keystone.service"
                 "tripleo_barbican_api.service"
                 "tripleo_barbican_worker.service"
                 "tripleo_barbican_keystone_listener.service"
                 "tripleo_cinder_api.service"
                 "tripleo_cinder_api_cron.service"
                 "tripleo_cinder_scheduler.service"
                 "tripleo_cinder_volume.service"
                 "tripleo_cinder_backup.service"
                 "tripleo_glance_api.service"
                 "tripleo_manila_api.service"
                 "tripleo_manila_api_cron.service"
                 "tripleo_manila_scheduler.service"
                 "tripleo_neutron_api.service"
                 "tripleo_placement_api.service"
                 "tripleo_nova_api_cron.service"
                 "tripleo_nova_api.service"
                 "tripleo_nova_conductor.service"
                 "tripleo_nova_metadata.service"
                 "tripleo_nova_scheduler.service"
                 "tripleo_nova_vnc_proxy.service"
                 "tripleo_aodh_api.service"
                 "tripleo_aodh_api_cron.service"
                 "tripleo_aodh_evaluator.service"
                 "tripleo_aodh_listener.service"
                 "tripleo_aodh_notifier.service"
                 "tripleo_ceilometer_agent_central.service"
                 "tripleo_ceilometer_agent_compute.service"
                 "tripleo_ceilometer_agent_ipmi.service"
                 "tripleo_ceilometer_agent_notification.service"
                 "tripleo_ovn_cluster_north_db_server.service"
                 "tripleo_ovn_cluster_south_db_server.service"
                 "tripleo_ovn_cluster_northd.service"
                 "tripleo_octavia_api.service"
                 "tripleo_octavia_health_manager.service"
                 "tripleo_octavia_rsyslog.service"
                 "tripleo_octavia_driver_agent.service"
                 "tripleo_octavia_housekeeping.service"
                 "tripleo_octavia_worker.service")

PacemakerResourcesToStart=("galera-bundle"
                           "haproxy-bundle"
                           "rabbitmq-bundle"
                           "openstack-cinder-volume"
                           "openstack-cinder-backup"
                           "openstack-manila-share")

echo "Starting systemd OpenStack services"
for service in ${ServicesToStart[*]}; do
    for i in {1..3}; do
        SSH_CMD=CONTROLLER${i}_SSH
        if [ ! -z "${!SSH_CMD}" ]; then
            if ${!SSH_CMD} sudo systemctl is-enabled $service &> /dev/null; then
                echo "Starting the $service in controller $i"
                ${!SSH_CMD} sudo systemctl start $service
            fi
        fi
    done
done

echo "Checking systemd OpenStack services"
for service in ${ServicesToStart[*]}; do
    for i in {1..3}; do
        SSH_CMD=CONTROLLER${i}_SSH
        if [ ! -z "${!SSH_CMD}" ]; then
            if ${!SSH_CMD} sudo systemctl is-enabled $service &> /dev/null; then
                if ! ${!SSH_CMD} systemctl show $service | grep ActiveState=active >/dev/null; then
                    echo "ERROR: Service $service is not running on controller $i"
                else
                    echo "OK: Service $service is running in controller $i"
                fi
            fi
        fi
    done
done

echo "Starting pacemaker OpenStack services"
for i in {1..3}; do
    SSH_CMD=CONTROLLER${i}_SSH
    if [ ! -z "${!SSH_CMD}" ]; then
        echo "Using controller $i to run pacemaker commands"
        for resource in ${PacemakerResourcesToStart[*]}; do
            if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then
                echo "Starting $resource"
                ${!SSH_CMD} sudo pcs resource enable $resource
            else
                echo "Service $resource not present"
            fi
        done
        break
    fi
done

echo "Checking pacemaker OpenStack services"
for i in {1..3}; do
    SSH_CMD=CONTROLLER${i}_SSH
    if [ ! -z "${!SSH_CMD}" ]; then
        echo "Using controller $i to run pacemaker commands"
        for resource in ${PacemakerResourcesToStop[*]}; do
            if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then
                if ${!SSH_CMD} sudo pcs resource status $resource | grep Started >/dev/null; then
                    echo "OK: Service $resource is started"
                else
                    echo "ERROR: Service $resource is stopped"
                fi
            fi
        done
        break
    fi
done
----

. If the Ceph NFS service is running on the deployment as a {rhos_component_storage_file_first_ref} back end, you must restore the Pacemaker order and colocation constraints for the `openstack-manila-share` service:
+
----

$ sudo pcs constraint order start ceph-nfs then openstack-manila-share kind=Optional id=order-ceph-nfs-openstack-manila-share-Optional
$ sudo pcs constraint colocation add openstack-manila-share with ceph-nfs score=INFINITY id=colocation-openstack-manila-share-ceph-nfs-INFINITY

----

. Verify that the source cloud is operational again, for example, you
can run `openstack` CLI commands such as `openstack server list`, or check that you can access the {dashboard_first_ref}.

. Remove the partially or fully deployed control plane so that you can attempt the adoption again later:
+
----
$ oc delete --ignore-not-found=true --wait=false openstackcontrolplane/openstack
$ oc patch openstackcontrolplane openstack --type=merge --patch '
metadata:
  finalizers: []
' || true

while oc get pod | grep rabbitmq-server-0; do
    sleep 2
done
while oc get pod | grep openstack-galera-0; do
    sleep 2
done

$ oc delete --ignore-not-found=true --wait=false pod mariadb-copy-data
$ oc delete --ignore-not-found=true --wait=false pvc mariadb-data
$ oc delete --ignore-not-found=true --wait=false pod ovn-copy-data
$ oc delete --ignore-not-found=true secret osp-secret
----

.Next steps

After you restore the {OpenStackShort} control plane services, their internal
state might have changed. Before you retry the adoption procedure, verify that all the control plane resources are removed and that there are no leftovers which could affect the following adoption procedure attempt. You must not use previously created copies of the database contents in another adoption attempt. You must make a new copy of the latest state of the original source database contents. For more information about making new copies of the database, see xref:migrating-databases-to-the-control-plane_configuring-network[Migrating databases to the control plane].