Configuring the Bare Metal Provisioning service

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Create the network over which to provision bare-metal instances:

   $ openstack network create \
     --provider-network-type <network_type> \
     [--provider-segment <vlan_id>] \
     --provider-physical-network <provider_physical_network> \
     --share <network_name>

   • Replace <network_type> with the type of network, either flat or vlan.
   • Optional: If your network type is vlan then specify the --provider-segment.
   • Replace <provider_physical_network> with the name of the physical network over which you implement the virtual network, which is the bridge mapping configured for the OVN service on the control plane.
   • Replace <network_name> with a name for this network.

3. Create the subnet on the network:

   $ openstack subnet create \
     --network <network_name> \
     --subnet-range <network_cidr> \
     --ip-version 4 \
     --gateway <gateway_ip> \
     --allocation-pool start=<start_ip>,end=<end_ip> \
     --dhcp <subnet_name>
     --dns-nameserver <dns_ip>

   • Replace <network_name> with the name of the provisioning network that you created in the previous step.
   • Replace <network_cidr> with the CIDR representation of the block of IP addresses that the subnet represents. The block of IP addresses that you specify in the range starting with <start_ip> and ending with <end_ip> must be within the block of IP addresses specified by <network_cidr>.
   • Replace <gateway_ip> with the IP address or host name of the router interface that acts as the gateway for the new subnet. This address must be within the block of IP addresses specified by <network_cidr>, but outside of the block of IP addresses specified by the range that starts with <start_ip> and ends with <end_ip>.
   • Replace <start_ip> with the IP address that denotes the start of the range of IP addresses within the new subnet from which floating IP addresses are allocated.
   • Replace <end_ip> with the IP address that denotes the end of the range of IP addresses within the new subnet from which floating IP addresses are allocated.
   • Replace <subnet_name> with a name for the subnet.
   • Replace <dns_ip> with the IP address of the load balancer configured for the DNS service on the control plane.

4. Create a router for the network and subnet to ensure that the Networking service serves metadata requests:

   $ openstack router create <router_name>

   • Replace <router_name> with a name for the router.

5. Attach the subnet to the new router to enable the metadata requests from cloud-init to be served and the node to be configured:

   $ openstack router add subnet <router_name> <subnet>

   • Replace <router_name> with the name of your router.
   • Replace <subnet> with the ID or name of the bare-metal subnet that you created in step 3.

6. Exit the openstackclient pod:

   $ exit

Procedure

1. Open your OpenStackControlPlane custom resource (CR) file, openstack_control_plane.yaml, on your workstation.

2. Add the following cellTemplates configuration to the nova service configuration:

     nova:
       apiOverride:
         route: {}
       template:
         ...
         secret: osp-secret
         cellTemplates:
           cell0:
             cellDatabaseAccount: nova-cell0
             hasAPIAccess: true
           cell1:
             cellDatabaseAccount: nova-cell1
             cellDatabaseInstance: openstack-cell1
             cellMessageBusInstance: rabbitmq-cell1
             hasAPIAccess: true
             novaComputeTemplates:
               compute-ironic: 

   1

   
                 computeDriver: ironic.IronicDriver

   1

   The name of the Compute service. The name has a limit of 20 characters, and must contain only lowercase alphanumeric characters and the - symbol.

3. Enable the ironic service and specify the networks to connect to:

   spec:
     ...
     ironic:
       enabled: true
       template:
         rpcTransport: oslo
         databaseInstance: openstack
         ironicAPI:
           replicas: 1
           override:
             service:
               internal:
                 metadata:
                   annotations:
                     metallb.universe.tf/address-pool: ctlplane
                     metallb.universe.tf/allow-shared-ip: ctlplane
                     metallb.universe.tf/loadBalancerIPs: 192.168.122.80
                 spec:
                   type: LoadBalancer
         ironicConductors:
         - replicas: 1
           storageRequest: 10G
           networkAttachments:
           - baremetal 

   1

   
           provisionNetwork: baremetal 

   2

   
         ironicInspector:
           replicas: 0 

   3

   
           networkAttachments:
           - baremetal 

   4

   
           inspectionNetwork: baremetal 

   5

   
         ironicNeutronAgent:
           replicas: 1
         secret: osp-secret

   1

   The name of the NetworkAttachmentDefinition CR you created for your isolated bare-metal network in Preparing RHOCP for bare-metal networks to use for the ironicConductor pods.

   2

   The name of the Networking service (neutron) network you created for use as the provisioning network in Creating the bare-metal network.

   3

   You can deploy the Bare Metal Provisioning service without the ironicInspector service. To deploy the service, set the number of replicas to 1.

   4

   The name of the NetworkAttachmentDefinition CR you created for your isolated bare-metal network in Preparing RHOCP for bare-metal networks to use for the ironicInspector pod.

   5

   The name of the Networking service (neutron) network you created for use as the inspection network in Creating the bare-metal network. The Ironic Inspector API listens on port 5050.

4. Specify the networks the Bare Metal Provisioning service uses for provisioning, cleaning, inspection, and rescuing bare-metal nodes:

   spec:
     ...
     ironic:
       ...
         ironicConductors:
         - replicas: 1
           storageRequest: 10G
           networkAttachments:
           - baremetal
           provisionNetwork: baremetal
           customServiceConfig: |
             [neutron]
             cleaning_network = <network_UUID>
             provisioning_network = <network_UUID>
             inspection_network = <network_UUID>
             rescuing_network = <network_UUID>

   • Replace <network_UUID> with the UUID of the network you created in Creating the bare-metal network for the function.

5. Configure the OVN mappings:

     ovn:
       template:
         ovnController:
           ...
           nicMappings: 

   1

   
             datacentre: ocpbr
             baremetal: baremetal

   1

   List of key-value pairs that map the physical network provider to the interface name defined in the NodeNetworkConfigurationPolicy (nncp) CR.

6. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

7. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status:

   $ oc get openstackcontrolplane -n openstack
   NAME 						STATUS 	MESSAGE
   openstack-control-plane 	Unknown 	Setup started

   The OpenStackControlPlane resources are created when the status is "Setup complete".

   Tip

   Append the -w option to the end of the get command to track deployment progress.

8. Confirm that the control plane is deployed by reviewing the pods in the openstack namespace:

   $ oc get pods -n openstack

   The control plane is deployed when all the pods are either completed or running.

Verification

1. Open a remote shell connection to the OpenStackClient pod:

   $ oc rsh -n openstack openstackclient

2. Confirm that the internal service endpoints are registered with each service:

   $ openstack endpoint list -c 'Service Name' -c Interface -c URL --service ironic
   +--------------+-----------+---------------------------------------------------------------+
   | Service Name | Interface | URL                                                           |
   +--------------+-----------+---------------------------------------------------------------+
   | ironic       | internal  | http://ironic-internal.openstack.svc:9292                     |
   | ironic       | public    | http://ironic-public-openstack.apps.ostest.test.metalkube.org |
   +--------------+-----------+---------------------------------------------------------------+

3. Exit the openstackclient pod:

   $ exit

Procedure

1. Open your OpenStackControlPlane custom resource (CR) file, openstack_control_plane.yaml, on your workstation.

2. Add the following configuration options to the customServiceConfig parameter in the ironicConductors template to configure how node event history records are managed:

   spec:
     ...
     ironic:
       enabled: true
       template:
         rpcTransport: oslo
         databaseInstance: openstack
         ironicAPI:
           ...
         ironicConductors:
         - replicas: 1
           storageRequest: 10G
           networkAttachments:
           - baremetal
           provisionNetwork: baremetal
           customServiceConfig: |
             ...
             [conductor]
             node_history_max_entries=<max_entries>
             node_history_cleanup_interval=<clean_interval>
             node_history_cleanup_batch_count=<max_purge>
             node_history_minimum_days=<min_days>
         ...
         secret: osp-secret

   • Optional: Replace <max_entries> with the maximum number of event records that the Bare Metal Provisioning service records. The oldest recorded events are removed when the maximum number of entries is reached. By default, a maximum of 300 events are recorded. The minimum valid value is 0.
   • Optional: Replace <clean_interval> with the interval in seconds between scheduled cleanup of the node event history entries. By default, the cleanup is scheduled every 86400 seconds, which is once daily. Set to 0 to disable node event history cleanup.
   • Optional: Replace <max_purge> with the maximum number of entries to purge during each clean up operation. Defaults to 1000.
   • Optional: Replace <min_days> with the minimum number of days to explicitly keep the database history entries for nodes. Defaults to 0.

3. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

4. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status:

   $ oc get openstackcontrolplane -n openstack
   NAME 						STATUS 	MESSAGE
   openstack-control-plane 	Unknown 	Setup started

   The OpenStackControlPlane resources are created when the status is "Setup complete".

   Tip

   Append the -w option to the end of the get command to track deployment progress.

5. Confirm that the control plane is deployed by reviewing the pods in the openstack namespace:

   $ oc get pods -n openstack

   The control plane is deployed when all the pods are either completed or running.

Procedure

1. Create an inventory file to define the details of each node, for example, ironic-nodes.yaml.

2. For each node, define the node name and the address and credentials for the bare-metal driver. For details on the available properties for your enabled driver, see Bare metal drivers.

   nodes:
     - name: <node>
       driver: <driver>
       driver_info:
         <driver>_address: <ip>
         <driver>_username: <user>
         <driver>_password: <password>
         [<property>: <value>]

   • Replace <node> with the name of the node.
   • Replace <driver> with a supported bare-metal driver, for example,redfish.
   • Replace <ip> with the IP address of the Bare Metal controller.
   • Replace <user> with your username.
   • Replace <password> with your password.
   • Optional: Replace <property> with a driver property that you want to configure, and replace <value> with the value of the property. For information on the available properties, see Bare metal drivers.

3. Define the node properties and ports:

   nodes:
     - name: <node>
       ...
       properties:
         cpus: <cpu_count>
         cpu_arch: <cpu_arch>
         memory_mb: <memory>
         local_gb: <root_disk>
         root_device:
           serial: <serial>
         network_interface: <interface_type>
       ports:
         - address: <mac_address>

   • Replace <cpu_count> with the number of CPUs.
   • Replace <cpu_arch> with the type of architecture of the CPUs.
   • Replace <memory> with the amount of memory in MiB.
   • Replace <root_disk> with the size of the root disk in GiB. Only required when the machine has multiple disks.
   • Replace <serial> with the serial number of the disk that you want to use for deployment.

   • Optional: Include the network_interface property if you want to override the default network type of flat. You can change the network type to one of the following valid values:

     • neutron: Use to provide tenant-defined networking through the Networking service, where tenant networks are separated from each other and from the provisioning and cleaning provider networks. Required to create a provisioning network with IPv6.
     • noop: Use for standalone deployments where network switching is not required.
   • Replace <mac_address> with the MAC address of the NIC used to PXE boot.

4. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

5. Import the inventory file into the Bare Metal Provisioning service:

   $ openstack baremetal create ironic-nodes.yaml

   The nodes are now in the enroll state.

6. Wait for the extra network interface port configuration data to populate the Networking service (neutron). This process takes at least 60 seconds.

7. Set the provisioning state of each node to available:

   $ openstack baremetal node manage <node>
   $ openstack baremetal node provide <node>

   The Bare Metal Provisioning service cleans the node if you enabled node cleaning.

8. Check that the nodes are enrolled:

   $ openstack baremetal node list

   There might be a delay between enrolling a node and its state being shown.

9. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Add a new node:

   $ openstack baremetal node create --driver <driver_name> --name <node_name>

   • Replace <driver_name> with the name of the driver, for example, redfish.
   • Replace <node_name> with the name of your new bare-metal node.
3. Note the UUID assigned to the node when it is created.

4. Update the node properties to match the hardware specifications on the node:

   $ openstack baremetal node set <node> \
     --property cpus=<cpu> \
     --property memory_mb=<ram> \
     --property local_gb=<disk> \
     --property cpu_arch=<arch>

   • Replace <node> with the ID of the bare metal node.
   • Replace <cpu> with the number of CPUs.
   • Replace <ram> with the RAM in MB.
   • Replace <disk> with the disk size in GB.
   • Replace <arch> with the architecture type.

5. Optional: Set the network_interface property to override the default network type of flat:

   $ openstack baremetal node set <node> --network-interace <network_interface>

   • Replace <network_interface> with one of the following valid network types:

     • neutron: Use to provide tenant-defined networking through the Networking service, where tenant networks are separated from each other and from the provisioning and cleaning provider networks. Required to create a provisioning network with IPv6.
     • noop: Use for standalone deployments where network switching is not required.

6. Optional: If you have multiple disks, set the root device hints to inform the deploy ramdisk which disk to use for deployment:

   $ openstack baremetal node set <node> \
     --property root_device='{"<property>": "<value>"}'

   • Replace <node> with the ID of the bare metal node.

   • Replace <property> and <value> with details about the disk that you want to use for deployment, for example root_device='{"size": "128"}'

     RHOSP supports the following properties:

     • model (String): Device identifier.
     • vendor (String): Device vendor.
     • serial (String): Disk serial number.
     • hctl (String): Host:Channel:Target:Lun for SCSI.
     • size (Integer): Size of the device in GB.
     • wwn (String): Unique storage identifier.
     • wwn_with_extension (String): Unique storage identifier with the vendor extension appended.
     • wwn_vendor_extension (String): Unique vendor storage identifier.
     • rotational (Boolean): True for a rotational device (HDD), otherwise false (SSD).

     • name (String): The name of the device, for example: /dev/sdb1 Use this property only for devices with persistent names.

       Note

       If you specify more than one property, the device must match all of those properties.

7. Inform the Bare Metal Provisioning service of the node network card by creating a port with the MAC address of the NIC on the provisioning network:

   $ openstack baremetal port create --node <node_uuid> <mac_address>

   • Replace <node> with the unique ID of the bare metal node.
   • Replace <mac_address> with the MAC address of the NIC used to PXE boot.

8. Validate the configuration of the node:

   $ openstack baremetal node validate <node>
   +------------+--------+---------------------------------------------+
   | Interface  | Result | Reason                                      |
   +------------+--------+---------------------------------------------+
   | boot       | False  | Cannot validate image information for node  |
   |            |        | a02178db-1550-4244-a2b7-d7035c743a9b        |
   |            |        | because one or more parameters are missing  |
   |            |        | from its instance_info. Missing are:        |
   |            |        | ['ramdisk', 'kernel', 'image_source']       |
   | console    | None   | not supported                               |
   | deploy     | False  | Cannot validate image information for node  |
   |            |        | a02178db-1550-4244-a2b7-d7035c743a9b        |
   |            |        | because one or more parameters are missing  |
   |            |        | from its instance_info. Missing are:        |
   |            |        | ['ramdisk', 'kernel', 'image_source']       |
   | inspect    | None   | not supported                               |
   | management | True   |                                             |
   | network    | True   |                                             |
   | power      | True   |                                             |
   | raid       | True   |                                             |
   | storage    | True   |                                             |
   +------------+--------+---------------------------------------------+

   The validation output Result indicates the following:

   • False: The interface has failed validation. If the reason provided includes missing the instance_info parameters [\'ramdisk', \'kernel', and \'image_source'], this might be because the Compute service populates those missing parameters at the beginning of the deployment process, therefore they have not been set at this point. If you are using a whole disk image, then you might need to only set image_source to pass the validation.
   • True: The interface has passed validation.
   • None: The interface is not supported for your driver.

9. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Set the Bare Metal service boot interface to redfish-virtual-media:

   $ openstack baremetal node set --boot-interface redfish-virtual-media <node_name>

   • Replace <node_name> with the name of the node.

3. For UEFI nodes, define the EFI System Partition (ESP) image:

   $ openstack baremetal node set --driver-info bootloader=<esp_image> <node>

   • Replace <esp_image> with the image UUID or URL for the ESP image.
   • Replace <node> with the name of the node.
   Note

   For BIOS nodes, do not complete this step.

4. Create a port on the bare-metal node and associate the port with the MAC address of the NIC on the bare metal node:

   $ openstack baremetal port create --pxe-enabled True --node <node_uuid> <mac_address>

   • Replace <node_uuid> with the UUID of the bare-metal node.
   • Replace <mac_address> with the MAC address of the NIC on the bare-metal node.

5. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Retrieve a list of your nodes to identify their UUIDs:

   $ openstack baremetal node list

3. Tag each bare-metal node with a custom bare-metal resource class:

   $ openstack baremetal node set \
    --resource-class baremetal.<CUSTOM> <node>

   • Replace <CUSTOM> with a string that identifies the purpose of the resource class. For example, set to GPU to create a custom GPU resource class that you can use to tag bare metal nodes that you want to designate for GPU workloads.
   • Replace <node> with the ID of the bare metal node.

4. Create a flavor for bare-metal instances:

   $ openstack flavor create --id auto \
    --ram <ram_size_mb> --disk <disk_size_gb> \
    --vcpus <no_vcpus> baremetal

   • Replace <ram_size_mb> with the RAM of the bare metal node, in MB.
   • Replace <disk_size_gb> with the size of the disk on the bare metal node, in GB.

   • Replace <no_vcpus> with the number of CPUs on the bare metal node.

     Note

     These properties are not used for scheduling instances. However, the Compute scheduler does use the disk size to determine the root partition size.

5. Associate the flavor for bare-metal instances with the custom resource class:

   $ openstack flavor set \
    --property resources:CUSTOM_BAREMETAL_<CUSTOM>=1 \
    baremetal

   To determine the name of a custom resource class that corresponds to a resource class of a bare-metal node, convert the resource class to uppercase, replace each punctuation mark with an underscore, and prefix with CUSTOM_.

   Note

   A flavor can request only one instance of a bare-metal resource class.

6. Set the following flavor properties to prevent the Compute scheduler from using the bare-metal flavor properties to schedule instances:

   $ openstack flavor set \
    --property resources:VCPU=0 \
    --property resources:MEMORY_MB=0 \
    --property resources:DISK_GB=0 baremetal

7. Verify that the new flavor has the correct values:

   $ openstack flavor list

8. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Create the bare-metal instance:

   $ openstack server create \
    --nic net-id=<network_uuid> \
    --flavor baremetal \
    --image <image_uuid> \
    myBareMetalInstance

   • Replace <network_uuid> with the unique identifier for the network that you created to use with the Bare Metal Provisioning service.
   • Replace <image_uuid> with the unique identifier for the image that has the software profile that your instance requires.

3. Check the status of the instance:

   $ openstack server list --name myBareMetalInstance

4. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Specify ramdisk as the deploy interface for the bare-metal node that boots from an ISO image:

   $ openstack baremetal node set --deploy-interface ramdisk

   Tip

   You can configure the deploy interface when you create the bare-metal node by adding --deploy-interface ramdisk to the openstack baremetal node create command. For information on how to create a bare-metal node, see Enrolling a bare-metal node manually.

3. Update the bare-metal node to boot an ISO image:

   $ openstack baremetal node set <node_UUID> \
       --instance-info boot_iso=<boot_iso_url>

   • Replace <node_UUID> with the UUID of the bare-metal node that you want to boot from an ISO image.

   • Replace <boot_iso_url> with the URL of the boot ISO file. You can specify the boot ISO file URL by using one of the following methods:

     • HTTP or HTTPS URL
     • File path URL
     • Image service (glance) object UUID

4. Deploy the bare-metal node as an ISO image:

   $ openstack baremetal node deploy <node_UUID>

5. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Check the current state of the node:

   $ openstack baremetal node show \
    -f value -c provision_state <node>

   • Replace <node> with the name or UUID of the node to clean.

3. If the node is not in the manageable state, then set it to manageable:

   $ openstack baremetal node manage <node>

4. Clean the node:

   $ openstack baremetal node clean <node> \
     --clean-steps '[{"interface": "deploy", "step": "<clean_mode>"}]'

   • Replace <node> with the name or UUID of the node to clean.

   • Replace <clean_mode> with the type of cleaning to perform on the node:

     • erase_devices: Performs a full clean.
     • erase_devices_metadata: Performs a metadata only clean.

5. Wait for the clean to complete, then check the status of the node:

   • manageable: The clean was successful, and the node is ready to provision.
   • clean failed: The clean was unsuccessful. Inspect the last_error field for the cause of failure.

6. Exit the openstackclient pod:

   $ exit

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Retrieve the UUID of the bare-metal instance you want to attach the VIF to:

   $ openstack server list

3. Retrieve the UUID of the VIF you want to attach to your node:

   $ openstack port list

4. Optional: Retrieve the UUID of the bare-metal port you want to map the VIF to:

   $ openstack baremetal port list

5. Attach the VIF to your bare-metal instance:

   $ openstack baremetal node vif attach [--port-uuid <port_uuid>] \
     <node> <vif_id>

   • Optional: Replace <port_uuid> with the UUID of the bare-metal port to attach the VIF to.
   • Replace <node> with the name or UUID of the bare-metal instance you want to attach the VIF to.
   • Replace <vif_id> with the name or UUID of the VIF to attach to the bare-metal instance.

6. Exit the openstackclient pod:

   $ exit

Procedure

1. Create a configuration file for the physical switches named 03-ml2-genericswitch.conf.

2. Specify the location of the session log file that captures the SSH session commands and responses:

   [ngs]
   session_log_file = /var/log/neutron/ngs.log

3. Add VLAN to the list of supported tenant network types:

   [ml2]
   tenant_network_types = geneve,vlan

4. Use a comma-separated list to map the physical networks to the segmentation ranges for the tenant networks:

   [ml2_type_vlan]
   network_vlan_ranges = <network_name>:<range_start>:<range_end>,<network_name>:<range_start>:<range_end>

   • Replace <network_name> with the name of the physical network.
   • Replace <range_start> with the VLAN ID for the start of the VLAN range.
   • Replace <range_end> with the VLAN ID for the end of the VLAN range.
   Tip

   You can apply multiple VLAN ranges to a single physical network by repeating the physical network name multiple times.

5. Configure each physical network switch with the type of switch device and details of how to connect to the switch device. The parameters required depend on the switch device.

   [genericswitch:<switch_name>]
   device_type = <device_type>
   ngs_mac_address = <mac_address>
   <parameter> = <parameter_value>

   • Replace <switch_name> with the name of the physical network switch.

   • Replace <device_type> with the networking-generic-switch driver to use for the device. For example:

     • For switches that run SONiC, set to netmiko_sonic.
     • For the Cisco Nexus switch, set to netmiko_cisco_nxos.
     • For the Dell Force 10 switch running OS10, set to netmiko_dell_force10.
   • Replace <mac_address> with the MAC address of the switch device.
   • Optional: Replace <parameter> and <parameter_value> with any other configurations required for the switch device. For more information on the available configuration options, see Physical network switch configuration options.

Procedure

1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, on your workstation.

2. Add the following configuration to the ironic service to change the network interface to neutron:

   spec:
     ...
     ironic:
       template:
         customServiceConfig: |
           [DEFAULT]
           default_network_interface=neutron

3. Add the generic switch as an ML2 mechanism driver to the neutron service specification:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     secret: osp-secret
     ...
     neutron:
     ...
       template:
         ml2MechanismDrivers:
         - genericswitch
         - ovn

4. Add the extraMounts parameter to the neutron service specification to mount the configuration of the physical network switches:

     neutron:
     ...
       template:
         ...
         extraMounts:
         - name: switchConf
           extraVol:
           - volumes:
             - name: neutron-switch-config
               secret:
                 secretName: neutron-switch-config
             mounts:
             - name: neutron-switch-config
               mountPath: /etc/neutron/neutron.conf.d/03-ml2-genericswitch.conf
               subPath: 03-ml2-genericswitch.conf
               readOnly: true

5. If you must assign authentication keys to the physical network switches, then add the private key files to the mounts:

             mounts:
             - name: neutron-switch-config
               mountPath: /etc/neutron/neutron.conf.d/03-ml2-genericswitch.conf
               subPath: 03-ml2-genericswitch.conf
               readOnly: true
             - name: neutron-switch-config
               mountPath: /etc/neutron/<key_file_name>
               subPath: <key_file_name>
               readOnly: true

   The mountPath should match the path to the key file defined for the switch device in the 03-ml2-genericswitch.conf file.`

6. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

Procedure

1. Open a remote shell connection to the OpenStackClient pod:

   $ oc rsh -n openstack openstackclient

2. View the event history for a particular node:

   $ openstack baremetal node history list <node_id>

   This command returns a list of the error events and node state transitions that occurred on the node. Each event is identified with an event UUID.

3. View the details of a particular event that occurred on the node:

   $ openstack baremetal node history get <node_id> <event_uuid>

4. Exit the openstackclient pod:

   $ exit

1. Enable the sensor method in the ironic.conf file:

   $ openstack-config --set /etc/ironic/ironic.conf \
      irmc sensor_method <method>

   • Replace <method> with scci or ipmitool.

2. If you enabled SCCI, install the python-scciclient package:

   # dnf install python-scciclient

3. Restart the Bare Metal conductor service:

   # systemctl restart openstack-ironic-conductor.service