:_mod-docs-content-type: PROCEDURE [id="adopting-the-compute-service_{context}"] = Adopting the {compute_service} [role="_abstract"] To adopt the {compute_service_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. The following procedure describes a single-cell setup. //[NOTE] //The following example scenario describes a single-cell setup. Real //multi-stack topology that is recommended for production use results in cells having a different database layout, and should use different naming schemes. kgilliga: We might reinstate this note after multi-cell is finished in Feature Release 1. .Prerequisites * You have completed the previous adoption steps. * You have defined the following shell variables. Replace the following example values with the values that are correct for your environment: + ---- alias openstack="oc exec -t openstackclient -- openstack" DEFAULT_CELL_NAME="cell3" RENAMED_CELLS="cell1 cell2 $DEFAULT_CELL_NAME" ---- + ** The source cloud `default` cell takes a new `$DEFAULT_CELL_NAME`. In a multi-cell adoption scenario, the 'default' cell might retain its original name,`DEFAULT_CELL_NAME=default`, or become renamed as a cell that is free for use. Do not use other existing cell names for `DEFAULT_CELL_NAME`, except for `default`. ** If you deployed the source cloud with a `default` cell, and want to rename it during adoption, define the new name that you want to use, as shown in the following example: + ---- DEFAULT_CELL_NAME="cell1" RENAMED_CELLS="cell1" ---- .Procedure . Patch the `OpenStackControlPlane` CR to deploy the {compute_service}: + [NOTE] This procedure assumes that {compute_service} metadata is deployed on the top level and not on each cell level. If the {OpenStackShort} deployment has a per-cell metadata deployment, adjust the following patch as needed. You cannot run the metadata service in `cell0`. To enable the metadata services of a local cell, set the `enabled` property in the `metadataServiceTemplate` field of the local cell to `true` in the `OpenStackControlPlane` CR. + [subs="+quotes"] ---- $ rm -f celltemplates $ for CELL in $(echo $RENAMED_CELLS); do $ cat >> celltemplates << EOF > ${CELL}: > *hasAPIAccess: true* > cellDatabaseAccount: nova-$CELL > *cellDatabaseInstance: openstack-$CELL* > *cellMessageBusInstance: rabbitmq-$CELL* > metadataServiceTemplate: > enabled: false > override: > service: > metadata: > annotations: > metallb.universe.tf/address-pool: internalapi > metallb.universe.tf/allow-shared-ip: internalapi > metallb.universe.tf/loadBalancerIPs: 172.17.0.$(( 79 + ${CELL##*cell} )) > spec: > type: LoadBalancer > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true > conductorServiceTemplate: > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true >EOF >done $ cat > oscp-patch.yaml << EOF >spec: > nova: > enabled: true > apiOverride: > route: {} > template: > secret: osp-secret > apiDatabaseAccount: nova-api > apiServiceTemplate: > override: > service: > internal: > metadata: > annotations: > metallb.universe.tf/address-pool: internalapi > metallb.universe.tf/allow-shared-ip: internalapi > metallb.universe.tf/loadBalancerIPs: <172.17.0.80> > spec: > type: LoadBalancer > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true > metadataServiceTemplate: > enabled: true > override: > service: > metadata: > annotations: > metallb.universe.tf/address-pool: internalapi > metallb.universe.tf/allow-shared-ip: internalapi > metallb.universe.tf/loadBalancerIPs: <172.17.0.80> > spec: > type: LoadBalancer > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true > schedulerServiceTemplate: > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true > cellTemplates: > cell0: > hasAPIAccess: true > cellDatabaseAccount: nova-cell0 > cellDatabaseInstance: openstack > cellMessageBusInstance: rabbitmq > conductorServiceTemplate: > customServiceConfig: | > [workarounds] > disable_compute_service_check_for_ffu=true >EOF $ cat celltemplates >> oscp-patch.yaml $ oc patch openstackcontrolplane openstack --type=merge --patch-file=oscp-patch.yaml ---- + * `${CELL}.hasAPIAccess` specifies upcall access to the API. In the source cloud, cells are always configured with the main Nova API database upcall access. You can disable upcall access to the API by setting `hasAPIAccess` to `false`. However, do not make changes to the API during adoption. * `${CELL}.cellDatabaseInstance` specifies the database instance that is used by the cell. The database instance names must match the names that are defined in the `OpenStackControlPlane` CR that you created in when you deployed the back-end services as described in xref:deploying-backend-services__migrating-databases[Deploying back-end services]. * `${CELL}.cellMessageBusInstance` specifies the message bus instance that is used by the cell. The message bus instance names must match the names that are defined in the `OpenStackControlPlane` CR. * `metallb.universe.tf/loadBalancerIPs: <172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. . If you are adopting the {compute_service} with the {bare_metal_first_ref}, append the `novaComputeTemplates` field with the following content in each cell in the {compute_service} CR patch. For example: + [source,yaml] ---- cell1: novaComputeTemplates: standalone: customServiceConfig: | [DEFAULT] host = [workarounds] disable_compute_service_check_for_ffu=true computeDriver: ironic.IronicDriver ... ---- + * Replace `` with the hostname of the node that is running the `ironic` Compute driver in the source cloud. . Wait for the CRs for the Compute control plane services to be ready: + ---- $ oc wait --for condition=Ready --timeout=300s Nova/nova ---- + [NOTE] The local Conductor services are started for each cell, while the superconductor runs in `cell0`. Note that `disable_compute_service_check_for_ffu` is mandatory for all imported Compute services until the external data plane is imported, and until the Compute services are fast-forward upgraded. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane] and xref:performing-a-fast-forward-upgrade-on-compute-services_data-plane[Upgrading Compute services]. .Verification * Check that {compute_service} endpoints are defined and pointing to the control plane FQDNs, and that the Nova API responds: + ---- $ openstack endpoint list | grep nova $ openstack server list ---- + ** Compare the outputs with the topology-specific configuration in xref:proc_retrieving-topology-specific-service-configuration_migrating-databases[Retrieving topology-specific service configuration]. * Query the superconductor to check that the expected cells exist, and compare it to its pre-adoption values: + ---- $ for CELL in $(echo $CELLS); do > set +u > . ~/.source_cloud_exported_variables_$CELL > set -u > RCELL=$CELL > [ "$CELL" = "default" ] && RCELL=$DEFAULT_CELL_NAME > > echo "comparing $CELL to $RCELL" > echo $PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS | grep -F "| $CELL |" > oc rsh nova-cell0-conductor-0 nova-manage cell_v2 list_cells | grep -F "| $RCELL |" > done ---- + The following changes are expected for each cell: + ** The `cellX` `nova` database and username become `nova_cellX`. ** The `default` cell is renamed to `DEFAULT_CELL_NAME`. The `default` cell might retain the original name if there are multiple cells. ** The RabbitMQ transport URL no longer uses `guest`. [NOTE] ==== At this point, the {compute_service} control plane services do not control the existing {compute_service} workloads. The control plane manages the data plane only after the data adoption process is completed. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane]. ==== [IMPORTANT] To import external Compute services to the {rhos_acro} data plane, you must upgrade them first. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane], and xref:performing-a-fast-forward-upgrade-on-compute-services_data-plane[Performing a fast-forward upgrade on Compute services].