:_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. + [source, shell] ---- $ rm -f celltemplates for CELL in $(echo $RENAMED_CELLS); do $ cat >> celltemplates << EOF ${CELL}: hasAPIAccess: true <1> cellDatabaseAccount: nova-$CELL cellDatabaseInstance: openstack-$CELL <2> cellMessageBusInstance: rabbitmq-$CELL <3> 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 <4> 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 ---- + <1> 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. <2> 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]. <3> 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. <4> 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].