Adopt the Compute service

Adopt the Compute service (nova) by patching the existing OpenStackControlPlane custom resource (CR) where the Compute service is disabled. The patch starts the service with the configuration parameters from Red Hat OpenStack Platform. This procedure describes a single-cell setup.

Before you begin

  • 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

  1. 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 RHOSP 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.
     
    $ 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 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.
  2. If you are adopting the Compute service with the Bare Metal Provisioning service (ironic), append the novaComputeTemplates field with the following content in each cell in the Compute service CR patch. For example: 
            cell1:
          novaComputeTemplates:
            standalone:
              customServiceConfig: |
                [DEFAULT]
                host = <hostname>
                [workarounds]
                disable_compute_service_check_for_ffu=true
              computeDriver: ironic.IronicDriver
        ...
    • Replace <hostname> with the hostname of the node that is running the ironic Compute driver in the source cloud.
  3. 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 Adopting Compute services to the RHOSO data plane and Performing a fast-forward upgrade on Compute services.

Results

  • 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
  • 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 cellXnova 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 Adopting Compute services to the RHOSO data plane.

 Important
To import external Compute services to the RHOSO data plane, you must upgrade them first. For more information, see Adopting Compute services to the RHOSO data plane, and Performing a fast-forward upgrade on Compute services.